> On Dec 20, 2018, at 11:24 AM, Geoffrey Garen <gga...@apple.com> wrote:
>>>> So hard to pronounce though! Why not UniqueString? It’s not quite as 
>>>> explicit but close enough. 
>>> Wouldn’t it be confusing to use UniqueString type for a string that is 
>>> *common* in order to save memory?
>> I would interpret it as UniqueString(foo) means “give me the unique copy of 
>> string foo”. You use a unique copy so you can use the same string in many 
>> places without wasting memory, or excess time on string compares. It’s used 
>> in many places, but there is only one. (Maybe we should call it 
>> HighlanderString? OK, not serious.)
> By definition, any string that has been uniqued is unique.
> So, maybe we like “unique” or maybe we don’t. But if we like “unique”, it’s 
> strictly better than “uniqued”.
>>> Personally, I like the AtomString proposal as it is close to the naming we 
>>> are used to and addresses the issue raised (atomic has a different meaning 
>>> with threading).
>>> Also, I had never heard of interned strings before.
> AtomicString has two features:
> (1) You do comparison by pointer / object identity;
> (2) You never allocate two objects for the same sequence of characters.
> JavaScript symbols offer (1) but avoid (2):
>       let a = Symbol(“The string of the past!”);
>       let b = Symbol(“The string of the past!”);
>       a == b; // false
>       a === b; // false
> Today we call (1) “UniquedStringImpl” and (1) + (2) “AtomicStringImpl”.
> If we rename (1) + (2) to “UniqueString” or “UniquedString”, we need a new 
> name for (1) alone.

It seems like (1) alone is not actually “uniqued". In the case of symbols at 
least, it's the opposite: the string deliberately kept distinct from all other 
strings of equal value, so pointer equality is used as a check for equality by 
pointer identity, rather than a shortcut for equality by value. 

From what I can tell, UniquedStringImpl exists mainly to be a base class for 
SymbolImpl and AtomicStringImpl. So you could imagine giving it a more verbose 
and explicit name, like PointerEqualityStringImpl. However, JSC seems to use 
UniquedStringImpl directly in a bunch of cases, I think to make it convenient 
for a property name to be either an AtomicString or a Symbol. Maybe a longer 
name for that case is ok?


webkit-dev mailing list

Reply via email to