On May 22, 2013, at 5:20 AM, Ron Buckton wrote: > What if the default Map prototype had a configurable but non-writable data > property for a @@coerceKey symbol that pointed to a default coercion > function. You could subclass Map and provide your own @@coerceKey > implementation. Then Map.prototype.set.call() would be forced to run the > custom coercion function. > > A @@coerceKey override could be used to coerce keys from one type to another, > or to provide key validation if you want keys in a specific format. By > providing a default implementation that is basically an identity function, > you maintain the same current expectations for Map. This then gives > developers the ability to further customize the behavior of Map in > subclasses, giving the class more flexibility.
It's an old Smalltalk trick to use subclass refinement hooks like this. Whether they make sense or not is largely dependent upon how common the use case is for that dimension of variability in subclasses. Having them adds both complexity and probably a bit of a performance hit. It is probably a reasonable design choice if the hook is frequently needed. I don't think we have enough data to say whether this will be the case for Map. My inclination would be to leave things as they are for now and see how actual usage evolves. These sorts of hooks are backwards compatible extensions that can always be added in the future. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
