[Gambas-devel] Fwd: Re: "Overriding" virtual classes

[Tobias Boege]

On Thu, 10 Jul 2014, Beno?t Minisini wrote:
>  > On Mon, 23 Jun 2014, Tobias Boege wrote:
> >> A try will show how far I can get with the solution I just sent in another
> >> mail. If it's not satisfying, I'll return to this thread...
> >>
> >
> > I have almost all pieces collected. But take this sample expression (first
> > the variable/property/method name, then the class name in parentheses):
> >
> >    myGraph (Graph)
> >      `-- .Vertices (.Graph.Enumerable)
> >            `-- [iVertex] (.Graph.Vertex)
> > 	       `-- .OutEdges (.Graph.Enumerable)
> >
> > This expression may be used as
> >
> >    Dim iEdge As Integer
> >
> >    For Each iEdge In myGraph.Vertices[iVertex].OutEdges
> >      Print "The vertex";; myGraph.Edges[iEdge].Destination;; "is adjacent to";; iVertex
> >    Next
> >
> > This way, I have lots of different classes that inherit .Graph.Enumerable
> > which is just a class that has a _next() method. But this _next() method
> > needs to be implemented differently for different things to enumerate on a
> > graph, like vertices, edges or edges going out from a particular vertex.
> >
> > You see, there is lots of things to be enumerated here and my problem is
> > that I don't want users to have like a half dozen (Graph.Vertices,
> > Graph.Edges, Graph.Vertices[i].InEdges, Graph.Vertices[i].OutEdges,
> > Graph.Vertices[i].Adjacent) classes to write which all just contain _next()
> > methods. (On the other hand, I do want to use virtual classes instead of
> > arrays to reduce memory usage for graphs that are implicitly defined by
> > another data structure (for which I gave an example yesterday).)
> >
> > I thought of having like _nextVertex() and _nextEdge() methods in the
> > *Graph* class. Then I could write a .Graph.Vertices class which Inherits
> > .Graph.Enumerable and is responsible for iterating over the vertices of a
> > graph - once and for all in gb.data. No Gambas programmer would then have to
> > write their own .Graph.Enumerable class for vertices (and likewise with the
> > other enumerable things).
> >
> > Its _next() method would only consist of a call to the _nextVertex() method
> > of the concrete Graph implementation. This way, we can preserve the syntax
> >
> >    Dim iVertex As Integer
> >
> >    For Each iVertex in myGraph.Vertices
> >      ' ...
> >    Next
> >
> > But there is the overhead of the call to myGraph._nextVertex() from
> > .Graph.Vertices._next(), i.e. GB.GetFunction() and GB.Call() because the
> > actual Graph's _nextVertex() implementation or location is unknown at
> > compilation time.
> >
> > The goal is, as I said, to reduce the number of short classes the user has
> > to write to implements their own Graph. In Java, the situation is a bit
> > better because there you can have nested classes which are easier to read
> > because they're *inside* the class they operate on and can also access their
> > private symbols.
> >
> > Do you have a better idea? What I need is a way to iterate over the same
> > object in multiple ways, i.e. I need For-Each to be able to pick different
> > _next() implementations in the same class.
> >
> > Regards,
> > Tobi
> >
> 
> 1) Can you commit your code?
> 

It's not really done yet (and by "it" I mean just the interface).  It's the
examination period currently for me, so I will take entire days off to work
on Gambas but afterwards entire weeks to prepare.

Tomorrow noon, I'll begin a Gambas day again and can hopefully incorporate
the suggestions from gambas-user into my mind map :-)

> 2) Do you want the user to implement its own graph class in Gambas or in
> C/C++?
> 

In Gambas! I succeeded to implement a Graph which is implicitly defined by
an Image object (in pure Gambas), by inheriting native virtual classes (with
the _Virtual_ClassName naming scheme, i.e. with underscores instead of dots,
so that the appropriate source files can actually be created and used in
Gambas code). I'll commit tomorrow, I hope.

Regards,
Tobi

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