Calc Macros - lagging behind?

[Stephan Bergmann]

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,
>>          args1())

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")

or even

   dispatcher.executeDispatch(...,
     new com.sun.star.beans.PropertyValue(
       (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.

Yes.