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

Bruno Félix Rezende Ribeiro oitofelix at ...181...
Tue Apr 15 22:14:12 CEST 2014


Em Tue, 15 Apr 2014 12:55:51 +0200
Tobias Boege <taboege at ...626...> escreveu:

> If I was to sum up your post: you want to call a method of Super with
> a variable argument list?

Yup.  You got that perfectly right! ;-)  I wonder if using your
summarizing sentence right away from the beginning of my original
text would have had the same effect.  In affirmative case I'm
being overly verbose, but it happens that I'm not the biggest fan of
misunderstanding, so I'd rather prefer to play a little bit safer. :-P
Nevertheless, it'd be pointless if actually the extensive explanation
achieves the contrary effect: hard comprehension.  I welcome feedback
on this matter too.


> 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?


> However, multi-dimensional arrays are limited to eight dimensions in
> Gambas, so there is no practical problem at present that would you
> keep you from Select-Case'ing Param.Count and doing
> Super[cased-arg-list-here] = vValue.

Oh... I just forgot for a moment that hard-coded limitation of 8
dimensions.  But yeah, given that our concerns are attached to
practical situations you've suggested a perfectly acceptable solution,
unfortunately somewhat inconvenient, though; yet as convenient as it
could possibly be with the current interpreter.

 
> But I believe in the existence of problems of bigger importance than
> practical problems, like ideational ones [ hope that's the right
> English word... ] where the above solution fails miserably.

I couldn't agree more on that.
 

> In the Tobias-Boegian school of Gambas, we distinguish between "real"
> multi- dimensional arrays and "derived" multi-dimensional arrays.
> Real m-d arrays are those you were about to use, the ones you declare
> with Variant[iDim1, iDim2, ..., iDimN] where N <= 8. These have at
> least three drawbacks:
> 
>  (1) their number of dimensions is limited by 8;
>  (2) the size of each dimension is static; and
>  (3) they can only shape like matrices.
> 
> Derived m-d arrays are array classes built by the interpreter out of
> other classes. If you have a class x, then x[] denotes an array type
> containing elements of type x. Moreover, x[] is again a class. So if
> you repeat that process, you obtain x[][] which is an array class
> that can hold x[] objects.
> 
> Let's look at the three above points. It turns out that derived m-d
> arrays are superior:
> 
>  (1) no limit;
>  (2) sizes of dimensions are fully dynamic; and
>  (3) we are not limited to matrix-shape.

Congratulations.  Very good characterization of "real" and "derived"
m-d arrays disadvantages and advantages respectively.

 
> 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.


> If you are willing to use derived arrays (there seems no reason
> against), you don't have that problem of variable argument lists, as
> there is no syntactic multi-dimensional-ity, you just happen to
> access 1d arrays whose elements are again arrays.

I agree with you that the use of m-d derived arrays is entirely taken
care of by the interpreter and it's quite transparent to my code.
However, if I'm going to replace the class 'Variant[]' presupposing
full backward compatibility, as you've suggested below, I must make
sure my code properly handle "real" arrays as well.


> 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?


> 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. ;-)


I really appreciate your very interesting response.
Happy Hacking!


Footnotes:

[1] http://gambaswiki.org/wiki/doc/forum


-- 
 ,= ,-_-. =.  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/20140415/736c2de0/attachment.sig>


More information about the User mailing list