This is long, so skip it if you're in a hurry... Long ago, in use-list terms, when I was up to my neck in visitors (in one country) and a new baby (in another), I read Richard's post below and it made me think how little I understand LC arrays. Now the visitors have gone and the baby has put on a whole pound (he was four weeks premature) and I have a little time to ask for help in understanding LC arrays.
My array knowledge is very very ancient, and the languages (largely forgotten) where I was able to use them were childishly simple. Basically an array, say AA, had elements, AA[1], AA[2] etc with no gaps. In some languages AA[0] would have been the first element. Elements could contain numbers or in some cases other types of object, particularly character strings (these were typed languages). By 'no gaps' I mean that all the elements from the first to last necessarily existed: AA[n] might be empty, but it would not (could not) cease to exist for that reason or any other. So in these languages the size of an array was simply the number of the last element to be created. Different languages allowed different operations on arrays as a whole, but these were very limited if they existed at all. In LC, I think (but I am fuzzy, which is why I'm writing this), the 'keys', i.e. the designators of each element, like 1, 2 etc in my old system, can be any character string, including of course the cardinal numbers as above, or the ordinal numbers for that matter, or something completely arbitrary like say the names of stations on the London Tube map. This must mean that, it seems to me, that there is no longer any implied order: I mean AA["Oxford Circus"] is neither before nor after AA["Victoria"]. I suppose that if some sense of order is required, then one simply has to choose inherently ordered keys, like letters of the alphabet, cardinal numbers etc. Can someone confirm this? I do understand that in LC, array elements can be completely deleted, rather than just rendered empty. I'm glad the engine does the garbage collection rather than the humble programmer. The other thing I think I understand is that an array element (the contents of AA["Victoria"]) can be anything, from empty to an entire stack, and taking in other arrays, which gives the possibility of multi-dimensional arrays, doesn't it? Again I am fuzzy: suppose we have a superset called, I dunno, 'Metros of the world', or 'MoW' for short. So an element of this can be MoW["London Tube"["Oxford Circus"]] can it? Or is that meaningless, and one has to write MoW["London Tube] ["Oxford Circus"] which seems counterintuitive to me, since it doesn't look nested: Is that in fact multidimensional, and is it legal? Again I am confused, despite having read Page 147-149 of the LC User Guide. A further issue to me is the operations that are allowed on entire arrays in LC - I note the existence of 'split' and 'combine'. Is that it? What happens when you combine a multidimensional array? Can anyone point me at a really clear exposition of LC arrays, preferably with diagrams? It's easier IMHO to think of this stuff in pictures... Here's hoping, as I have a feeling I'm going to need arrays in my next project. Otherwise I might try to write a little essay about it myself, but it would mean a lot of trial and error, I imagine. TIA Graham On 4 Aug 2014, at 07:48, Richard Gaskin <ambassa...@fourthworld.com> wrote: > Mike Kerner wrote: > >> The problem we have with arrays is that they don't let us really use >> indirection, i.e. pointers/handles. It's a lot easier to write generic >> handlers for a screen full of controls with pointers/handles. "DO" is ok, >> but it's the same problem we've always had with "DO", namely it's slow. >> It's very, very flexible, but it's slow. > > Your post suggests an interesting angle: > > Before xTalk had associative arrays, I used to work really hard to be able to > have arbitrary numbers of name-value pairs in structures that were gracefully > usable. Then when arrays came along so many things became easy which had > been difficult and slow before. > > So with the sorts of things you'd like to do with pointers, what might we > imagine that would be to arrays what arrays are to "do" in terms of efficient > paradigm shift for certain ranges of problems? > > Maybe there is indeed a very different way of working waiting to be > discovered and put to use. > > Maybe it could become achievable within the time frame of Open Language.... > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for Desktop, Mobile, and Web > ____________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
