Speed of control lookup (Was Re: Parent of Target)

Mark Waddingham mark at livecode.com
Sat Aug 12 05:26:03 EDT 2017

On 2017-08-11 23:58, Monte Goulding via use-livecode wrote:
> That would mean speed improvements could be done on an object
> reference that is relatively robust to changes in the object tree and
> unless you are creating an IDE you would be very unlikely to need to
> do the LCB object reference repository thing.

I was pondering that whilst writing my 'experiment'. Whilst it says 'for 
strict long ids', its strictness is more in the string structure (all 
tokens lowercase, all integers 0 or start with 1, one space between 
tokens etc. - this is mainly where the speed comes from - the 'parser' 
in my experiment is basically an unrolled regular expression). It could 
be evolved to parse more general control chunk chains over time.

Indeed, I was wondering whether 'minimal id' might be a reasonable name 
- however, whatever the name, there's still the choice of stack short 
name vs filename. I'd be happier about introducing a new id if we could 
solve the multiple mainstack with same name issue too (or at least get a 
step closer to it) - whilst it might be nice to think it could be done 
with more appropriate search order, given the move towards libraries and 
other such things I worry that no search order would ever solve the 
problem really; and would end up with issues appearing in complex 
circumstances which are hard to diagnose.

However, certainly, it would mean that the LCB idea is only something 
you would need if you were writing a full IDE - as the problems the IDE 
has only really come about because arbitrary script runs within it which 
it can't control; in particular, locking messages around changes to 
stack names, control ids, or control ownership.

Warmest Regards,


Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

More information about the Use-livecode mailing list