Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.