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

Brendan Eich brendan at mozilla.com
Thu Sep 29 13:30:34 PDT 2011


On Sep 29, 2011, at 9:03 PM, Sean Eagan wrote:

> On Mon, Sep 26, 2011 at 7:27 PM, Waldemar Horwat <waldemar at google.com> wrote:
>> Reached consensus on the following # proposal:
>> # before an object literal seals the object
>> # before a propoerty makes that property nonconfigurable and nonwritable.
>> All method properties are nonenumerable.
>> All value properties are enumerable.
> 
> I like it!  Here are some extensions to consider:
> 
> # to seal, ## to freeze:

Too much chicken-scratching. It's tempting but I think we should focus on one funny prefix char per special form and make it count, optimize for the common case. Uncommon cases use APIs.


> ##{
>  p: 1,
>  m() {}
> }
> 
> # non-configurable, ## non-writable as well:
> {
>  #p: 1,
>  ##m() {}
> }

These do regularize things from the consensus Waldemar recorded: you need one # to seal, two to freeze, whether property or object. But the consensus we reached was aimed at common use-cases. The idea is that sealing an object is more common than freezing it, while freezing a property is more common than sealing it.


> Extend to other literal forms ala <|:
> 
> #[a, b, c]
> #function(){...}
> #/\d+/
> #1
> #""
> #true

We don't want # as a prefix for value types. I did propose in HoMD that we support #(a,b){...} but that fell to completion leak concerns and the desire of some for shorter syntax without freezing/joining (so without # prefix in this scenario, but (a){} is ambiguous with current JS if you insert a newline between the ) and the {).


> Compose with <|:
> 
> null <| ##{...} // record-esque
> null <| ##[...] // tuple-esque

These are too long if common, they want the HoMD single # prefixing.


> 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.

/be


More information about the es-discuss mailing list