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

[Tobias Boege]

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?

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. 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.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk