This is all very clever (seriously!), but I think this thread is
simply talking about two different things. It is one thing to maintain
your own sorting information in arrays. It's another to pull the data
out of arrays, then sort it. But it's another entirely to have
sortable array. When your data gets really large, you don't want to
have to maintain your own indices for sorting. You can, but it would
be way more efficient to keep it in the engine.
The latter is what, I think, some would like to see. The workarounds
are great, and if they work for your needs, then you probably don't
need native support. I love resourceful solutions =). But I have to
agree -- native support would be a nice addition.
One point of speculation which would make a huge difference is how Rev
is actually implementing the arrays. If it is truly a hash table,
providing any sort of in-order traversal of the array elements won't
be happening any time soon. A hash table is an unordered piece of
data, and so to provide any sort of built-in sorting, RunRev would
have to implement workarounds under the hood similar to what people
are already scripting. On the other hand, if they are using something
more like red-black trees, it is trivial to walk the tree in order and
return the elements. Or backwards. Or "next" and "prev" functionality.
But... I have no idea what data structure they are using.
FWIW.
- Brian
You enter the keys into the list while you enter real data stored
behind these keys that are the individual containers. It was in my
previous post, kind of. I just left out the process.
Let's assume that there is no sort function for keys added or order
of entry
set controls.
put chars 4000 to 5000 of zigzag into myArray[4]["4000to5000"]
-- this is the data being stored
-- It received the key "4000to5000"
-- I then created a layer/zone - whatever, (a list) that is appended
as I add more and more data with keys added to the layer myArray[4].
Now that I think of it, and keeping with the illusion that I'm
always going to keep any dimensional layer's (key registry) in
["keyReg"]. There might be a time when I want to use layer [9].
put "4000to5000," after myArray[4]["keyReg"]["sorted"] -- sort this
put "4000to5000," after myArray[4]["keyReg"]["notSorted"]
put "4000to5000," after myArray[4]["keyReg"]["entryOrder"]
put "4000to5000," after myArray[4]["keyReg"]["globalEntryOrder"]
Later you can sort the list of keys in myArray[4]["keyReg"]["sorted"]
Do you see it yet. "4000to5000" is the key to those 1000 characters
that were stored in the dimensional array.
You want at it in the order that it was entered:
put myArray[4][ item 2 of myArray[4]["keyReg"]["entryOrder"] ] into
hThis
You want at it in the order that it was sorted:
put myArray[4][ item 1 of myArray[4]["keyReg"]["Sorted"] ] into hThis
You want at it in the order that it was entered anywhere in the
array, any layer:
put the number of items in myArray[4]["keyReg"]["globalEntryOrder"]
into tNum
put myArray[4][ item tNum of myArray[4]["keyReg"]
["globalEntryOrder"] ] into hThis
I don't see the need for the engine to physically move the data if
the keys are sorted or custom arranged.
Does that help?
P.S. Those calls to the array within the calls to the array are
untested.
Mark
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
