On Jul 12, 2004, at 10:10 PM, J. Landman Gay wrote:
If speed doesn't matter, then base your storage methods on convenience. If speed does matter, use variables.
Alright. Noted. (Though Richard's article on stack properties suggested otherwise.)
BUT, variables are less powerful (or at least more clumsy) than I am used to, OR I'm using them wrong, and I don't think so. Arrays in Rev are great - but they are not multi-dimensional, and every simulation I've seen so far has holes in capability you could throw a global through, again, to my level of understanding. While some of the custom solutions that have been offered up undoubtedly serve their masters well, they are not strong in a generic sense.
For instance, if you use Director, you know that casts are somewhat like "resource stacks." They have the same "not as fast as a variable" issue, so at times, I store data in casts, but then on program launch, rip all the contents of the cast into a nested array... images, text... everything. This gives me amazing speed of variables, and the pathing ease of a multi-D array, but the storage of a cast. On close, you just put any changes back to the cast and save it.
If you don't use Director, or any language which is list-based, consider a Multi-D array to have the speed of a standard array, the pathing finesse of XML, and the RAM-based storage capacity of a stack (images, other binary data, text, properties.)
In your case, it sounds to me, like when things get multi-dimensional in Transcript, you are probably doing something multi-line, correct? Or do you relate multiple arrays to each other?
Gosh, I hate to dwell, but it seems like there is a choice between power, speed, and pathing elegance being made here, and for the nature of many of my applications, I need all three. Access time, and the ability to locate what I am looking for directly is pretty critical.
Good lord, am I going to have to write or adapt one of the custom solutions like the other guys have, just in order to get variables that have power like I am used to? I think I'd rather just continue my huge unlearning process and find some solution which is the way Rev WANTS to work. Whatever that is.
Perhaps it is time to bone up on chunking techniques, arrays, and multi-line data in arrays?
My standard disclaimer - I'm not trying to be difficult, just trying to get the best performance from my applications, since their nature demands best performance.
--
Troy
RPSystems, Ltd.
http://www.rpsystems.net
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
