[Gambas-user] New feature in Gambas 3 development version

[Doriano Blengino]

Benoit Minisini ha scritto:
> Hi,
>
> If you use the development version, now you can declare typed object arrays:
>
> DIM ArrayOfLabels AS Label[8, 8]
>
> The Label[] class is dynamically created by the interpreter the first time it 
> is used. 
>
> It has exactly the same features as the Object[] class, except that it always 
> returns Labels, not Objects.
>
> So, something like:
>
>   ArrayOfLabels[1, 1].Text = "Hello"
>
> becomes faster as the interpreter now knows that ArrayOfLabels[1, 1] returns a 
> label, and so can optimize the property access.
>   
I think that every step in direction of more strong typing is a good 
step, for two reasons. First is the possibility for the compiler to 
check for type mismatches: it is better to catch errors at compile time 
instead to catch them at runtime. Next, optimization and speed-up is an 
added value, thanks to the fact that the interpreter already knows what 
is happening.

> This feature is more powerful. Any class can be followed by "[]" to become an 
> typed array class, and this process is recursive.
>
> So "String[][][]" is an array of array of array of String! I don't know if it 
> useful in that specific case...
>   
Generalization of concepts is always good, in my opinion; one can think 
at something, and know that it will work, without exceptions. Why one 
could have an "array of labels", but not an "array of arrays (of 
something)"? I suspect that an array of array is simply a bi-dimensional 
array (at least at the logic level - for the CPU they could be two 
different things), but still prefer to have two different ways to 
declare it.

> I want to enhance this "template" feature: I'd like to do something like:
>
> DIM MyIndex AS String.Collection
>
> to be able to declare a Collection whose elements are strings. It could be 
> faster than using the standard Collection, whose elements are variants.
>   
Again, strong typization is the key. Variants are nice, but they should 
be used only when convenient. If all that one wants are numbers (for 
example, integers), then an Integer.Collection saves memory and CPU 
time, code is clearer, and more protected from errors. In fact, I always 
look with suspect to heterogeneous collections, lists or arrays. There 
are languages which proudly claim to have heterogeneous lists; I think 
they should be avoided as much as possible. There are cases where this 
is almost required, for example the collection of controls owned by a 
Form but, in my opinion, they should be typecasted explicitly by the 
programmer.

To do the same thing (a homogeneous collection of something), other 
languages require to derive a new collection type from the ancestor one, 
which contains the basilar function of "Collection". While this is 
powerful, it is also tedious and unnecessary most of the times... so, I 
definately say that I would be very content about this feature.

> And maybe we could go further: using any class as template. Something like:
>
> DIM MyListOfString AS String.List
>
> where List is a class written in Gambas.
>
> I don't know that last feature would be really useful anyway.
>   
Right now, nothing comes to my mind about the usefulness of such a 
thing. And I suspect it is nearly impossible to implement in a correct 
way. But there are counter reasons to both the sentences. Nobody can say 
a thing is useless just because he can not imagine a useful way to 
deploy it... so, who can tell?
The second argument is more strict. If we think at the List class as 
something similar to a collection, then the List class should implement 
methods to read, write, add and delete elements (strings, in this case). 
All these things are already present in Collection class. If we do not 
think at the Collection similarity, then what could the List class do? 
And how should it be implemented? And why should we have a declarative 
part (the "AS String.List") possibly conflicting with the implementation 
part? The implementation of the List class already should/could contain 
methods which require/return the correct type (String), so an added 
declaration is a complication. In other words, I see a conflict between 
declaration (String.List) and implementation of the List class, unless 
the List class always talks "variants", and the compiler converts the 
variant type from/to String (because String is in declaration 
String.List). Please note: the compiler does type conversion, not the 
interpreter. In the latter case, these things are already present in the 
language (at interpreter level). If what is wanted is a more specialized 
version of Collection, with added functionalities, then inheriting from 
Collection would be more appropriate.

Hope I succeded in explaining myself. I can't remember right now if it 
is possible in gambas to define array properties but, if it is so, then 
all the semantics required to cover the Collection/Array are already 
present. If array properties are not inside, they could be added...

Anyway, the xxxx.Collection is a great, useful, clean, easy to use idea.

Best salutations,
Doriano Blengino