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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user