Speed of control lookup (Was Re: Parent of Target)
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.
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the Use-livecode