The specification license issue

[musicdenotation]

Has the ECMAScript specification license problem been resolved? If so, how?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: TC39 vs "the community"

[Garrett Smith]

Nice.

I wonder what Horse would think of Vermin Supreme's pony identification program.

But in all seriousness, Google, MSFT, are all pushing for IoT or
"wearables" by putting on events featuring that, creating a buzz, and
making press on the event.

On 6/23/14, Brendan Eich  wrote:
> +1
>
> But Garrett's post was helpful in its own way. @horse_esdiscuss agrees!
>
> /be
>
> joe wrote:
>> And here I thought you were making an educated argument with your
>> explanation of the history of propaganda and public relations.  When I
>> first read "corporate propaganda," I thought you mean the
>> propaganda of JS developers, not commercial corporations.
>>
>> Frankly, I find the idea that commercial interests trump corporate
>> identity hard to fathom.  If that were true, Java would be a very
>> different language today, and JavaScript would have long fallen into
>> disuse. "The community," very much exists;  it's not a figment of some
>> PR type's imagination.  Anyone claiming there isn't a sense of
>> corporate identity among JS developers is fooling themselves.
>>
>> I'm on the side of TC39, by the way.  I don't believe in democracy in
>> software.  That's why we have standards organizations.
>>
>> Joe
>


-- 
Garrett
@xkit
ChordCycles.com
garretts.github.io
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Kevin Smith]

On Wed, Jun 25, 2014 at 4:50 PM, C. Scott Ananian 
wrote:

> @John Barton:  Yes, ideally that syntax would work as well when you don't
> need a namespace.  But sometimes you do need a namespace, even if you don't
> care precisely what it is:
> ```
> import {format} from 'url';
> import {format} from 'util';
> import {connect} from 'tls';
> import {connect} from 'net';
> import {fork} from 'cluster';
> import {fork} from 'child_process';
> // etc
> ```
>

I agree, and importing as a namespace is what ModuleImport is all about.
 Crazy idea:  what if we had this:

// ModuleImport: import Identifier from StringLiteral
import fs from "fs";
import url from "url";

And just got rid of the default monkey-business?  Simple, no confusion, no
refactoring hazards.

Do we *really* need assignable default exports?  If we could jettison that
feature, it would (as John points out) make all of this pain go away.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[C. Scott Ananian]

On Wed, Jun 25, 2014 at 6:17 PM, Brian Donovan  wrote:

> You don’t actually need a namespace for this, though it may be more
> convenient/aesthetically pleasing than the alternative:
>

"may"? (!)
 --scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Brian Donovan]

You don’t actually need a namespace for this, though it may be more
convenient/aesthetically pleasing than the alternative:

