Overriding Map/etc with get/set hooks?
allen at wirfs-brock.com
Wed May 22 02:21:23 PDT 2013
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss