Calc Macros - lagging behind?
sbergman at redhat.com
Tue Oct 6 03:26:10 PDT 2015
On 10/03/2015 05:54 PM, Michael Meeks wrote:
> On Sat, 2015-10-03 at 08:44 -0400, Christian Heller wrote:
>> eg I love the strict types that get me all the member
>> functions and variables by just typing "." (auto-complete).
> This is a huge scriptability problem that we have. The Excel interfaces
> have concrete typing - so you get an "Window" object and all the types
> of the members are known, and there are helpful methods to get a
> Worksheet property of type WorkSheet etc.
> I guess that the UNO interfaces are far less annotated, and many
> properties are hidden by generics; though Stephan has done some nice
> work in recent times to make it easier to pass type information through
> tricky places, and its possible to type annotated properties ahead of
> time. Do you have plans for the IDE in that regard Stephan ? (can we
> pass type information about eg. collections through too ? )
Sorry, I'm not sure what work of mine you would allude to here?
The generic answer would be "shiny new (of ca. a decade ago) UNO," but
that never addressed the issue of using generic containers well.
(Introducing polymorphic interfaces would probably have been more useful
than introducing polymorphic structs---but also more work.)
There is two approaches imaginable. One is to introduce some high-level
interfaces to cover typical use cases in more type safe ways, as
mentioned below. (LOK could have provided that, I think, if it hadn't
gone to create its own silo interface.)
The other is to extend UNOIDL with polymorphic interfaces, and to
retrofit existing container interfaces to either keep working on
arbitrary values of type ANY, or to only work on references of some
abstracted-over interface type. (Similarly to how generics were
retrofitted into Java containers.) This is hard, though, at least for
two reasons: For one, there is a mismatch large enough between "type
ANY" and "some abstracted-over interface type" to make it rough going to
integrate this at least into the C++ language binding. For another,
existing uses of the ANY-based containers may most of the time use only
a specific interface type, but occasionally take the liberty to not
stick to that, probably making it hard to retrofit these changes into
the existing corpus of UNOIDL in a sound way.
A relaxed approach could be to introduce polymorphic interfaces into
UNOIDL as glorious documentation only, so that language bindings would
go unaffected in general, but e.g. the Basic IDE could make use of the
annotations to provide better auto-completion suggestions (even though
they might occasionally not be perfect, see the "for another" above).
>> dim args1(0) as new com.sun.star.beans.PropertyValue
>> args1(0).Name = "Text"
>> args1(0).Value = "Your name"
>> dispatcher.executeDispatch(document, ".uno:InsertText", "", 0,
What Basic code like this might benefit from is some syntax for
"compound literals," like
dim args1(0) as new com.sun.star.beans.PropertyValue(
Name: "Text", Value: "Your name")
(Name: "Text", Value: "Your name")))
> This of course is not a great way to insert text either ;-) my hope
> would be that we could encourage people to use the UNO APIs through
> making them easier to understand and use - perhaps with some less
> cumbersome top-level, strongly typed methods to get useful interfaces.
> Either way - I agree its a huge hole, and it'd be lovely to have
> someone to care about not only our API - but how we can use stronger
> type information to get the IDE into some more usable shape.
More information about the LibreOffice