Question re the uno-skeletonmaker'-t' CLI qualifier

[David]

On 25/1/23 20:05, Stephan Bergmann wrote:
> On 25/01/2023 05:14, David [minor edit] wrote:
>> However treating the '-t' option as a service rather than an interface, as follows, works.  An <org/openoffice/adl/util> directory tree is created in the directory where the skeletonmaker CLI command was run, and a very plausible skeleton CalcDL1.java file was created in <util> though I haven't been through it in detail.
>> Your comment "[...] So I would assume that -t must specify that interface type." is what I'd expect too.  That's reinforced by the HELP text which states:  "-t <name> specifies a UNOIDL type name, e.g. com.sun.star.text.XText (can be used more than once". Not much doubt there... 
> So the uno-skeletonmaker help and diagnostic output apparently uses, somewhat consistently but maybe also somewhat confusingly, the term "type" to mean both UNOIDL interfaces and UNOIDL services. 

That's the problem in a nutshell.

In common programming terminology, the word "type" refers to a single variable or symbol.  A strongly-typed language will flag a compilation error if incompatible types are used, for example 'i=x' where 'i' is declared to be an integer type and 'x' is declared floating-point.  Extending this concept of "type" to a complex structure like a UNOIDL interface, which may include many different atomic types, makes sense.  But I can't see how it can possibly refer to a "service".

An IDL interface and an IDL service are different things entirely, conventionally distinguished by prefixing 'X' to interface names.

And in the case of the uno-skeletonmaker 'calc-add-in command', specifying a service works but specifying an interface fails.  So I argue that the documentation and HELP text are plainly wrong and should be corrected.  After all, skeletonmaker is only at version 0.4!

Perhaps it would be worthwhile checking that this inconsistency doesn't hide some deeper problem.  It feels to me like the result of a misunderstanding or a sudden change of design which may have further ramifications.

D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20230126/88b580e2/attachment.htm>