Parent of Target

[Mark Waddingham]

On 2017-08-10 01:47, Monte Goulding via use-livecode wrote:
> Thinking about this some more I wonder if a stringified representation
> and string representation type could be paired with the object
> reference so that if you got say the abbreviated id then that would be
> the stringified representation and if the object is deleted then the
> stringified representation is used from then on until it is
> re-resolved (say the stack is reloaded). Then if it is re-stringified
> then the new representation stored. The only issue here would be any
> code that relied on the string not changing when you rename etc an
> object etc but I’m not sure how common that would be. That and there
> could be quirks like if you get the reference, rename it and then
> delete it the string representation would probably still be the
> original name. The general idea though is it would be something like a
> string is now in the engine. We don’t need to know if under the hood
> it is currently an 8 bit native string or a 16 bit unicode string.

This sounds very much like the idea proposed here - 
http://forums.livecode.com/viewtopic.php?f=66&t=15017 - as a reason for 
why UUIDs were not necessarily the 'right' approach (and never will be, 
IMHO) ;)

This is something which could be done (with the new architecture in 7+, 
indeed the potential for it was one of the many many reasons that 
motivated the refactor) - however, in reality, we risk changing the 
language quite fundamentally. Something which I became acutely aware of 
during the refactoring process (partly through direct conversation with 
a variety of long-term xTalkers - trying to explain what could become 
possible with it).

If we are going to break the everything-but-arrays are strings semantic 
then let's do it (1) completely and (2) in a way which ensures we 'bring 
everyone with us' (how many VB users didn't move to VB.NET?). [ The 
latter point is the most important one, btw ]. 'Creeping' language 
changes just don't work - particularly at the core semantic (types, in 
this case) level - you risk ending up with something which may be much 
more powerful but also much less accessible/easy/familiar/... ]

Indeed, this realisation of the crucial 'semantic gap'* LiveCode Script 
has (which is true of 4GLs *in general*) was one of the motivations for 
Builder**.

Builder already has the 'object handle' (ScriptObject) idea - so we can 
use that to build a library which manages the object references the IDE 
holds at any one time. This solves the robustness problem we face in the 
IDE and in a way which doesn't require a single change to LCS. (Over 
time it could also solve the speed issue too - we implement the parts 
which are bottle-necked by ScriptObject<->StringId conversions in LCB so 
they aren't necessary). [ Robustness is far more important than speed 
here, though ].

In terms of user-code, then yes, there are also user apps which require 
this - so we can just make the functionality a user available library 
extension when it is mature enough. Users can then evaluate whether it 
is 'worth' the extra cognitive cost of using such a thing for their 
situation on a per-project basis (just like the IDE - being a LiveCode 
Script project itself).

Warmest Regards,

Mark.

* I should stress that what I call a 'semantic gap' does not in any way 
make LCS a 'lesser' language - because it really is not. xTalks have 
evolved with a different focus from many other languages and fill that 
very well, that's all. They make the tasks it is focused on easier, at 
the expense of making some other things harder (but only slightly - you 
still have the 'ease' of the language as a whole to couch them in).

** I do see a future where there are not two languages - 'Script' and 
'Builder' - but only 'LiveCode'. However, that 'unification' has to be 
done in a way which does not, in any way, detract from what makes 
LiveCode Script what it is (which sounds subjective, but the recent 
study released about 'cognitive load' does perhaps suggest a means of 
measurement - which starts to make it objective).

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