Vorrei riportarvi questa discussione apparsa nella M.L. ufficiale:
" Occasionally, and unfortunately for me lately quite frequently, I have
found a need to access the first or last item in (or perhaps better "the
first or last item added to") a collection regardless of key values (and
by extension I could envisage a need to access the nth item in a collection
regardless of the key value). There does not seem to be an elegant solution
to this - or maybe just that I am incapable of developing an elegant solution to this.
"First" can be achieved by using the For Each construct and
unconditionally Break'ing the iteration on the first loop. This smells like
using a sledge hammer to crush an ant.
"Last" I have achieved after a manner, but the mechanism is too
embarrassing to reveal.
"nth" I am reluctant to attempt.
Any clues?
--
B Bruen "
" If I remember correctly Benoit warned that collections doesn't necessarily
keep the items in order. But I don't know what would make it to lose the
order. Maybe he will enlighten the issue.
Anyway I suggest you use array of objects, which you declare extra property "Key".
jussi "
" AFAIK, Collection is a hash table and of course, you cannot assume a
particular order of keys in a hash table.
But Bruce apparently doesn't care about an *order* but only that the
elements can be addressed bijectively by the integers in [0, .Count).
But the collection isn't meant to allow you to do that because elements
are addressed by strings, not integers and the integer addressing isn't
meaningful to people other than Bruce in his particular application :-)
HOWEVER, and that's my proposal, an integer index does make sense in the
AvlTree class in gb.data which is otherwise similar to Collection (i.e.
normally uses strings as indices, etc.), because we can traverse the keys
in an AvlTree in order.
If you can use AvlTree instead of the normal Collection in your application,
I will add functionality to get the n-th element of an AvlTree. Otherwise,
we must hack Collection for this special purpose.
And I don't think Benoit will make that change mainline (because it really
has no sense, under normal circumstances, to use integers to address a
string-built hash table) -- or Benoit adds a .Data property, if that is
possible at all, similar to that of the array classes...?
I don't know but my offer holds.
Regards,
Tobi "
" Oh, I just saw the "added to" bit. That's not possible with AvlTree and also
won't be with Collection.
Then I suppose that you create a custom Collection class and make it record
the first and last items added. For the general case of the n-th added item,
you really need to sort your keys by the point in time they're inserted and
that's plainly an array using the Add() method.
Generally, if you want to have the same data *sorted* in different ways (and
you want "sorted" because otherwise you would need to loop through the data
which you don't want), it sounds plausible that you need the data twice, but
in diffent containers and sorted differently.
Tobi "
" >For the general case of the n-th added item,
> you really need to sort your keys by the point in time they're inserted and
> that's plainly an array using the Add() method.
My first question is why not just use an Array full-stop: by
definition that is the structure for accessing
items by order.
> Generally, if you want to have the same data *sorted* in different ways (and
> you want "sorted" because otherwise you would need to loop through the data
> which you don't want), it sounds plausible that you need the data twice, but
> in diffent containers and sorted differently.
Correct.
if the "things" in question are Objects of any type, then internally
what's being held in the Array or Collection are pointers
to the objects, so extra memory use is minimal. In this case IMHO the
most graceful and efficient solution is to have both an Array and a
Collection of the same objects.
If that doesn't work then I'd have a String[] holding the keys to the
collection, this means two lookups so a bit of a speed penalty (but
Gambas is fast at this stuff, I doubt you'd notice)
Ian "
" That is my understanding also. But they always seems to be in order they
have been added, when you iterate them with "For Each ...".
What would cause the disorder?
Jussi "
" There are in order by design (the hash table elements are linked both by
hash slot *and* insertion order).
But I don't guarantee that this non-official feature won't be removed.
Regards,
--
Benoît Minisini "
