Re: [Libreoffice] BASIC IDE code completion

On 20/08/11 11:41, Henrik Jensen wrote:
> Hi Stephan
>
> On 19-08-2011 09:40, Stephan Bergmann wrote:
> If I understand the problem correctly: So the hypothetical 
> code-completion engine has to, at runtime, initialize all kinds of 
> temp-objects and objects they use and so forth and destroy them 
> afterwards, to be able to extract type information on them. This kind 
> of tedious house holding should have been eased with the reflection 
> and introspection interfaces but the rest of the api does not support 
> these interfaces very good?
not really, the main problem is that to extract useful information from 
an object you need some hint about the type, unfortunately there are 2 
things that make doing this with the basic IDE difficult,

a) Libreoffice basic like most scripting languages is a very loosely 
typed, so mostly there is *no* information available at compile time. 
Most scripting languages ( VBA for example ) allow you to explicitly 
define the type of an object and this is where you can get some real 
bang with a  refection api. Libreoffice basic only has the 'Object' type 
( which could be an UNO object ) it doesn't support any specific uno 
object types.
b) like Stephan and others mention, the problem about the uno objects is 
that mostly the useful information is only available at runtime, so.. 
even if stronger typing were available from Basic( and it would be 
possible to do that I think without needing heroic effort ) the amount 
of useful information would not be that great ( but maybe better than 
nothing ) Of course that would bring the question of what 'types' should 
you be able to define an object as, defining an object as some sort of 
XSomething in reality only would allow you access to a small facet of 
the object's methods/properties etc. Being able to define an object as 
some sort of Service type has been proposed in previous discussion along 
these lines but I don't think the needed information is currently stored 
in the types/services db(s) additionally the accuracy of such 
definitions where they exist could be well... questionable.


Noel