[Gambas-devel] "Overriding" virtual classes

Tobias Boege tobias at ...692...
Mon Jun 23 19:15:08 CEST 2014


Hi Benoit,

for the Graph class in gb.data, I thought of having a non-creatable Graph
class (we had that topic already in the past) which is the interface
necessary for all concrete graph implementations. This class exposes a
Graph.Edges property to a virtual .Graph.Edges class whose interface and
default implementation are also specified.

As I said earlier, I really want to have it this way because it enables the
programmer to makde a decision on what graph data structure they need to use
for their application and it also makes modelling non-Graph data as a Graph
very easy. An example (which I want to implement as a Gambas example for
Graphs) would be to have an Image object. Each pixel is a vertex and edges
are implicitly defined between neighbouring pixels of the same colour. If
you do a breadth-first search on this graph from a pixel, you are actually
doing a flood-fill on the Image.

This is where the virtual classes become an unbelievably handy thing: you
don't have to create explicit vertex and edge *objects* from the Image but
you can pipe the user requests through the virtual object's interface and
operate on the backing data.

If I now create a GraphMatrix class basing on adjacency matrices which
Inherits Graph, I also need to point the Graph.Edges property to some
concrete .GraphMatrix.Edges class which operates on the adjacency matrix.

Is there a way to do this or can it be implemented? I could store the needed
function pointers myself in a separate data structure and let the standard
.Graph.Edges class reference those but this would not help Gambas programmers
if they want to implement their Graph classes non-natively, right?

So, I'm asking for a way to replace a virtual class with another virtual
class in the inheritance process. [ Maybe you can make an exception in the
inheritance checking routines since virtual classes are a thing of native
components and native components writers should be supposed to know what
they're doing? :-) ]

Regards,
Tobi

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





More information about the Devel mailing list