> On 10 Aug 2017, at 6:48 am, Monte Goulding via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> I have actually thought about whether it would be reasonable for `the long 
> id` to return such an object reference as it would stringify automagically if 
> necessary. However, deleting the object would mean the string form couldn’t 
> be created so that probably wouldn’t work... I think complex objects that 
> handle many object references and the IDE would have a significant bump in 
> speed if we did such a thing.

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.

If we could work out all the little niggles in the idea then it could be that 
we wouldn’t need to change our code at all (other than to remove all the code 
which tries to handle name and id changes) which would be nice. Also things 
like `the target` and `the owner` could seamlessly upgrade to being references.


use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to