is strictly a name

Paul Dupuis paul at researchware.com
Fri Sep 1 15:29:10 EDT 2023


Thank you Mark. I followed that explanation and now understand that - 
for all of my foreseeable applications - I can ignore 'is strictly a 
name' :-)

Paul

On 9/1/2023 1:23 PM, Mark Waddingham via use-livecode wrote:
> On 2023-09-01 17:44, Paul Dupuis via use-livecode wrote:
>> I may just be experiencing a brain fart, but I have read the release 
>> notes several times, and I don't understand the purpose of the new:
>>
>> is strictly a name
>>
>> operator? Can someone explain its purpose in really basic terms or 
>> examples?
>
> Its purposes is so that it is possible to tell when a value is a 
> 'name' rather than a 'string' when the distinction is important. The 
> cases where this is true are few and far between - indeed, the 
> use-case it was added for was so that the exact runtime type of 
> constant values generated when parsing script (e.g. from constant 
> initializers) is preserved.
>
> There are two kinds of strings internally - strings and names. All 
> names are strings, but not all strings are names.
>
> The difference is that there is only ever one instance of a name with 
> a given string in memory - e.g. if two variables hold a name whose 
> string is "foo", then they will hold the same pointer.
>
> As to what names are - they are an optimization for cases where the 
> engine will often do comparisons between them.
>
> Names are implemented in a global hash table in such a way that 
> caseless and case-sensitive comparisons are constant time (when both 
> values being compared are names).
>
> The keys of an array are names - which means the engine never has to 
> compare the actual characters of a key in an array as it does a lookup.
>
> Literals in scripts are stored as names - so if you have 100 instances 
> of the string constant "foobar" throughout all your scripts as 
> literals - there will only actually be one instance of "foobar"
>
> Similarly, internally, object names, handler names and variable names 
> are all stored as, well, names (again - because they are commonly 
> compared against each other).
>
> Some examples of where you can observe a name are:
>
>    put "foo" is strictly a name => true
>
>    put ("foo" & empty) is strictly a name => false
>
>    repeat for each key tFoo in { "foo": true }
>      put tFoo is a strictly a name => true
>    end repeat
>
> There might be a few other places where you could see a name rather 
> than a string, but as mentioned above - its unlikely that 99.9% of 
> people would ever need to worry about it :)
>
> Warmest Regards,
>
> Mark.
>




More information about the use-livecode mailing list