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
