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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
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

Reply via email to