[Gambas-devel] Multi-level virtual objects, inheritance and symbol resolution mess

Benoît Minisini gambas at ...1...
Wed Sep 10 22:11:45 CEST 2014


Le 10/09/2014 21:34, Tobias Boege a écrit :
> On Wed, 10 Sep 2014, Beno?t Minisini wrote:
>> Le 06/09/2014 17:50, Beno?t Minisini a ?crit :
>>>
>>> OK. As I thought, the "_" prefix was the problem. I fixed the
>>> interpreter so that it decides that a native class is virtual by taking
>>> into account the "GB_VIRTUAL_CLASS()" declaration, not just the initial
>>> dot in the name.
>>>
>>> But there is another problem:
>>>
>>> hGraphMatrix.Vertices[] calls GraphVertices_get, which calls the
>>> "_getVertex" method. As "_getVertex" returns a "virtual object", no
>>> dynamic calling can occur, and the InDegree property of _Graph_Vertex is
>>> called, never the InDegree property of _Matrix_Vertex.
>>>
>>> I have no solution at the moment...
>>>
>>
>> Hi Tobias,
>>
>> Did you succeed in dealing with that tricky stuff?
>>
>
> Tricky indeed. So far I have essentially nothing (working)... [ Good thing
> I just finished the elementary number theory part of my exam preparation and
> am tackling the graph theory part. I think I can afford to work a little on
> Gambas now since it is about graphs, too :-) ]
>
> I had a problem which is at least unrelated to the design difficulties:
> After going through the interface of a Gambas class, the program aborts due
> to an error "Symbol not found". Indeed some of the methods I search via
> GB.GetFunction() are not implemented (because they're optional). How can I
> clear the error information in this case? I saw a way in gb.eval which
> requires linking gb_error.c to my component. I'm surprised there doesn't
> seem to be a GB.ClearError() or something... Is the gb.eval way the advised
> one?

GB.Error(NULL) clears the error.

>
> Also: to get the graph interfaces, I would do the following: a native
> implementation provides a structure of function pointers to its objects
> themselves. A Graph in Gambas gets scanned in its _init() special method
> and a structure of Gambas function pointers are stored in a hashtable,
> indexed by the class name. Whenever an object of the latter is instantiated,
> the structure is looked up -- or is there already a standard mechanism to
> save per-class information? Like a spare place of memory in the CLASS
> structure.

You must call GB.GetFunction() for each method you search and stores the 
result. The class implementation must stay opaque to the components.

> As each object can access its class very quickly, this would save
> a hashtable lookup on object creation. Not a big saving but a question that
> came to my mind.

I don't see how you can save a hashtable lookup (technically it's not a 
hashtable, but something faster) if you look for the method "_getVertex" 
with a specific signature.

Regards,


-- 
Benoît Minisini




More information about the Devel mailing list