[Gambas-devel] Should we provide different implementations to the same abstract datatype?

[Tobias Boege]

Hi Benoit,

I want to implement a Graph class for gb.data and I'm struggling with what
internal representation to use because depending on the application, one
data structure may perform badly and another one well. This may invert for
a different application.

To have a well-performing Graph in their application, the programmer should
choose the internals themselves and I'm thinking that I can do the following
to support that:

 - Create a non-creatable class Graph that provides a common interface
    - Create a GraphAdjMatrix class which Inherits Graph and overrides its
      methods and properties to be an adjacency matrix based implementation
    - Create a GraphAdjList class " to be an adjacency list based
      implementation
    - etc.
 - If the user cares, they can explicitly request, e.g., an adjacency
   matrix. Maybe there will be a Graph._call() static method that returns a
   default implementation's object for those that don't care.
 - Method signatures will only need to refer to the Graph class so that a
   non-expert user (not familiar with that inheritance tree) doesn't need to
   be confused. But still the correct methods are applied to the objects as
   Gambas uses virtual dispatching.

[ For a more intuitive feeling, I can also make Graph creatable and do the
  same in _new() that I planned to do in _call()... right? ]

Does that sound reasonable? If you don't have strong objections, I would
really like to do it that way. Maybe I can also introduce an abstract
SearchTree class and have AvlTree (the only search tree at present) inherit
from this class - because there it is the same principle but better
developed as there are plenty of search tree implementations with a common
set of operations.

This way, there would be some analogon to the UserControl class of gb.qt4
for abstract datatypes, i.e. the user can also design Graph/SearchTree/...
implementations in Gambas and pass them equally to all the methods that
accept abstract Graph/SearchTree/... objects, i.e. methods that are agnostic
about the implementation.

Regards,
Tobi

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