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

[Brendan Eich]

On Sep 29, 2011, at 10:07 PM, Sean Eagan wrote:

> On Thu, Sep 29, 2011 at 3:30 PM, Brendan Eich <brendan at mozilla.com> wrote:
> 
>> The idea is that sealing an object is more common than freezing it, while freezing a property is more common than sealing it.
> 
> I was thinking freezing an object is more common than sealing, but #
> for freeze, ## for seal looks backwards anyways.

Yes, if we allow doubling then obviously two is colder than one ;-). But should we allow doubling? I was arguing against, on the basis that one ugly character is enough for the common case. This led to the irregular but use-case oriented (we think -- you could be right, we haven't measured and not enough code uses ES5 freeze and seal) consensus Waldemar reported.


> 
>> We don't want # as a prefix for value types.
> 
> Agree, but why not for at least Arrays if not Functions and Regexps as well ?

What about the function's .prototype object? Would that be sealed or frozen too? Perhaps not.

How about lastIndex updating on a #/.../g regexp?


> Probably shouldn't have <| for value types either then right ?

That's right, they are not objects.


> 
>>> Compose with <|:
>>> 
>>> null <| ##{...} // record-esque
>>> null <| ##[...] // tuple-esque
>> 
>> These are too long if common, they want the HoMD single # prefixing.
> 
> Agree.  I think composition with <| still is needed though for
> consistency with non-#-prefixed literals if nothing else.

It should work -- at first it looks like evaluation order will result in <| cloning the sealed (at least) RHS and then try to update its [[Prototype]], but that seems legal. [[Extensible]] = false does not prevent internal properties from changing. Should check with Allen on this, though.


> 
>>> Include tuple-isms for #[], ##[]:
>>> 
>>> holes => syntax error
>>> length cannot be greater than 2^32 - 1
>> 
>> Sure, this carries over for all tuple proposals (I assert). But we want shorter syntax, no doubled funny chars, no verbose regularity at the expense of common cases being relatively overlong.
> 
> So if #[] is added as shorthand for a sealed Array, do you agree that
> #[0,,1] should be a syntax error ?

I thought I just said so ("Sure, this carries over for all tuple proposals" in reply to your "holes => syntax error").

/be