> On 9 May 2012 01:32, Brendan Eich<brendan@...> wrote:
>> We could indeed put type-reflecting method(s) there but I'm
>> loath to add manifest constants. What's wrong with strings?
> Depends on the mechanism. If it is supposed to be user-extensible
> (i.e. an open set) then strings are bad because there might be clashes
> between extensions made by separate libraries. With constants (or
> unique names) as denotations no such issue exists.
> IOW, strings don't scale well. They are only suitable for closed sets.
The problem is "who closes the set"? If the masses extend, you're right,
but strings still can be made to work with awful hacks such as Java's
reverse-DNS package naming. But I explicitly cited the set being closed
by TC39, edition by edition. This can be done well with strings or enums
of some kind (int-valued constants).
Then I argued strings win in the context of typeof.