> 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? Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev