[Libreoffice] BASIC IDE code completion

[Henrik Jensen]

Hi Stephan

On 19-08-2011 09:40, Stephan Bergmann wrote:
> On Aug 19, 2011, at 2:06 AM, Henrik Jensen wrote:
>> On 16-08-2011 17:50, Michael Meeks wrote:
>>> On Mon, 2011-08-15 at 23:40 +0100, Henrik Jensen wrote:
>>>> Later when I feel more comfortable with the code, I hope to be able to use (resurrect ?)
>>>> the old GSOC 2006 project http://wiki.services.openoffice.org/wiki/BASIC/UNO_Object_Browser
>>>> as a stepping stone for pursuing  an old dream of adding (at least some primitive kind of)
>>>> code-completion functionality to the star-basic editor.
>>>
>>>      Ah - that would indeed be nice; unfortunately - queryInterface makes a
>>> dogs breakfast of type inference from objects: by the power of
>>> 'meta'ness ;-) we have no idea what interfaces are supported, and we are
>>> constantly loosing strong type information down 'Any' shaped holes -
>>> which is a shame.
>>
>> Oh my, that sounds more like politicians with vague promises than interfaces with contracts. :-P. Heh, I got this feeling I'm probably better off slowly turning the lid back on what appears to be a can of worms, hoping not to many noticed, and focus on more realistic objectives for the near future. :-)
>>
>> Jokes aside, I'm a bit surprised of these difficulties because there seems to be plenty of reflection interfaces in the uno-framework:
>> http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/AdvUNO/UNO_Reflection_API ?
>> Is the Editor component on a too low layer to take advantages of these ?
> 
> The problem is rather that much of the interesting information about UNO objects is only available dynamically, at runtime.  The static type information that is available is indeed often just only XInterface (or some other basic interface type) or ANY.  So you generally face the same problems wrt code completion as you face with any of today's dynamic programming languages.  UNO has the concepts to do better, but most parts of the API do not make use of them.
> 
> -Stephan

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?

--Henrik