[Gambas-user] Inheriting, wrapping and casting

[Bruno Félix Rezende Ribeiro]

Hello Gambas fellows!

Suppose we are overriding the class 'Variant[]' to add the event
'Update' which will be raised after the completion of any method which
could possibly modify the array structure.  In particular, we need
to override appropriately any function that happens to do so.  For
exposition purposes let's consider the 'Extract' function, which removes
one or more elements from the array and returns them.  It's signature
is as follow:

  Public Function Extract(iStart As Integer, \
    Optional iLength As Integer) As Variant[]

Our inherited class has, hence, to override this function with another
of the exact same signature, by Gambas' rules.  However, it doesn't
make sense to return an object of the base class, while the operation
is executed by a derived class over an object thereof.

It seems there is no easy or natural way around it.  We could declare a
second extraction function for the derived class named after a different
symbol like "ExtractDerived", but we'd break the interface, what isn't
a desired outcome.

Another approach would be to forget this particular base class and go
upwards until there is no possible conflicting functions and to inherit
from there, what happens to be in this case the immediate base class of
'Variant[]' called "Array".  However, we'd have to re-implement large
portions of the 'Variant[]' class, that could otherwise be immediately
deployed if not by our particular design problem at hand.

One last, and arguably more reasonable, approach is to give up the
syntactical native language's feature of inheritance --- and its useful
properties -- and to define a dedicated container base class, which
inherits from nowhere, semantically wrapping all functionality of the
class 'Variant[]'.  It'd work as a layer for accessing the underlying
variant array which would be stored in a private variable and isolated
from the outside world, i.e., not directly accessible by any property.
The only way to modify the array's content would be to use the
class' interface which would mimic that of 'Variant[]'.

As we've seen, there is no way if not by modifications of the
interpreter's very core.  Thus, I'd like to know why Gambas enforces
the signature of functions onwards inherited classes.  If not by
technical reasons, but only for methodological consistency requirements,
I'd like to suggest that we make it, at least, allows to use the
inherited class in place of the parent class within method signatures.
Personally, I'd find yet more useful if there were no restriction at
all.

A very interesting and useful feature, related but independent of this
suggestion, is that the interpreter could take care of casting objects
in both directions in an hierarchy of classes.  In order to accomplish
it, there would be introduced two special methods which would be
implemented in any class the programmer deems them meaningful and
useful: '_castUp' and '_castDown', for casting an object from the
inherited to the parent class, and from the parent to the inherited
class, respectively.  Being 'ThisClass' the inherited class and
'UpClass' its parent, the special methods signatures would be:

Static Public Function _castUp (hThisClass As ThisClass) As UpClass
Static Public Function _castDown (hUpClass As UpClass) As ThisClass

The job of the interpreter would be to call these functions, in a
possible chain, to cast automatically upside or downside every time an
object of certain class is used in a context that requires an object of
another class but in the same hierarchy.

What are your thoughts on that?


Thank you.


-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20140417/5f92c94f/attachment.sig>