syntax options for reading array properties

Richard Gaskin ambassador at
Sun Sep 27 13:11:18 EDT 2009

David Bovill wrote:

> 2009/9/26 Richard Gaskin <ambassador at>
>> Is there any trick to using customProperties[<arrayNotation> to access
>> nested array elements in an object?
> No. As far as I understand it the new nested array data structure uses
> arrayencode / arraydecode internally and this adds the speed hit. 

That's what it seems, and arrayDecode/arrayDecode benchmark as the 
slowest of all array storage options I've found.

Oddly enough, two-dimensional arrays (property set + property list) work 
reliably and lightning fast, e.g.:

   put the uPropSet[tSomeProp] into tResult

But alas attempting to go deeper fails:

   put the uPropSet[tSomeDeeperKey][tSomeProp]


> For that reason, and others I've moved over to using getprop / setprops
> together with script locals to store nested arrays. These are then loaded
> I think when the stack (or card / object) is loaded so you get the speed
> increases and the same syntax.

I've used getProp and setProp in a number of projects, and they do make 
convenient accessor for some uses (though I still prefer simple commands 
and functions for many accessors as they require less typing, using 
getProp and setProp for cases where the storage object may change).

But in this project the data will be loaded and accessed only once in a 
given session, so it would be ideal if we could have both persistence 
and efficient performance.

Looking into the RQCC this morning I found an excellent discussion on 
this by Mark Waddingham in in request submitted by Björnke:

The solutions Mark offers there would be great - easy to read, easy to 
write.  If only they existed. ;)  I added a few votes in hope that they 
one day will.  Good ideas there.

While I was there I added a request to solve the bloat problem with keys 
of sub-arrays within a parent array in which all of the sub-arrays use 
the same key names:

  Richard Gaskin
  Fourth World
  Rev training and consulting:
  Webzine for Rev developers:
  revJournal blog:

More information about the Use-livecode mailing list