Quentin Long wrote:
> I don't know if there's a command that will do the job. However,
> there's a construction I use when I merge two list variables into one:
>
> put ItemList2 into item (1 + the number of items in ItemList1) of
> ItemList1
>
> That construction may seem a little weird, but it does the job. So
> *if* the same sort of logic applies to arrays, something like this
> might do the job:
>
> function ConcatArray Array1, Array2
> -- if this was a real function, it would confirm that Array1 and
Array2 are both, you know, *arrays*
> put the number of lines in the keys of Array1 into A1
> put the keys of Array2 into key (A1 + 1) of Array1
> return Array1
> end ConcatArray
The "*if*" there is critical, as strings (LC lists) do not work like arrays.
I'm not sure of the specifics of LC's implementation, but this general
discussion may be useful:
https://en.wikipedia.org/wiki/Associative_array#Implementation
In brief (and woefully oversimplified), we could conceive of an array as
a collection of memory addresses, in which each address is derived from
a hashing function applied to the key.
This is why when we try to display an array in a field it shows empty -
there is no single string for the array data, its contents instead
spread across multiple locations linked together through pointers.
Indeed, given that arrays can be nested, it's non-trivial to come up
with a string representation to meaningfully represent them.*
In contrast to the actual structure of an array, using the keys function
does return a string, a return-delimited list of the key names. But the
creation of that string is copying the keys from the actual array
structure, and not the structure itself.
So given an array which we could notate as:
Array2/
key "a" = value "SomeValue"
key "b" = value "SomeOtherValue"
...the line above that reads:
put the keys of Array2 into key (A1 + 1) of Array1
...would first get a string comprised of copies of the key names, like this:
a
b
...then add 1 to the number of lines there to get 3, and then use that
as the string list of key names as the value of element Array1[3]
That is, if the syntax "...into key <keyName> of <arrayName>" was
something LC did - using LC we'd need to write that as:
put the keys of Array2 into Array1[A1+1)
But while that modified line would execute, it still won't do what we
want here. It applies a return delimited string of key names as a value
to a single element, and what we're looking for is a method of bulk
copying the actual array elements.
This post may seem tediously long and pedantic, but bear with me, as I
think we're discovering an opportunity for an enhanced array tutorial.
The conceptualization of the role of array keys here closely matches one
we saw a couple weeks ago on this list, in which a very experienced
developer was attempting to use the keys of an array as a sort of bulk
copying method for the array elements.
Whether we have a good means of doing that bulk copying already (union
seems useful here) is less interesting to me than the conceptualization
itself. There may be value exploring ways we might make the
conceptualization of arrays more closely match their actual structure,
hopefully making it easier for us to anticipate how the various syntax
for arrays can and can't be used for a given task.
Many years ago Dar Scott put together a wonderfully animated tutorial on
LiveCode (then "Revolution") Message Mechanics, available here:
http://pages.swcp.com/dsc/revstacks.html
I wonder if we might have a similarly inventive soul among us who may be
able to deliver something as nice for explaining array structure.
As with Dar's stack, this may well be a case where illustrations, esp.
animated ones, might help far more than any explanatory text alone.
Arrays are among the more abstract things in LiveCode, a language
otherwise characterized by an ease of learning afforded through more
concrete structures (objects, chunks - things we can see). But arrays
are so useful in so many contexts that it seems an excellent tutorial
would be a welcome addition to our community learning resources.
* The challenge of representing associate arrays in a textual form is
infamous; doable, but cumbersome. JSON is the most popular way to do
this, but being designed specifically for the JavaScript engine it's
notoriously tedious to parse in anything other language. YAML offers a
much more human-readable/writable alternative, though less commonly used.
Now that JSON is included in LC 8 we do at last have a common means of
translating LC's associative arrays to and from textual form. But for
the sake of readability, it might be nice if there was a common YAML
library available as well.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the 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
