# proposal extensions (Was: Re: Sep 26 meeting notes)

[Allen Wirfs-Brock]

On Sep 29, 2011, at 3:10 PM, Brendan Eich wrote:

> On Sep 29, 2011, at 11:03 PM, Brendan Eich wrote:
> 
>>> Probably shouldn't have <| for value types either then right ?
>> 
>> That's right, they are not objects.
> 
> Or hrm, now that you mention it Allen did spec these, and they get wrapped implicitly (string "foo" becomes new String("foo"), etc.).

I included them so we didn't have special cases for <|.  Any literal form can appear on the RHS.  My thinking was that there is some value to such consistency although I could also argue that saying (foo <| 1) is much more likely a mistake rather than a valid use case and hence it would be more beneficial to just make it an error. 

Was also trying to get rid of "non-subclassable" built-ins.  Allowing non-object to the right <| takes care of this for the wrapper built-ins.  However, I could also address this in the same way that I plan fix Date.  Just make their [[PrimativeValue]] a private named property.  Then
   let ExtendedNumber = Number <| function(val) {super.constructor(val)}
could would work for sublcassing Number, String, and Boolean as well as for Date.

> 
> I still find implicit primitive wrapping where the wrapper is observable raises my hackles. Anyone feel the same?

Yes, but we have them and I don't seen anyway to eliminate them.

Allen