```
import {format as formatURL} from 'url';
import {format} from 'util';
import {connect as tlsConnect} from 'tls';
import {connect as netConnect} from 'net';
import {fork as clusterFork} from 'cluster';
import {fork} from 'child_process';
// etc
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[C. Scott Ananian]

@John Barton:  Yes, ideally that syntax would work as well when you don't
need a namespace.  But sometimes you do need a namespace, even if you don't
care precisely what it is:
```
import {format} from 'url';
import {format} from 'util';
import {connect} from 'tls';
import {connect} from 'net';
import {fork} from 'cluster';
import {fork} from 'child_process';
// etc
```
 --scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[John Barton]

// I have a module named `foo`.
// I don't care what `foo` is.
// Including whether or not its a namespace.
// I need make no promises about identifier `foo`.
import {bar} from './foo';


On Wed, Jun 25, 2014 at 12:52 PM, C. Scott Ananian 
wrote:

> On Wed, Jun 25, 2014 at 2:59 PM, Kevin Smith  wrote:
>
>> Correct me if I'm wrong, but the perspective says: "why would I need to
>> import the multiple-exports if I'm specifically overriding the exports with
>> a default?  Having a way to import both the default and multiple-exports is
>> silly and confusing."
>>
>
> For my part, my personal perspective is, "I have a module named `foo`.  I
> want to write `foo.bar` to get the export named bar.  I don't care *what*
> `foo` is.  Perhaps its a function object for backwards-compatibility.
>  Perhaps it's a module object because of some circular dependency.  Perhaps
> it's a plain object.  To me it's just a namespace.  Please let me use the
> same import syntax regardless.  In exchange, I promise never to use bare
> `foo` in my code."
>
> There are a couple of different solutions; default-default is one of those.
>  --scott
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Duplicate property names (was Re: @@new)

[Allen Wirfs-Brock]

right, typo now-> not

On Jun 25, 2014, at 12:36 PM, Erik Arvidsson wrote:

> On Wed, Jun 25, 2014 at 3:20 PM, Allen Wirfs-Brock  
> wrote:
> 
> I think "use strict" is a special care where we were trying to simulate what 
> we would allow in a statement composed of reserved words and escapes are now 
> allowed in keywords. 
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-reserved-words 
> 
> That says: "A code point in a ReservedWord cannot be expressed by a \ 
> UnicodeEscapeSequence." which fits with what I remember too.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[C. Scott Ananian]

On Wed, Jun 25, 2014 at 2:59 PM, Kevin Smith  wrote:

> Correct me if I'm wrong, but the perspective says: "why would I need to
> import the multiple-exports if I'm specifically overriding the exports with
> a default?  Having a way to import both the default and multiple-exports is
> silly and confusing."
>

For my part, my personal perspective is, "I have a module named `foo`.  I
want to write `foo.bar` to get the export named bar.  I don't care *what*
`foo` is.  Perhaps its a function object for backwards-compatibility.
 Perhaps it's a module object because of some circular dependency.  Perhaps
it's a plain object.  To me it's just a namespace.  Please let me use the
same import syntax regardless.  In exchange, I promise never to use bare
`foo` in my code."

There are a couple of different solutions; default-default is one of those.
 --scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Duplicate property names (was Re: @@new)

[Erik Arvidsson]

On Wed, Jun 25, 2014 at 3:20 PM, Allen Wirfs-Brock 
wrote:

>
> I think "use strict" is a special care where we were trying to simulate
> what we would allow in a statement composed of reserved words and escapes
> are now allowed in keywords.
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-reserved-words
>

That says: "A code point in a ReservedWord cannot be expressed by a \
UnicodeEscapeSequence." which fits with what I remember too.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Duplicate property names (was Re: @@new)

[Allen Wirfs-Brock]

On Jun 25, 2014, at 10:27 AM, Erik Arvidsson wrote:

> Allen,
> 
> > If propKey is the string value "__proto__"
> 
> Do we want to allow "__\u0070roto__" or not? For "use strict" we made it 
> clear that no escape sequences are allowed. I think we should follow that 
> route unless it makes implementation and/or speccing too hard.

I think the usual rules should apply.  LiteralPropertyName is either an 
IdentifierName or a StringLiteral.  
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-names-and-keywords 
says the escaped and non-escaped code points are equivalent within an 
IdentifierName.  
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-static-semantics-sv-s-and-cv-s
 says the the SV of is the same for a string containing non-escaped code points 
and a string containing escapes for the same code points.

That means that {__proto__: something}, {__\u0070roto__: something}, 
{"__proto__": something}, and {"__\u0070__": something} should all mean the 
same thing and if Annex B is being implemented that means they all do a 
[[SetPrototypeOf]].

I think "use strict" is a special care where we were trying to simulate what we 
would allow in a statement composed of reserved words and escapes are now 
allowed in keywords. 
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-reserved-words 

Allen








> 
> 
> On Wed, Jun 25, 2014 at 11:21 AM, Allen Wirfs-Brock  
> wrote:
> yes, this is covered by 
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-__proto__-property-names-in-object-initializers
>  
> 
> __proto__ only has special meaning within a production:
> 
>   PropertyDefiniton : PropertyName ":" AssignmentExpression
> 
> and when PropertyName is not a ComputedPropertyName.
> 
> All other PropertyDefinition forms that have __proto__ as the property name 
> (whether literally or as a ComputedPropertyName)  just define ordinary 
> properties with the name "__proto__".
> 
> The current non-duplicated name restriction made it illegal to have more than 
> one __proto__ : something property definitions in an object literal. Because 
> __proto__: something is a special form with its own semantics I think we 
> should continue to make it illegal to have more than one of them, even when 
> we relax the duplicate rule for regular property definitions.
> 
> Allen
> 
> 
> On Jun 25, 2014, at 8:09 AM, Erik Arvidsson wrote:
> 
>> If I recall correctly the intent was that __proto__ was special syntax for 
>> setting the [[Prototype]]. So only three following cases are setting the 
>> [[Prototype]]
>> 
>> {__proto__: object}
>> {'__proto__': object}
>> {"__proto__": object}
>> 
>> Other combinations set an own property:
>> 
>> {['__proto__']: object}
>> {'__\u0070roto__]: object}
>> {__proto__() {}}
>> var __proto__;
>> {__proto__}
>> {get __proto__() {}}
>> {set __proto__(x) {}}
>> 
>> Combining these leads to confusing code (so don't do that) but the semantics 
>> is clear.
>> 
>> 
>> On Wed, Jun 25, 2014 at 9:27 AM, Andy Wingo  wrote:
>> On Wed 25 Jun 2014 15:19, Andy Wingo  writes:
>> 
>> > Hi,
>> >
>> > On Fri 20 Jun 2014 15:16, "Mark S. Miller"  writes:
>> >
>> >> On Fri, Jun 20, 2014 at 1:48 AM, Andy Wingo  wrote:
>> >> >
>> >> > There is one change:
>> >> >
>> >> > ({ foo: 3, get foo() { return 4 } })
>> >> >
>> >> This is not allowed with current sloppy mode.
>> >>
>> >> Yes, good catch. This is a change, and it is now allowed.
>> >
>> > What about:
>> >
>> >   ({ get __proto__() {}, __proto__: foo })  // (1)
>> >
>> > Does this end up setting the prototype of the result?  Would it if there
>> > were a setter?
>> >
>> > Likewise:
>> >
>> >   ({ __proto__: foo, get __proto__() {} })  // (2)
>> >
>> > This one is kinda similar:
>> >
>> >   ({ ['__proto__']: 34, __proto__: foo })   // (3)
>> 
>> And another one:
>> 
>>   ({ get __proto__() {}, __proto__: foo, set __proto__(x) {} })
>> 
>> Does the resulting accessor have a setter and a getter, or just a
>> setter?  I would think just a setter, in the same way that this one
>> would only have a setter:
>> 
>>   ({ get qux() {}, qux: foo, set qux(x) {} })
>> 
>> Andy
>> 
>> 
>> 
>> -- 
>> erik
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
> erik

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Kevin Smith]

> default-default is the least worst one I have heard that doesn't totally
> change everything,
>

Fair enough.  Thanks for putting up with my questioning - I think I have a
better understanding of where you and Scott are coming from now.

Correct me if I'm wrong, but the perspective says: "why would I need to
import the multiple-exports if I'm specifically overriding the exports with
a default?  Having a way to import both the default and multiple-exports is
silly and confusing."
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Calvin Metcalf]

default-default is the least worst one I have heard that doesn't totally
change everything,


On Wed, Jun 25, 2014 at 2:08 PM, Kevin Smith  wrote:

>
>>> One import syntax.  C'mon, we've been over this for *months* Kevin.
>>
>
> I get that, I really do.  But specifically, that would mean a
> default-default, right?
>
>


-- 
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Kevin Smith]

>
>
>> One import syntax.  C'mon, we've been over this for *months* Kevin.
>

I get that, I really do.  But specifically, that would mean a
default-default, right?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[C. Scott Ananian]

On Wed, Jun 25, 2014 at 1:38 PM, Kevin Smith  wrote:

>
>> the payoff is decoupling how something is imported from how something is
>> exported.
>>
>
> Maybe I'm being dense, but I must admit I find this statement to be
> completely baffling.  The import side always has to match the export side -
> how could it possibly be any different?  What am I missing here?
>

One import syntax.  C'mon, we've been over this for *months* Kevin.
  --scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Kevin Smith]

>
>
> the payoff is decoupling how something is imported from how something is
> exported.
>

Maybe I'm being dense, but I must admit I find this statement to be
completely baffling.  The import side always has to match the export side -
how could it possibly be any different?  What am I missing here?


> A module is a bag of names, but there is no reason an import has to be as
> well.
>

Between the default import (which is what you want) and ModuleImport it
seems that all of our bases are covered.  What's the problem, then?

Is it merely that you want a default-default?  Is that the only issue for
you?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Duplicate property names (was Re: @@new)

[Erik Arvidsson]

Allen,

> If propKey is the string value "__proto__"

Do we want to allow "__\u0070roto__" or not? For "use strict" we made it
clear that no escape sequences are allowed. I think we should follow that
route unless it makes implementation and/or speccing too hard.


On Wed, Jun 25, 2014 at 11:21 AM, Allen Wirfs-Brock 
wrote:

> yes, this is covered by
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-__proto__-property-names-in-object-initializers
>
>
> __proto__ only has special meaning within a production:
>
>   PropertyDefiniton : PropertyName ":" AssignmentExpression
>
> and when PropertyName is not a ComputedPropertyName.
>
> All other PropertyDefinition forms that have __proto__ as the property
> name (whether literally or as a ComputedPropertyName)  just define ordinary
> properties with the name "__proto__".
>
> The current non-duplicated name restriction made it illegal to have more
> than one __proto__ : something property definitions in an object literal.
> Because __proto__: something is a special form with its own semantics I
> think we should continue to make it illegal to have more than one of them,
> even when we relax the duplicate rule for regular property definitions.
>
> Allen
>
>
> On Jun 25, 2014, at 8:09 AM, Erik Arvidsson wrote:
>
> If I recall correctly the intent was that __proto__ was special syntax for
> setting the [[Prototype]]. So only three following cases are setting the
> [[Prototype]]
>
> {__proto__: object}
>  {'__proto__': object}
> {"__proto__": object}
>
> Other combinations set an own property:
>
> {['__proto__']: object}
> {'__\u0070roto__]: object}
> {__proto__() {}}
> var __proto__;
> {__proto__}
> {get __proto__() {}}
> {set __proto__(x) {}}
>
> Combining these leads to confusing code (so don't do that) but the
> semantics is clear.
>
>
> On Wed, Jun 25, 2014 at 9:27 AM, Andy Wingo  wrote:
>
>> On Wed 25 Jun 2014 15:19, Andy Wingo  writes:
>>
>> > Hi,
>> >
>> > On Fri 20 Jun 2014 15:16, "Mark S. Miller"  writes:
>> >
>> >> On Fri, Jun 20, 2014 at 1:48 AM, Andy Wingo  wrote:
>> >> >
>> >> > There is one change:
>> >> >
>> >> > ({ foo: 3, get foo() { return 4 } })
>> >> >
>> >> This is not allowed with current sloppy mode.
>> >>
>> >> Yes, good catch. This is a change, and it is now allowed.
>> >
>> > What about:
>> >
>> >   ({ get __proto__() {}, __proto__: foo })  // (1)
>> >
>> > Does this end up setting the prototype of the result?  Would it if there
>> > were a setter?
>> >
>> > Likewise:
>> >
>> >   ({ __proto__: foo, get __proto__() {} })  // (2)
>> >
>> > This one is kinda similar:
>> >
>> >   ({ ['__proto__']: 34, __proto__: foo })   // (3)
>>
>> And another one:
>>
>>   ({ get __proto__() {}, __proto__: foo, set __proto__(x) {} })
>>
>> Does the resulting accessor have a setter and a getter, or just a
>> setter?  I would think just a setter, in the same way that this one
>> would only have a setter:
>>
>>   ({ get qux() {}, qux: foo, set qux(x) {} })
>>
>> Andy
>>
>
>
>
> --
> erik
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>


-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: ModuleImport

[Domenic Denicola]

From: es-discuss  on behalf of Calvin Metcalf 


> the payoff is decoupling how something is imported from how something is 
> exported.

+1. Although I am uneasy about the default-default export idea, since it has 
[several edge cases][1] that make it seem too messy for a language-level 
feature, it does fix the major problem of encapsulation breakage that the 
current design introduces. Having to know how the module author wrote their 
code, and using the correct import form based on that, is frustrating and a 
regression from current CommonJS/AMD module usability.

[1]: https://gist.github.com/domenic/23dfe87fc921735de04c
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Calvin Metcalf]

import 'foo'
let foo = this.get('foo')

 that was what came out of the last meeting to replace module/from semantics

the payoff is decoupling how something is imported from how something is
exported.  A module is a bag of names, but there is no reason an import has
to be as well.




On Wed, Jun 25, 2014 at 11:15 AM, Kevin Smith  wrote:

>
> import 'foo'
>>> let foo = this.get('foo')
>>>
>>
> To be less flippant, this isn't a solution to the problem:  how do I
> statically bind to a module instance object?  It's a runtime workaround.
>
> Default-default aside, what's the payoff in trying to obscure the fact
> that a module is always a named set of exported bindings?
>
>


-- 
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Duplicate property names (was Re: @@new)

[Allen Wirfs-Brock]

yes, this is covered by 
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-__proto__-property-names-in-object-initializers
 

__proto__ only has special meaning within a production:

  PropertyDefiniton : PropertyName ":" AssignmentExpression

and when PropertyName is not a ComputedPropertyName.

All other PropertyDefinition forms that have __proto__ as the property name 
(whether literally or as a ComputedPropertyName)  just define ordinary 
properties with the name "__proto__".

The current non-duplicated name restriction made it illegal to have more than 
one __proto__ : something property definitions in an object literal. Because 
__proto__: something is a special form with its own semantics I think we should 
continue to make it illegal to have more than one of them, even when we relax 
the duplicate rule for regular property definitions.

Allen


On Jun 25, 2014, at 8:09 AM, Erik Arvidsson wrote:

> If I recall correctly the intent was that __proto__ was special syntax for 
> setting the [[Prototype]]. So only three following cases are setting the 
> [[Prototype]]
> 
> {__proto__: object}
> {'__proto__': object}
> {"__proto__": object}
> 
> Other combinations set an own property:
> 
> {['__proto__']: object}
> {'__\u0070roto__]: object}
> {__proto__() {}}
> var __proto__;
> {__proto__}
> {get __proto__() {}}
> {set __proto__(x) {}}
> 
> Combining these leads to confusing code (so don't do that) but the semantics 
> is clear.
> 
> 
> On Wed, Jun 25, 2014 at 9:27 AM, Andy Wingo  wrote:
> On Wed 25 Jun 2014 15:19, Andy Wingo  writes:
> 
> > Hi,
> >
> > On Fri 20 Jun 2014 15:16, "Mark S. Miller"  writes:
> >
> >> On Fri, Jun 20, 2014 at 1:48 AM, Andy Wingo  wrote:
> >> >
> >> > There is one change:
> >> >
> >> > ({ foo: 3, get foo() { return 4 } })
> >> >
> >> This is not allowed with current sloppy mode.
> >>
> >> Yes, good catch. This is a change, and it is now allowed.
> >
> > What about:
> >
> >   ({ get __proto__() {}, __proto__: foo })  // (1)
> >
> > Does this end up setting the prototype of the result?  Would it if there
> > were a setter?
> >
> > Likewise:
> >
> >   ({ __proto__: foo, get __proto__() {} })  // (2)
> >
> > This one is kinda similar:
> >
> >   ({ ['__proto__']: 34, __proto__: foo })   // (3)
> 
> And another one:
> 
>   ({ get __proto__() {}, __proto__: foo, set __proto__(x) {} })
> 
> Does the resulting accessor have a setter and a getter, or just a
> setter?  I would think just a setter, in the same way that this one
> would only have a setter:
> 
>   ({ get qux() {}, qux: foo, set qux(x) {} })
> 
> Andy
> 
> 
> 
> -- 
> erik
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Duplicate property names (was Re: @@new)

[Andy Wingo]

On Wed 25 Jun 2014 17:09, Erik Arvidsson  writes:

> If I recall correctly the intent was that __proto__ was special syntax
> for setting the [[Prototype]]. So only three following cases are setting
> the [[Prototype]]
>
> {__proto__: object}
> {'__proto__': object}
> {"__proto__": object}
>
> Other combinations set an own property [...]  Combining these leads to
> confusing code (so don't do that) but the semantics is clear.

I'm glad that the semantics are clear to you ;-)) The tricky case is not
__proto__ in isolation; it's how it interacts with other defined
properties.  Particularly, from my mail:

> ({ get __proto__() {}, __proto__: foo, set __proto__(x) {} })
> 
> Does the resulting accessor have a setter and a getter, or just a
> setter?

What do you think should happen in this case?

Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Kevin Smith]

> import 'foo'
>> let foo = this.get('foo')
>>
>
To be less flippant, this isn't a solution to the problem:  how do I
statically bind to a module instance object?  It's a runtime workaround.

Default-default aside, what's the payoff in trying to obscure the fact that
a module is always a named set of exported bindings?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Duplicate property names (was Re: @@new)

[Erik Arvidsson]

If I recall correctly the intent was that __proto__ was special syntax for
setting the [[Prototype]]. So only three following cases are setting the
[[Prototype]]

{__proto__: object}
{'__proto__': object}
{"__proto__": object}

Other combinations set an own property:

{['__proto__']: object}
{'__\u0070roto__]: object}
{__proto__() {}}
var __proto__;
{__proto__}
{get __proto__() {}}
{set __proto__(x) {}}

Combining these leads to confusing code (so don't do that) but the
semantics is clear.


On Wed, Jun 25, 2014 at 9:27 AM, Andy Wingo  wrote:

> On Wed 25 Jun 2014 15:19, Andy Wingo  writes:
>
> > Hi,
> >
> > On Fri 20 Jun 2014 15:16, "Mark S. Miller"  writes:
> >
> >> On Fri, Jun 20, 2014 at 1:48 AM, Andy Wingo  wrote:
> >> >
> >> > There is one change:
> >> >
> >> > ({ foo: 3, get foo() { return 4 } })
> >> >
> >> This is not allowed with current sloppy mode.
> >>
> >> Yes, good catch. This is a change, and it is now allowed.
> >
> > What about:
> >
> >   ({ get __proto__() {}, __proto__: foo })  // (1)
> >
> > Does this end up setting the prototype of the result?  Would it if there
> > were a setter?
> >
> > Likewise:
> >
> >   ({ __proto__: foo, get __proto__() {} })  // (2)
> >
> > This one is kinda similar:
> >
> >   ({ ['__proto__']: 34, __proto__: foo })   // (3)
>
> And another one:
>
>   ({ get __proto__() {}, __proto__: foo, set __proto__(x) {} })
>
> Does the resulting accessor have a setter and a getter, or just a
> setter?  I would think just a setter, in the same way that this one
> would only have a setter:
>
>   ({ get qux() {}, qux: foo, set qux(x) {} })
>
> Andy
>



-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Duplicate property names (was Re: @@new)

[Andy Wingo]

On Wed 25 Jun 2014 15:19, Andy Wingo  writes:

> Hi,
>
> On Fri 20 Jun 2014 15:16, "Mark S. Miller"  writes:
>
>> On Fri, Jun 20, 2014 at 1:48 AM, Andy Wingo  wrote:
>> >
>> > There is one change:
>> > 
>> > ({ foo: 3, get foo() { return 4 } })
>> > 
>> This is not allowed with current sloppy mode.
>>
>> Yes, good catch. This is a change, and it is now allowed.
>
> What about:
>
>   ({ get __proto__() {}, __proto__: foo })  // (1)
>
> Does this end up setting the prototype of the result?  Would it if there
> were a setter?
>
> Likewise:
>
>   ({ __proto__: foo, get __proto__() {} })  // (2)
>
> This one is kinda similar:
>
>   ({ ['__proto__']: 34, __proto__: foo })   // (3)

And another one:

  ({ get __proto__() {}, __proto__: foo, set __proto__(x) {} })

Does the resulting accessor have a setter and a getter, or just a
setter?  I would think just a setter, in the same way that this one
would only have a setter:

  ({ get qux() {}, qux: foo, set qux(x) {} })

Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Duplicate property names (was Re: @@new)

[Andy Wingo]

Hi,

On Fri 20 Jun 2014 15:16, "Mark S. Miller"  writes:

> On Fri, Jun 20, 2014 at 1:48 AM, Andy Wingo  wrote:
> >
> > There is one change:
> > 
> > ({ foo: 3, get foo() { return 4 } })
> > 
> This is not allowed with current sloppy mode.
>
> Yes, good catch. This is a change, and it is now allowed.

What about:

  ({ get __proto__() {}, __proto__: foo })  // (1)

Does this end up setting the prototype of the result?  Would it if there
were a setter?

Likewise:

  ({ __proto__: foo, get __proto__() {} })  // (2)

This one is kinda similar:

  ({ ['__proto__']: 34, __proto__: foo })   // (3)

I would propose that the answers to the question "does the prototype get
set" be "yes" for all of these, since the model is that each one is like
an invocation of Object.defineProperty, with the exception that
__proto__ is clownshoes-special and that a getter or setter inherits the
setter or getter (respectively) of the currently installed property, if
any.

Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Kevin Smith]

>
> import 'foo'
> let foo = this.get('foo')
>

Please no.  Just...no.

: )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Calvin Metcalf]

The

import 'foo'
let foo = this.get('foo')

Is less of a hassle if you only need it for when you have default and named
exports and need the module object.
 On Jun 25, 2014 7:48 AM, "Kevin Smith"  wrote:

> But if modules were said to have a default default export that was an
>> object with all the exports that could be overridden then that's different.
>>
> I see where you're coming from, and honestly I don't have a better
> argument against a default default.  (I actually tried to argue for that
> once upon a time.)
>
> In any case, I still think the design is not complete unless you have
> *some* way to access the module instance object (even in the case where the
> default has been "overridden"), so we still need ModuleImport.
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Kevin Smith]

>
> But if modules were said to have a default default export that was an
> object with all the exports that could be overridden then that's different.
>
I see where you're coming from, and honestly I don't have a better argument
against a default default.  (I actually tried to argue for that once upon a
time.)

In any case, I still think the design is not complete unless you have
*some* way to access the module instance object (even in the case where the
default has been "overridden"), so we still need ModuleImport.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Calvin Metcalf]

Thanks Kevin.

Back to bikeshedding import export syntax.

The refactoring hazards of defaulting to an object with all the exports are
going to depend on how the feature is described, talking in terms of
looking first for a default export and then returning the module body and
now you get unforseen changes when you add an export named default.

But if modules were said to have a default default export that was an
object with all the exports that could be overridden then that's different.

Adding an export named default and the import changed is unexpected,
overriding the default export and the default import changed, on the other
hand, is not unexpected behavior.
On Jun 24, 2014 10:48 PM, "Kevin Smith"  wrote:

>
> Side note: is that legal?  I assumed you wouldn't be able to do that due
>> to default being a reserved word.
>>
> Definitely.  Exports can be named any IdentifierName, so all of this is
> valid:
>
> export { foo as class, bar as switch, baz as default };
>
> And you can import IdentifierNames as well:
>
> import { class as foo, switch as bar, default as baz } from "wherever";
>
> **Here's the crucial point:**
>
> In fact, the default export is nothing other than an export named
> "default".  These two import declarations are *entirely* equivalent:
>
> import { default as whatever } from "module";
> import whatever from "module";
>
> Does that make sense?
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Module Default Export Syntax

[Claude Pache]

Le 25 juin 2014 à 11:16, Calvin Metcalf  a écrit :

> The place where the current syntax shines is when dealing with anonymous 
> values, 
> 
For that case, the same sugar as named exports could work:

export let default = ...

at the condition to allow "default" as an identifier in that position.

BTW, I agree with Kevin that the sugar for default export is not worth the 
obfuscation of the design.

—Claude



> On Jun 25, 2014 1:29 AM, "Barronville, Jonathan"  
> wrote:
> Kevin, you're not alone :) . I like that last form, too.
> 
> - Jonathan
> —
> Sent from Mailbox
> 
> 
> On Wed, Jun 25, 2014 at 1:21 AM, Axel Rauschmayer  wrote:
> 
> I do like the conciseness of the last form. The other forms do indeed not 
> seem very useful.
> 
> 
> On Jun 25, 2014, at 5:45 , Kevin Smith  wrote:
> 
>> 
>> ExportDeclaration:
>> ...
>> export default ClassDeclaration
>> export default FunctionDeclaration
>> export default GeneratorDeclaration
>> export default = AssignmentExpression
>> 
>> 
>> To reply to myself (since no one else appears to be interested), I think it 
>> might even be best to drop these special forms altogether.  The non-sugared 
>> form of:
>> 
>> export { someVar as default };
>> 
>> is already very concise, and will help developers understand what this whole 
>> "default" thing is about.  The sugar appears to be obfuscating the design, 
>> and is doing more harm than good.
>> 
>> Again, thoughts?
>> 
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> -- 
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
> 
> 
> 
> 
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Module Default Export Syntax

[Calvin Metcalf]

The place where the current syntax shines is when dealing with anonymous
values,
On Jun 25, 2014 1:29 AM, "Barronville, Jonathan" 
wrote:

> Kevin, you're not alone :) . I like that last form, too.
>
> - Jonathan
> —
> Sent from Mailbox 
>
>
> On Wed, Jun 25, 2014 at 1:21 AM, Axel Rauschmayer 
> wrote:
>
>> I do like the conciseness of the last form. The other forms do indeed not
>> seem very useful.
>>
>> On Jun 25, 2014, at 5:45 , Kevin Smith  wrote:
>>
>>
>>> ExportDeclaration:
>>> ...
>>> export default ClassDeclaration
>>> export default FunctionDeclaration
>>> export default GeneratorDeclaration
>>> export default = AssignmentExpression
>>>
>>>
>> To reply to myself (since no one else appears to be interested), I think
>> it might even be best to drop these special forms altogether.  The
>> non-sugared form of:
>>
>> export { someVar as default };
>>
>> is already very concise, and will help developers understand what this
>> whole "default" thing is about.  The sugar appears to be obfuscating the
>> design, and is doing more harm than good.
>>
>> Again, thoughts?
>>
>>  ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>  --
>> Dr. Axel Rauschmayer
>> a...@rauschma.de
>> rauschma.de
>>
>>
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss