[Gambas-user] Advising methods of non-fixed argument tuple in a parent class

[Tobias Boege]

On Tue, 15 Apr 2014, Bruno F??lix Rezende Ribeiro wrote:
> > AFAIK, you are right that we cannot call Super._put() directly when
> > we want to pass a variable number of arguments. For that, we need to
> > manipulate the Gambas stack to push that stuff and then call the
> > method. That's precisely when Object.Call() would come into play and
> > AFAIK, you are right, too, in that we cannot use Super there as it
> > cannot be used alone. And there is no other way of accessing our
> > inherited class. That looks like a limitation.
> 
> So, I guess it'd be a reasonable feature request to include at least a
> way to bypass this particular limitation.  By the way, are you a Gambas
> developer?
> 

Not one of the kind that could do such a thing. I'm working on C/C++
components for Gambas (and if you write C/C++ components for Gambas, it is
inevitable to look at the interpreter's source once in a while). In the
source tree:

  $ grep -R Tobias * | egrep "\.(class|project|component)"

should show you where I've been. I develop components as there is time but
mathematics students aren't very famed around here for having much spare
time.

> > Maybe now it becomes clear what I meant with matrix-shaped: if you
> > have real m-d arrays, any dimension must have the same size at every
> > point, e.g. if you have a m-d array of three dimensions, it will
> > always look like a cuboid. Whereas 3d derived m-d arrays are arrays
> > of arrays of arrays and every two arrays in that system may have
> > different sizes. [ I first posted that explanation here[0]. ]
> 
> I guess [0] is in German, and thus unfortunately I can't read it.  I
> have the feeling, though I could be deadly wrong, that outside this
> mailing list, there are a lot more information and discussion about
> Gambas in languages other than English.  It seems that [1] supports
> this claim.  It's unfortunate because fewer people can have access to
> that information, and it segregates the user-base to some extent.
> 

Yeah, there is likely quite some information about Gambas only available
to a very limited community in their language - and I must admit that I
don't even attend those famous French or Spanish sites (not even
whiteislandsoftware.com).

BUT there is only one German Gambas community I know of and that's the
Gambas-Club of which I have taken care recently. Since I'm active on this
list, the link is established (it's just not broadband). Of Ru Vuott and
Willy Raets, I have noticed that they must have taken similar positions.

I suppose that this is how it works with the other forums as well. So
potentially, we can transfer most of the stuff into this list if people
ask the right questions... maybe. :-)

Too bad that you can't understand German, though. I had luck with others
in the past who could at least somewhat read German. Actually, I have
translated everything about array classes I said in that post in my last
mail but there is also a German online book[0] we're writing about Gambas
which happens to contain "original research" and "exclusive material" :-)
(may it only be up-to-date documentation of some classes).

> 
> > And finally let me tell you something about extending classes: it gets
> > especially cool when you call your extending class like the extended
> > class. Above, you would not call your class VariantArray but
> > Variant[]. [ At present, you have to create .src/Variant[].class
> > outside of the IDE in your project because the IDE forbids use of
> > brackets in class names. However, the interpreter doesn't seem to
> > have any problems with that. ]
> 
> What a neat tip!  If the behavior of having classes with brackets in
> their names is useful --- and even the interpreter is fine with that ---
> I don't see why this wouldn't be an IDE bug.  Have you or anyone else
> addressed this bug or submitted a bug report on this?
> 

It was discussed already in this thread [1].

> 
> > That way, you are overriding the Variant[] class in the interpreter's
> > global symbol table, using inheritance, i.e. you extend it. You can
> > add features to Variant[] which are immediately available to all
> > users of the Variant[] class without having to change any code.
> > That's explained in the docs as well[1].
> 
> Talking about that, don't you think that an 'Update' event as I've
> described would be a very nice core addition to the 'Array' class in
> the main distribution?  It seems to me it would be generally useful for
> users.  Poor 'Array' class... it doesn't have any events --- let's give
> it some useful ones. ;-)
> 

That would mean overhead which is unnecessary - I dare to say - _most_ of
the time. I myself never needed a data container which would tell me when
it changed. That is also a decision I have made for gb.data: classes in
there are data containers. They don't communicate with me (raise events),
they only contain.

And raising an event in code means to execute some functions, no matter if
that object is actually able to generate events. It is not, e.g. when it
has no event name which is the case for all current code. Since changing
data in an array is surely one of its most used functions, it would be cool
to see a benchmark with and without that event. But I bet the benchmark
with event wouldn't look too nice...

Regards,
Tobi

[0] http://www.gambas-buch.de
[1] http://sourceforge.net/p/gambas/mailman/message/29417207/

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