date:20111102

On Nov 2, 2011, at 10:38 PM, Matthew Tretter wrote:

> Introducing yet another syntax for creating a function feels like bloat to 
> me. 

It's not just for creating a function. Method definition syntax was proposed a 
while ago and it makes the method non-enumerable and binds super correctly. 
Please don't treat it as just short for ': function' (although that is 
approximately 10 chars too long at scale :-|).

/be

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

Re: Minimalist Classes

2011-11-02 Thread Matthew Tretter

I'm totally in agreement with Jeremy's "class id objectLiteral" proposal, but 
for one thing: don't give up on your function definition syntax yet!

I really don't see any reason for adding a new way to define function 
(methods).  This:

   class Runner {
   run(a) {
  }
   }

is just as clearly expressed as this:

   class Runner {
   run: function(a) {
   }
   }

Granted, if we went with the latter, there's slightly more to type BUT 1) it's 
immediately clear to all JavaScript developers what's going on and how to work 
with it and 2) there are already several good proposals for function definition 
shorthands (arrow syntax and block lambdas). As I said on the github thread, we 
need to take a holistic view here and not lose sight of its effects on the rest 
of the language. For example, with block lambdas:

   class Runner {
   run: {| a |
   }
   }

Introducing yet another syntax for creating a function feels like bloat to me.  
Also, I bet we would start seeing a lot of "run(a){…}" attempts at function 
definitions in a non-class context.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minimalist Classes

Last followup for tonight:

$ git diff
diff --git a/minimalist-classes.js b/minimalist-classes.js
index 7d8195e..d6bdab2 100644
--- a/minimalist-classes.js
+++ b/minimalist-classes.js
@@ -212,9 +212,9 @@ class Monster {
 
   public flair, // you should have 37 pieces of public flair
 
-  constructor(name, health) {
-@name = name;
-@health = health;
+  // Yes, shorthand for @name = name given formal param name, etc. -- just as
+  // in CoffeeScript!
+  constructor(@name, @health) {
 @flair = 0;
   }
 
$ git commit -a -m"constructor(@foo) shorthand."
[master 7d1228f] constructor(@foo) shorthand.
 1 files changed, 3 insertions(+), 3 deletions(-)

/be


On Nov 2, 2011, at 7:02 PM, Brendan Eich wrote:

> On Nov 2, 2011, at 7:00 PM, Brendan Eich wrote:
> 
>> Updated: https://gist.github.com/1332193
>> 
>> $ git commit -a -m"Updates per conversations with @dflanagan and @allenwb."
>> 
>> git diff output below. Exec. summary: prefix groups via { ... } and public 
>> @-namespace population to avoid "this." sad-making verbosity.
>> 
>> /be
>> 
>> diff --git a/minimalist-classes.js b/minimalist-classes.js
>> index 18a7a8c..6f25144 100644
>> --- a/minimalist-classes.js
>> +++ b/minimalist-classes.js
>> @@ -188,8 +188,11 @@ class Monster {
>>  // See the new sameName method for an example of infix and prefix @ in 
>> action.
>>  //
>>  // David Flanagan suggests keeping the unary-prefix @foo shorthand, but 
>> making
>> -// the long-hand obj.@foo. Breaks E4X but no matter -- I'm open to it, but 
>> it
>> -// is not essential to bikeshed here.
>> +// the long-hand obj.@foo. Breaks E4X but no matter -- but the win is that 
>> the
>> +// [no LineTerminator here] restriction on the left of unary-prefix @ is not
>> +// needed. Also the references don't grep like email addresses, which counts
>> +// with David and me. So I've incorporated David's suggestion. See 
>> other.@name
>> +// etc. below.
>>  //
>>  // There is no const instance variable declaration. Non-writable instance 
>> vars
>>  // (properties to most people) are quite rare. Use ES5's 
>> Object.defineProperty
>> @@ -203,15 +206,17 @@ class Monster {
>>  
>>  class Monster {
>>  
>> -  private name, health;
>> +  private { name, health }, // can group a prefix, same for const and static
>> +  public flair, // you should have 37 pieces of public flair
>>  
>>constructor(name, health) {
>>  @name = name;
>>  @health = health;
>> +@flair = 0;
>>}
>>  
>>sameName(other) {
>> -return @name === other@name;
>> +return @name === other.@name;
>>}
>>  
>>private attackHelper(target) {
>> 
> 
> Quick followup:
> 
> $ git diff
> diff --git a/minimalist-classes.js b/minimalist-classes.js
> index 6f25144..7d8195e 100644
> --- a/minimalist-classes.js
> +++ b/minimalist-classes.js
> @@ -206,7 +206,10 @@ class Monster {
>  
>  class Monster {
>  
> -  private { name, health }, // can group a prefix, same for const and static
> +  private { name, health }  // can group a prefix, same for const and static
> +// note comma optional after closing brace, as 
> for
> +// method definitions
> +
>public flair, // you should have 37 pieces of public flair
>  
>constructor(name, health) {
> $ git commit -a -m"More comma elision."
> [master 4f47332] More comma elision.
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> /be
> 
>> On Nov 1, 2011, at 6:56 PM, Brendan Eich wrote:
>> 
>>> On Nov 1, 2011, at 5:18 PM, Brendan Eich wrote:
>>> 
 On Oct 31, 2011, at 6:57 PM, Jeremy Ashkenas wrote:
 
> 'Evening, ES-Discuss.
> 
> After poking a stick in the bees' nest this morning (apologies, Allen), 
> and in the spirit of loyal opposition, it's only fair that I throw my hat 
> in the ring. 
> 
> Here is a proposal for minimalist JavaScript classes that enable behavior 
> that JavaScripters today desire (as evidenced by libraries and languages 
> galore), without adding any new semantics beyond what already exists in 
> ES3.
> 
> https://gist.github.com/1329619
> 
> Let me know what you think, and feel free to fork.
 
 Thanks, I did fork, and I made a Rich Corinthian Leather version, for the 
 reasons given in the comments. In brief, I contend that over-minimizing 
 will please no one: class haters still gonna hate, while class lovers used 
 to batteries-and-leather-included will find the bare sheet metal poky and 
 painful.
 
 Love it or hate it, I'm ok either way :-P. But I do crave intelligent 
 responses.
>>> 
>>> Handy link included: https://gist.github.com/1332193
>>> 
>>> /be
>>> 
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org

Re: Minimalist Classes

On Nov 2, 2011, at 7:00 PM, Brendan Eich wrote:

> Updated: https://gist.github.com/1332193
> 
> $ git commit -a -m"Updates per conversations with @dflanagan and @allenwb."
> 
> git diff output below. Exec. summary: prefix groups via { ... } and public 
> @-namespace population to avoid "this." sad-making verbosity.
> 
> /be
> 
> diff --git a/minimalist-classes.js b/minimalist-classes.js
> index 18a7a8c..6f25144 100644
> --- a/minimalist-classes.js
> +++ b/minimalist-classes.js
> @@ -188,8 +188,11 @@ class Monster {
>  // See the new sameName method for an example of infix and prefix @ in 
> action.
>  //
>  // David Flanagan suggests keeping the unary-prefix @foo shorthand, but 
> making
> -// the long-hand obj.@foo. Breaks E4X but no matter -- I'm open to it, but it
> -// is not essential to bikeshed here.
> +// the long-hand obj.@foo. Breaks E4X but no matter -- but the win is that 
> the
> +// [no LineTerminator here] restriction on the left of unary-prefix @ is not
> +// needed. Also the references don't grep like email addresses, which counts
> +// with David and me. So I've incorporated David's suggestion. See 
> other.@name
> +// etc. below.
>  //
>  // There is no const instance variable declaration. Non-writable instance 
> vars
>  // (properties to most people) are quite rare. Use ES5's 
> Object.defineProperty
> @@ -203,15 +206,17 @@ class Monster {
>  
>  class Monster {
>  
> -  private name, health;
> +  private { name, health }, // can group a prefix, same for const and static
> +  public flair, // you should have 37 pieces of public flair
>  
>constructor(name, health) {
>  @name = name;
>  @health = health;
> +@flair = 0;
>}
>  
>sameName(other) {
> -return @name === other@name;
> +return @name === other.@name;
>}
>  
>private attackHelper(target) {
> 

Quick followup:

$ git diff
diff --git a/minimalist-classes.js b/minimalist-classes.js
index 6f25144..7d8195e 100644
--- a/minimalist-classes.js
+++ b/minimalist-classes.js
@@ -206,7 +206,10 @@ class Monster {
 
 class Monster {
 
-  private { name, health }, // can group a prefix, same for const and static
+  private { name, health }  // can group a prefix, same for const and static
+// note comma optional after closing brace, as for
+// method definitions
+
   public flair, // you should have 37 pieces of public flair
 
   constructor(name, health) {
$ git commit -a -m"More comma elision."
[master 4f47332] More comma elision.
 1 files changed, 4 insertions(+), 1 deletions(-)

/be

> On Nov 1, 2011, at 6:56 PM, Brendan Eich wrote:
> 
>> On Nov 1, 2011, at 5:18 PM, Brendan Eich wrote:
>> 
>>> On Oct 31, 2011, at 6:57 PM, Jeremy Ashkenas wrote:
>>> 
 'Evening, ES-Discuss.
 
 After poking a stick in the bees' nest this morning (apologies, Allen), 
 and in the spirit of loyal opposition, it's only fair that I throw my hat 
 in the ring. 
 
 Here is a proposal for minimalist JavaScript classes that enable behavior 
 that JavaScripters today desire (as evidenced by libraries and languages 
 galore), without adding any new semantics beyond what already exists in 
 ES3.
 
 https://gist.github.com/1329619
 
 Let me know what you think, and feel free to fork.
>>> 
>>> Thanks, I did fork, and I made a Rich Corinthian Leather version, for the 
>>> reasons given in the comments. In brief, I contend that over-minimizing 
>>> will please no one: class haters still gonna hate, while class lovers used 
>>> to batteries-and-leather-included will find the bare sheet metal poky and 
>>> painful.
>>> 
>>> Love it or hate it, I'm ok either way :-P. But I do crave intelligent 
>>> responses.
>> 
>> Handy link included: https://gist.github.com/1332193
>> 
>> /be
>> 
>> ___
>> 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: Minimalist Classes

Updated: https://gist.github.com/1332193

$ git commit -a -m"Updates per conversations with @dflanagan and @allenwb."

git diff output below. Exec. summary: prefix groups via { ... } and public 
@-namespace population to avoid "this." sad-making verbosity.

/be

diff --git a/minimalist-classes.js b/minimalist-classes.js
index 18a7a8c..6f25144 100644
--- a/minimalist-classes.js
+++ b/minimalist-classes.js
@@ -188,8 +188,11 @@ class Monster {
 // See the new sameName method for an example of infix and prefix @ in action.
 //
 // David Flanagan suggests keeping the unary-prefix @foo shorthand, but making
-// the long-hand obj.@foo. Breaks E4X but no matter -- I'm open to it, but it
-// is not essential to bikeshed here.
+// the long-hand obj.@foo. Breaks E4X but no matter -- but the win is that the
+// [no LineTerminator here] restriction on the left of unary-prefix @ is not
+// needed. Also the references don't grep like email addresses, which counts
+// with David and me. So I've incorporated David's suggestion. See other.@name
+// etc. below.
 //
 // There is no const instance variable declaration. Non-writable instance vars
 // (properties to most people) are quite rare. Use ES5's Object.defineProperty
@@ -203,15 +206,17 @@ class Monster {
 
 class Monster {
 
-  private name, health;
+  private { name, health }, // can group a prefix, same for const and static
+  public flair, // you should have 37 pieces of public flair
 
   constructor(name, health) {
 @name = name;
 @health = health;
+@flair = 0;
   }
 
   sameName(other) {
-return @name === other@name;
+return @name === other.@name;
   }
 
   private attackHelper(target) {

On Nov 1, 2011, at 6:56 PM, Brendan Eich wrote:

> On Nov 1, 2011, at 5:18 PM, Brendan Eich wrote:
> 
>> On Oct 31, 2011, at 6:57 PM, Jeremy Ashkenas wrote:
>> 
>>> 'Evening, ES-Discuss.
>>> 
>>> After poking a stick in the bees' nest this morning (apologies, Allen), and 
>>> in the spirit of loyal opposition, it's only fair that I throw my hat in 
>>> the ring. 
>>> 
>>> Here is a proposal for minimalist JavaScript classes that enable behavior 
>>> that JavaScripters today desire (as evidenced by libraries and languages 
>>> galore), without adding any new semantics beyond what already exists in ES3.
>>> 
>>> https://gist.github.com/1329619
>>> 
>>> Let me know what you think, and feel free to fork.
>> 
>> Thanks, I did fork, and I made a Rich Corinthian Leather version, for the 
>> reasons given in the comments. In brief, I contend that over-minimizing will 
>> please no one: class haters still gonna hate, while class lovers used to 
>> batteries-and-leather-included will find the bare sheet metal poky and 
>> painful.
>> 
>> Love it or hate it, I'm ok either way :-P. But I do crave intelligent 
>> responses.
> 
> Handy link included: https://gist.github.com/1332193
> 
> /be
> 
> ___
> 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: Globalization API working draft

2011-11-02 Thread David Herman

> I think we probably have an interesting question for Dave and Sam about how 
> to support version evolution of modules.  Is there a module equivalent of 
> monkey patching. What if we have an implementation that exposes a "V1" module 
> (particularly a built-in module) and code that depends upon upon a V2 of that 
> same module that has an expanded export list.  Is there anyway for that code 
> to patch the module to add the extra exported APIs it would like to use?

ES6 modules are not extensible, for a number of reasons including compile-time 
variable checking. But of course API evolution is critical, and it works; it 
just works differently. Monkey-patching says "let the polyfill add the module 
exports by mutation," e.g.:

// mypolyfill.js
...
if (!SomeBuiltinModule.newFeature) {
load("someotherlib.js", function(x) {
SomeBuiltinModule.newFeature = x;
});
}

you instead say "let the polyfill provide the exports," e.g.:

// mypolyfill.js
...
export let newFeature = SomeBuiltinModule.newFeature;
if (!newFeature) {
load("someotherlib.js", function(x) {
newFeature = x;
});
}

The difference is that clients import from the polyfill instead of importing 
from the builtin module. I'm not 100% satisfied with this, but it's not any 
more code than monkey-patching.

Dave

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

Re: Globalization API working draft

On Nov 2, 2011, at 4:51 PM, Nebojša Ćirić wrote:

> My main concern at the moment is ES5. It seems that best practice is to 
> declare [[Extensible]]:true, which would in turn avoid conflicts with 
> pre-existing globals and let developers append new functionality to 
> Globalization. We can deal with modules in the future revisions if necessary.

That's a fine approach if you really are making a spec that adds onto ES5. 
Depends on timing.

/be

> 
> 02. новембар 2011. 16.20, Brendan Eich  је написао/ла:
> On Nov 2, 2011, at 4:09 PM, Allen Wirfs-Brock wrote:
> 
> > Ideally, the globalization support would manifest as a global (or 
> > properties on an existing global) in ES5 implementations and as a module in 
> > ES.next.  Do we know how to actually make that work?
> 
> What we did talk about was exposing the system loader to unversioned script 
> through an API, say Object.System. Then you could Object.System.load("@g11n" 
> ...) and get stuff done. The built-ins should not require a callback
> 
> /be
> 
> 
> 
> 
> -- 
> Nebojša Ćirić
> ___
> 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: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

On Nov 2, 2011, at 1:27 PM, Mikeal Rogers wrote:

> On Nov 2, 2011, at November 2, 201110:57 AM, Brendan Eich wrote:
> 
>> [vtables vs. prototype properties performance stuff deleted]

>> This is a contrived case, but in general, because JS objects are mutable, 
>> and when they're used as prototypes they stand in for class vtables, 
>> something has to pay a price. Either you worry about checking on every 
>> d.m(i) call that the cached target method in b is still the one to call, or 
>> you emit code that doesn't check but tear it up and throw it away when c.m 
>> is injected and shadows b.m.
>> 
>> This is fine with me and worth the price, but it clearly is not for everyone.
> 
> I don't think I've ever heard an active JavaScript developer, who has been 
> programming in JavaScript longer than 6 months, ask for private class or 
> instance variables.

Why are you talking about private when I was talking about performance issues 
that might or might not be helped by freeze, seal, and const?

> Maybe you have, you talk to more people than I do. I do hear this a lot from 
> people who don't use JavaScript and likely won't even if we add it.

There are lots of people using the closure pattern precisely to have private 
instance variables. Crock's thin little book recommends it.

>> I'm not just talking about implementors, either. Some users will want to 
>> know d.m isn't going to change. They may not want to know that it's b.m, 
>> mind you -- they simply won't want that c.m assignment to be legal, or else 
>> if they do support such a thing, they don't want it to affect d's "vtable".
>> 
>> Ok, so such people should use another language than JS. Or, perhaps, they 
>> could freeze c and b.
> 
> I would argue that developers who rely on these kinds of assurances are 
> actually slowing down their own, and others, productivity. Assuming they 
> wrote the perfect method and it should never be changed is a grand claim for 
> anyone who isn't Donald Knuth. Assuming that the consumer of their code is 
> responsible for their own bugs if they introduce them with monkey patching 
> class methods seems fair.

Of course I agree, but one size does not fit all in JS. Again, "freedom" 
includes my ability to fence my yard.

If there's an enclosure movement, where the new lords of the land (who stole it 
fair and square) kick off the tenant farmers and close the commons, then we 
have a fight and I'm on the same side as you. But that's not what is threatened 
by providing fencing material and tools. Tools are not moral actors.

And really, who is going to enclose the commons and freeze everything? Google? 
Hah!

> I think this is what Jeremy is getting at, not having these features (or at 
> least obscuring their use to be a different, more explicit pattern, using 
> closures) actually leads to longer term productivity and sustainability in 
> the community and I tend to agree
> 
> I may have said this before, but the lack of these features may actually be 
> part of what has allowed JavaScript to thrive and, for lack of a better term, 
> to win. Jeremy brought up some compelling examples.

I am sure JS has thrived in part because I chose to make it monkey-patchable, 
but providing integrity features on an opt-in basis does not mean JS won't 
thrive. It might mean those users who in the future opt into freezing, etc. and 
make the world too cold find the users have gone to warmer climes on github. 
That'll be even more convincing proof of your conjecture.

>> Then they'd have parity, once V8 and other engines got around to optimizing 
>> accordingly. (It's bogus for you to infer too much from the state of 
>> optimization vs. new features.)
> 
> I was just trying to debunk the claim that these features are necessarily 
> faster and will vary with implementation. Most features can lend themselves 
> to optimizations but, as you pointed out, at what cost.

The VM game continues. My argument in favor of optional integrity features is 
not about performance, but performance can get better with more lock-down. 
Again see Dart and the bragging about it compared to JS. Not that this should 
matter or prevail forever!

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

Re: Globalization API working draft

2011-11-02 Thread Nebojša Ćirić

My main concern at the moment is ES5. It seems that best practice is to
declare [[Extensible]]:true, which would in turn avoid conflicts with
pre-existing globals and let developers append new functionality to
Globalization. We can deal with modules in the future revisions if
necessary.

02. новембар 2011. 16.20, Brendan Eich  је написао/ла:

> On Nov 2, 2011, at 4:09 PM, Allen Wirfs-Brock wrote:
>
> > Ideally, the globalization support would manifest as a global (or
> properties on an existing global) in ES5 implementations and as a module in
> ES.next.  Do we know how to actually make that work?
>
> What we did talk about was exposing the system loader to unversioned
> script through an API, say Object.System. Then you could
> Object.System.load("@g11n" ...) and get stuff done. The built-ins should
> not require a callback
>
> /be
>
>


-- 
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Globalization API working draft

On Nov 2, 2011, at 4:09 PM, Allen Wirfs-Brock wrote:

> Ideally, the globalization support would manifest as a global (or properties 
> on an existing global) in ES5 implementations and as a module in ES.next.  Do 
> we know how to actually make that work?

What we did talk about was exposing the system loader to unversioned script 
through an API, say Object.System. Then you could Object.System.load("@g11n" 
...) and get stuff done. The built-ins should not require a callback

/be

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

Re: Globalization API working draft

2011-11-02 Thread Allen Wirfs-Brock

On Nov 2, 2011, at 3:00 PM, Nebojša Ćirić wrote:

> We were told (I think by Allen) that setting [[Extensible]] to true would 
> conflict in some way with ES6 modules. I do agree it's a big restriction to 
> set it to false given how JavaScript works today.
> 
> So the question is - are we going to have problems with ES6 Modules is we set 
> this property to true? If so, is there another way of solving this problem?

I do recall that we talked about this at the meeting held at Google, but I 
don't remember the details.  I'm pretty sure that my first reaction would have 
been the same as Erik's but we also did talk about module implications.

Ideally, the globalization support would manifest as a global (or properties on 
an existing global) in ES5 implementations and as a module in ES.next.  Do we 
know how to actually make that work?

I think we probably have an interesting question for Dave and Sam about how to 
support version evolution of modules.  Is there a module equivalent of monkey 
patching. What if we have an implementation that exposes a "V1" module 
(particularly a built-in module) and code that depends upon upon a V2 of that 
same module that has an expanded export list.  Is there anyway for that code to 
patch the module to add the extra exported APIs it would like to use?

Allen  

> 
> 02. новембар 2011. 14.12, Erik Arvidsson  је 
> написао/ла:
> The draft has the following:
> 6 The Globalization Object
> 
> The Globalization object is a single object that has some named properties, 
> all of which are constructors.
> 
> The value of the [[Prototype]] internal property of the Globalization object 
> is the built-in Object prototype object specified by the ECMAScript Language 
> Specification. The value of the [[Extensible]] internal property is false.
> 
> This seems very bad and counter intuitive to how the web works. It would mean 
> that there is no way to fix the Globalization object for browsers that are 
> not fully up to date. Lets assume that in a future version of the spec the 
> Globalization object gains a new property. The standard way to handle this in 
> JS is to do:
> 
> if (!Globalization.newProperty) {
>   Globalization.newProperty = ...;
> }
> 
> This allows people to migrate to new features and it is how people gradually 
> started to use Array extras.
> 
> -- 
> erik
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
> Nebojša Ćirić
> ___
> 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: Globalization API working draft

On Nov 2, 2011, at 3:00 PM, Nebojša Ćirić wrote:

> We were told (I think by Allen) that setting [[Extensible]] to true would 
> conflict in some way with ES6 modules. I do agree it's a big restriction to 
> set it to false given how JavaScript works today.
> 
> So the question is - are we going to have problems with ES6 Modules is we set 
> this property to true? If so, is there another way of solving this problem?

Do you mean, are you (or all of us working on Ecma TC39 standards) going to 
make Globalization name an ES6 module? But that doesn't seem necessary. Users 
should declare

module G11N from "@g11n";

or

import {foo, bar, baz} from "@g11n";

and name the module in whatever scope they want.

If we try to pre-declare the module and force the name to "Globalization", then 
I agree with Erik -- not only are we making it hard to polyfill for v2 when 
running on G11N v1 -- we are stepping on a name that may be in use.

/be


> 
> 02. новембар 2011. 14.12, Erik Arvidsson  је 
> написао/ла:
> The draft has the following:
> 6 The Globalization Object
> 
> The Globalization object is a single object that has some named properties, 
> all of which are constructors.
> 
> The value of the [[Prototype]] internal property of the Globalization object 
> is the built-in Object prototype object specified by the ECMAScript Language 
> Specification. The value of the [[Extensible]] internal property is false.
> 
> This seems very bad and counter intuitive to how the web works. It would mean 
> that there is no way to fix the Globalization object for browsers that are 
> not fully up to date. Lets assume that in a future version of the spec the 
> Globalization object gains a new property. The standard way to handle this in 
> JS is to do:
> 
> if (!Globalization.newProperty) {
>   Globalization.newProperty = ...;
> }
> 
> This allows people to migrate to new features and it is how people gradually 
> started to use Array extras.
> 
> -- 
> erik
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
> Nebojša Ćirić
> ___
> 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: Minimalist Classes

On Nov 2, 2011, at 3:08 PM, David Flanagan wrote:

> On 11/2/11 11:16 AM, Brendan Eich wrote:
>> On Nov 2, 2011, at 10:52 AM, David Flanagan wrote:
>> 
>> 
>>>  Could they have initializers that were automatically included in the 
>>> constructor?
>> 
>> I answered that in a gist comment. Yes, I like the CoffeeScript 
>> constructor(@x, @y){} shorthand. Dart picked up on it, but requires this. 
>> instead of @. I'll put it in the gist.
>> 
>> 
> I saw the comment, I think.  What I meant here was initializer expressions 
> that are part of the 'private' declaration.  That is, can I write
> 
>private stack = [];
> 
> and have that initialization code automatically inserted (Java-like) into the 
> constructor for me?  I'm trying to understand whether private and static have 
> the same basic syntax in this proposal.

The problem with initialization of private vars outside of the constructor is 
the order dependency. Do private names with initializers get bound and 
initialized before entry to the constructor, independent of their order with 
respect to the constructor in the class body? I hope so, but that might seem 
confusing. Can an initializer refer to the value of a prior name, e.g.

  private stack = [], stack2 = @stack;

My gist does not show initializers for private names, and since I switched to 
object literal syntax with optional prefix keywords, the above should be

  private stack: [], private stack2: @stack, ...

That is, no ; at end, and private must be repeated as a property initialiser 
prefix (which sucks).

An alternative mentioned in some comments is to allow @name: value, and 
@method() {...}, to be used in class bodies to bind private names without 
having to pre-declare them with private name, method; declarations or the like. 
That avoids the problem but only if you are willing to initialize prototype 
private-named properties -- that's what these initialiser parts do.

If you want to declare private names in scope throughout the body (in all 
methods), initailized in the constructor via @name = value; assignment 
expression-statements, then you want something like a private name; 
declaration. But the declaration-style syntax, with semicolon at end, is at 
odds with the main object literal flow.

>>>  Plain 'x' is bound to the Name object and @x is the value of the property 
>>> with that name?  Is x a variable?
>> 
>> x is a const binding in the "@ scope" of the class body. It does not collide 
>> with any lexically bound x (formal parameter name, e.g.). That's important 
>> -- see the Monster constructor with its name and health parameters and 
>> private property names.
>> 
>> So, o@x is *not* o[x] for such a private-declared x.
>> 
> What I don't understand is whether the "@ scope" is a specification 
> abstraction, or whether it is visible to programmers.  If I declare a private 
> variable x, and there isn't any other x in scope, is x bound to a Name object 
> that I can use?

Only via @ -- not in other expressions or you collide @health and health.

> If not, is there any way I can access the automatically-created Name objects 
> so that I can share my private names with "friend" classes?

No, not in what I'm proposing. If you want that, you'll have to Name.create().

>> Some argue @ should work for any x, so if there were some x = "y" in scope, 
>> then o@x would be o[x] would be o.y. I think that's too error-prone. What if 
>> I typo @heath instead of @health and there's a non-private-declared heath in 
>> scope?
>> 
> That's where a 'public' declaration comes in!  'private x' binds x to a new 
> Name in @ scope.  And 'public y' binds y to "y" in @ scope.  Then make @ work 
> with any identifier declared private or public.  That would allow programmers 
> to elide the "this" but still have publicly visible properties.

Ok, that seems unproblematic at first glance.

> Resolution of identifiers in @ scope can happen at compile time, can't it?

Requirement!

>  That is, for the code "@x", x is just looked up in @ scope once when the 
> code is compiled, not dynamcally each time it is evaluated, right?

Absolutely.

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

Le 02/11/2011 22:56, Jake Verbaten a écrit :
>
>> I don't think I've ever heard an active JavaScript developer, who
>> has been programming in JavaScript longer than 6 months, ask for
>> private class or instance variables.
> Your own code:
> 
> https://github.com/mikeal/npmjs.org/commit/c0d9cc77e79504b9a7c23b4fac735dde97444054#L3R10
> Line 35, you define the function stopBuffering (keeping only
> relevant parts):
> 
> function File (options) {
>
>   var stopBuffering = function () {
> // ...
>   }
>
> }
> 
> Why didn't you do this.stopBuffering = function(){}?
>
> Maybe you used the keyword "var", but you effectively created a
> private method of your "File" class. With a class syntax, you
> would have used the "private" keyword to achieve the same thing.
> Maybe you don't call it this way, but you use (and de facto ask
> for) privacy.
>
>
> I think making such broad statements as "every local variable is
> actually a 'private' variable" is just plain silly.
What is the difference between a local variable and a private object
property?
Both reduce access to the data they store. Private properties are only
accessible from the body of a given number of functions, local variables
too. What is the difference?
I don't get why we would push 'let' to ES.next and not private properties.

> To me that looks like a utility method for code organisation points.
>
> "private" means its a private method/data that's used in other methods
> of an object. That particular function is not used in any method.
>
> And no, with class syntax it would not be private, it would still be a
> utility function inside the constructor.
You're right, I didn't analyse the code enough. Sorry, my mistake.
But my point remains. Why make a "utility function"? What is "utility"?
Why isn't it public like everything else?

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

Declaring vars in a function, private vars in a class or not using export in a 
module often have similar objectives and ultimately is the decision of the 
author. For serializable data structures that are reified in various places, 
private is overkill and would complicate JSON.{stringify,parse}. Perhaps an 
author wants to keep a definition 'open' and sees no reason for private. The 
language should enable but not require a variety of use cases which I think is 
the main point here.

On Nov 2, 2011, at 2:56 PM, Jake Verbaten  wrote:

>> 
>> I don't think I've ever heard an active JavaScript developer, who has been 
>> programming in JavaScript longer than 6 months, ask for private class or 
>> instance variables.
> Your own code:
> https://github.com/mikeal/npmjs.org/commit/c0d9cc77e79504b9a7c23b4fac735dde97444054#L3R10
> Line 35, you define the function stopBuffering (keeping only relevant parts):
> 
> function File (options) {
> 
>   var stopBuffering = function () {
> // ...
>   }
> 
> }
> 
> Why didn't you do this.stopBuffering = function(){}?
> 
> Maybe you used the keyword "var", but you effectively created a private 
> method of your "File" class. With a class syntax, you would have used the 
> "private" keyword to achieve the same thing.
> Maybe you don't call it this way, but you use (and de facto ask for) privacy.
> 
> I think making such broad statements as "every local variable is actually a 
> 'private' variable" is just plain silly.
> 
> To me that looks like a utility method for code organisation points.
> 
> "private" means its a private method/data that's used in other methods of an 
> object. That particular function is not used in any method.
> 
> And no, with class syntax it would not be private, it would still be a 
> utility function inside the constructor.
> 
> I personally second that we don't need private or instance variables.
> ___
> 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: Minimalist Classes

2011-11-02 Thread David Flanagan


On 11/2/11 11:16 AM, Brendan Eich wrote:

On Nov 2, 2011, at 10:52 AM, David Flanagan wrote:


  Could they have initializers that were automatically included in 
the constructor?


I answered that in a gist comment. Yes, I like the CoffeeScript 
constructor(@x, @y){} shorthand. Dart picked up on it, but requires 
this. instead of @. I'll put it in the gist.



I saw the comment, I think.  What I meant here was initializer 
expressions that are part of the 'private' declaration.  That is, can I 
write


private stack = [];

and have that initialization code automatically inserted (Java-like) 
into the constructor for me?  I'm trying to understand whether private 
and static have the same basic syntax in this proposal.


  Plain 'x' is bound to the Name object and @x is the value of the 
property with that name?  Is x a variable?


x is a const binding in the "@ scope" of the class body. It does not 
collide with any lexically bound x (formal parameter name, e.g.). 
That's important -- see the Monster constructor with its name and 
health parameters and private property names.


So, o@x is *not* o[x] for such a private-declared x.

What I don't understand is whether the "@ scope" is a specification 
abstraction, or whether it is visible to programmers.  If I declare a 
private variable x, and there isn't any other x in scope, is x bound to 
a Name object that I can use?


If not, is there any way I can access the automatically-created Name 
objects so that I can share my private names with "friend" classes?


Some argue @ should work for any x, so if there were some x = "y" in 
scope, then o@x would be o[x] would be o.y. I think that's too 
error-prone. What if I typo @heath instead of @health and there's a 
non-private-declared heath in scope?


That's where a 'public' declaration comes in!  'private x' binds x to a 
new Name in @ scope.  And 'public y' binds y to "y" in @ scope.  Then 
make @ work with any identifier declared private or public.  That would 
allow programmers to elide the "this" but still have publicly visible 
properties.


Resolution of identifiers in @ scope can happen at compile time, can't 
it?  That is, for the code "@x", x is just looked up in @ scope once 
when the code is compiled, not dynamcally each time it is evaluated, right?


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

Re: Globalization API working draft

2011-11-02 Thread Nebojša Ćirić

We were told (I think by Allen) that setting [[Extensible]] to true would
conflict in some way with ES6 modules. I do agree it's a big restriction to
set it to false given how JavaScript works today.

So the question is - are we going to have problems with ES6 Modules is we
set this property to true? If so, is there another way of solving this
problem?

02. новембар 2011. 14.12, Erik Arvidsson  је
написао/ла:

> The draft has the following:
>
> *6 The Globalization Object*
>
> The Globalization object is a single object that has some named
> properties, all of which are constructors.
>
> The value of the [[Prototype]] internal property of the Globalization
> object is the built-in Object prototype object specified by the ECMAScript
> Language Specification. The value of the [[Extensible]] internal property
> is false.
>
> This seems very bad and counter intuitive to how the web works. It would
> mean that there is no way to fix the Globalization object for browsers
> that are not fully up to date. Lets assume that in a future version of the
> spec the Globalization object gains a new property. The standard way to
> handle this in JS is to do:
>
> if (!Globalization.newProperty) {
>   Globalization.newProperty = ...;
> }
>
> This allows people to migrate to new features and it is how people
> gradually started to use Array extras.
>
> --
> erik
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

2011-11-02 Thread Jake Verbaten

>
>
>  I don't think I've ever heard an active JavaScript developer, who has
> been programming in JavaScript longer than 6 months, ask for private class
> or instance variables.
>
> Your own code:
>
> https://github.com/mikeal/npmjs.org/commit/c0d9cc77e79504b9a7c23b4fac735dde97444054#L3R10
> Line 35, you define the function stopBuffering (keeping only relevant
> parts):
> 
> function File (options) {
>
>   var stopBuffering = function () {
> // ...
>   }
>
> }
> 
> Why didn't you do this.stopBuffering = function(){}?
>
> Maybe you used the keyword "var", but you effectively created a private
> method of your "File" class. With a class syntax, you would have used the
> "private" keyword to achieve the same thing.
> Maybe you don't call it this way, but you use (and de facto ask for)
> privacy.
>

I think making such broad statements as "every local variable is actually a
'private' variable" is just plain silly.

To me that looks like a utility method for code organisation points.

"private" means its a private method/data that's used in other methods of
an object. That particular function is not used in any method.

And no, with class syntax it would not be private, it would still be a
utility function inside the constructor.

I personally second that we don't need private or instance variables.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

>>> This is a contrived case, but in general, because JS objects are mutable, 
>>> and when they're used as prototypes they stand in for class vtables, 
>>> something has to pay a price. Either you worry about checking on every 
>>> d.m(i) call that the cached target method in b is still the one to call, or 
>>> you emit code that doesn't check but tear it up and throw it away when c.m 
>>> is injected and shadows b.m.
>>> 
>>> This is fine with me and worth the price, but it clearly is not for 
>>> everyone.
>> 
>> I don't think I've ever heard an active JavaScript developer, who has been 
>> programming in JavaScript longer than 6 months, ask for private class or 
>> instance variables. Maybe you have, you talk to more people than I do. I do 
>> hear this a lot from people who don't use JavaScript and likely won't even 
>> if we add it.
>> 
> 
> The module pattern, arguably one of the most common JS patterns out there is 
> predicated on making internal variables 'private' via a closure, and only 
> returning a 'public' API. For any class/type defined, there are vars that are 
> likely to be only used within the implementation or they are vital to the 
> class/type contract. Both are compelling reasons to have private. 

For some background, I wrote one of the revisions of the commonjs modules 
specification and I wrote the CouchDB implementation of that spec and I work, 
infrequently, on node.js' implementation.

I don't think your comparison is accurate. 

You *must* be allowed to customize the return value of require("mymodule"), 
just like you can customize the return value of a function call, and require() 
is a function call. 

While it may not be obvious to the user, the reason the scope is private by 
default is because you have to do a function wrapped eval in order to allow 
customization of the return value from require(), not the other way around as 
your comment would suggest.

The fact that module variables and methods default to private is actually a 
source of pain. For example, we have exposed previously internal objects and 
methods to the exports object in bugfix releases of node.js because there was 
no other way to work around a bug or customize important or broken behavior. 
The fact that they weren't public by default means that we now have forward 
incompatibility problems in point releases of node.js. 

If every js implementation had an eval sandbox where we could pass in and 
return a new scope commonjs modules may have done that by default and only made 
that scope private when the user intended to customize the return value. I 
would have advocated it, but commonjs modules had to be written for the lowest 
common denominator so that was never an option. In fact, the commonjs spec 
can't even support node.js' `module.exports = function () {}` because it can't 
work in some environments.

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

Le 02/11/2011 21:27, Mikeal Rogers a écrit :
>
> On Nov 2, 2011, at November 2, 201110:57 AM, Brendan Eich wrote:
>
>> This is fine with me and worth the price, but it clearly is not for
>> everyone.
>
> I don't think I've ever heard an active JavaScript developer, who has
> been programming in JavaScript longer than 6 months, ask for private
> class or instance variables.
Your own code:
https://github.com/mikeal/npmjs.org/commit/c0d9cc77e79504b9a7c23b4fac735dde97444054#L3R10
Line 35, you define the function stopBuffering (keeping only relevant
parts):

function File (options) {

  var stopBuffering = function () {
// ...
  }

}

Why didn't you do this.stopBuffering = function(){}?

Maybe you used the keyword "var", but you effectively created a private
method of your "File" class. With a class syntax, you would have used
the "private" keyword to achieve the same thing.
Maybe you don't call it this way, but you use (and de facto ask for)
privacy.

> Maybe you have, you talk to more people than I do. I do hear this a
> lot from people who don't use JavaScript and likely won't even if we
> add it.
Who are these people? You are saying that there exists people who don't
use JavaScript but want to change the language? This sounds like a crazy
idea. Regardless, why should we be listening to them?


>> I'm not just talking about implementors, either. Some users will want
>> to know d.m isn't going to change. They may not want to know that
>> it's b.m, mind you -- they simply won't want that c.m assignment to
>> be legal, or else if they do support such a thing, they don't want it
>> to affect d's "vtable".
>>
>> Ok, so such people should use another language than JS. Or, perhaps,
>> they could freeze c and b.
>
> I would argue that developers who rely on these kinds of assurances
> are actually slowing down their own, and others, productivity.
This is maybe true.
For some people, productivity is not a priority. Some people want to be
able to prove their program is correct, some people want security, some
people want reliability and they prioritize these things higher than
productivity. Should we close them the door to JavaScript?

> Assuming they wrote the perfect method and it should never be changed
> is a grand claim for anyone who isn't Donald Knuth. Assuming that the
> consumer of their code is responsible for their own bugs if they
> introduce them with monkey patching class methods seems fair.
>
> I think this is what Jeremy is getting at, not having these features
> (or at least obscuring their use to be a different, more explicit
> pattern, using closures) actually leads to longer term productivity
> and sustainability in the community and I tend to agree
This is pure speculation. I think these features won't change anything.
There is a strong culture of monkey-patching and using the dynamicity in
JavaScript. I think that if a library is too strongly locked-down it
will be unpopular, so either people will not use it, rewrite another one
with the same features or fork (if open source) and unlock. Because of
the cultural aspect, people will keep things unlocked, not changing
anything to long-term productivity and sustainability.

David

Ps:
https://github.com/mikeal/npmjs.org/commit/c0d9cc77e79504b9a7c23b4fac735dde97444054#L3R64
You could do "process.nextTick( stopBuffering )" instead of creating an
anonymous function.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minimalist Classes

I guess we just don't agree then, I find this alternative very unintuitive.

On Nov 2, 2011, at November 2, 20112:02 PM, Erik Arvidsson wrote:

> On Wed, Nov 2, 2011 at 13:39, Mikeal Rogers  wrote:
> 
> var generateModelClass = function(columns) {
> 
> 
> 
> 
> 
>   var definition = {};
> 
> 
> 
> 
> 
>   columns.forEach(function(col) {
> 
> 
> definition['get' + col] = function() {
> 
> 
>   return this[col];
> 
> 
> };
> 
> 
> definition['set' + col] = function(value) {
> 
> 
>   return this[col] = value;
> 
> 
> };
> 
> 
>   });
> 
> 
> 
> 
> 
>   return class definition;
> 
> 
> 
> 
> 
> };
> 
> 
> 
> I feel like this is too strange to my liking. With something more along what 
> Brendan was suggesting the same could be done like this:
> 
> 
> var generateModelClass = function(columns) {
> 
> 
>   var c = class {},
> 
> 
>   p = returnClass.prototype;
> 
> 
> 
> 
> 
>   columns.forEach(function(col) {
> 
> 
> p['get' + col] = function() {
> 
> 
>   return this[col];
> 
> 
> };
> 
> 
> p['set' + col] = function(value) {
> 
> 
>   return this[col] = value;
> 
> 
> };
> 
> 
>   });
> 
> 
> 
> 
> 
>   return c;
> 
> 
> };
> 
> 
> 
> -- 
> erik

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...



On Nov 2, 2011, at 1:27 PM, Mikeal Rogers  wrote:

> 
> On Nov 2, 2011, at November 2, 201110:57 AM, Brendan Eich wrote:
> 
>> On Nov 2, 2011, at 9:51 AM, Mikeal Rogers wrote:
>> 
>>> On Nov 2, 2011, at November 2, 20119:30 AM, Quildreen Motta wrote:
 
> "freeze" does not add anything new to an object. If you don't want to 
> change the shape of an object ... don't change the shape of the object.
 Again, immutability isn't just about security, but optimisation as well. 
 You could also look at shared-memory threads, because I think they make a 
 hell of an argument for "frozen" objects or immutability.
>>> 
>>> The last time we looked at freezing a few core objects in node.js we found 
>>> that v8 was actually slower with them frozen and backed them out, which is 
>>> probably a good thing.
>>> 
>>> I'm very skeptical of the "new language feature for optimization" argument 
>>> ever since the static typing debate in ES4 and the tracer work Mozilla did 
>>> shortly after.
>> 
>> Type inference is doing well for us now. I agree in general.
>> 
>> However, there's a reason Dart did what it did. With JS, you have to guard, 
>> or provide an invalidation protocol, in case someone shadows an inherited 
>> property:
>> 
>> var a = [],
>> b = {m: function (i) { return i * i; }},
>> c = Object.create(b),
>> d = Object.create(c);
>> 
>> for (var i = 0; i < BIG; i++) {
>>   a[i] = d.m(i);
>>   if (rarely(i)) {
>> c.m = function (i) { return 42 * i; };
>>   }
>> }
>> 
>> This is a contrived case, but in general, because JS objects are mutable, 
>> and when they're used as prototypes they stand in for class vtables, 
>> something has to pay a price. Either you worry about checking on every 
>> d.m(i) call that the cached target method in b is still the one to call, or 
>> you emit code that doesn't check but tear it up and throw it away when c.m 
>> is injected and shadows b.m.
>> 
>> This is fine with me and worth the price, but it clearly is not for everyone.
> 
> I don't think I've ever heard an active JavaScript developer, who has been 
> programming in JavaScript longer than 6 months, ask for private class or 
> instance variables. Maybe you have, you talk to more people than I do. I do 
> hear this a lot from people who don't use JavaScript and likely won't even if 
> we add it.
> 

The module pattern, arguably one of the most common JS patterns out there is 
predicated on making internal variables 'private' via a closure, and only 
returning a 'public' API. For any class/type defined, there are vars that are 
likely to be only used within the implementation or they are vital to the 
class/type contract. Both are compelling reasons to have private. 

>> I'm not just talking about implementors, either. Some users will want to 
>> know d.m isn't going to change. They may not want to know that it's b.m, 
>> mind you -- they simply won't want that c.m assignment to be legal, or else 
>> if they do support such a thing, they don't want it to affect d's "vtable".
>> 
>> Ok, so such people should use another language than JS. Or, perhaps, they 
>> could freeze c and b.
> 
> I would argue that developers who rely on these kinds of assurances are 
> actually slowing down their own, and others, productivity. Assuming they 
> wrote the perfect method and it should never be changed is a grand claim for 
> anyone who isn't Donald Knuth. Assuming that the consumer of their code is 
> responsible for their own bugs if they introduce them with monkey patching 
> class methods seems fair.
> 
> I think this is what Jeremy is getting at, not having these features (or at 
> least obscuring their use to be a different, more explicit pattern, using 
> closures) actually leads to longer term productivity and sustainability in 
> the community and I tend to agree
> 
> I may have said this before, but the lack of these features may actually be 
> part of what has allowed JavaScript to thrive and, for lack of a better term, 
> to win. Jeremy brought up some compelling examples.
> 
>> Then they'd have parity, once V8 and other engines got around to optimizing 
>> accordingly. (It's bogus for you to infer too much from the state of 
>> optimization vs. new features.)
> 
> I was just trying to debunk the claim that these features are necessarily 
> faster and will vary with implementation. Most features can lend themselves 
> to optimizations but, as you pointed out, at what cost.
> 
>> 
>> /be
> 
> ___
> 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: Globalization API working draft

2011-11-02 Thread Erik Arvidsson

The draft has the following:

*6 The Globalization Object*

The Globalization object is a single object that has some named properties,
all of which are constructors.

The value of the [[Prototype]] internal property of the Globalization
object is the built-in Object prototype object specified by the ECMAScript
Language Specification. The value of the [[Extensible]] internal property
is false.

This seems very bad and counter intuitive to how the web works. It would
mean that there is no way to fix the Globalization object for browsers that
are not fully up to date. Lets assume that in a future version of the spec
the Globalization object gains a new property. The standard way to handle
this in JS is to do:

if (!Globalization.newProperty) {
  Globalization.newProperty = ...;
}

This allows people to migrate to new features and it is how people
gradually started to use Array extras.

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

Re: Minimalist Classes

2011-11-02 Thread Erik Arvidsson

On Wed, Nov 2, 2011 at 13:39, Mikeal Rogers  wrote:
>
> var generateModelClass = function(columns) {
>
>   var definition = {};
>
>   columns.forEach(function(col) {
> definition['get' + col] = function() {
>   return this[col];
> };
> definition['set' + col] = function(value) {
>   return this[col] = value;
> };
>   });
>
>   return class definition;
>
> };
>
>
I feel like this is too strange to my liking. With something more along
what Brendan was suggesting the same could be done like this:

var generateModelClass = function(columns) {
  var c = class {},
  p = returnClass.prototype;

  columns.forEach(function(col) {
p['get' + col] = function() {
  return this[col];
};
p['set' + col] = function(value) {
  return this[col] = value;
};
  });

  return c;
};


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

Re: Minimalist Classes

On Nov 2, 2011, at 1:20 PM, Brendan Eich  wrote:

> On Nov 2, 2011, at 1:17 PM, Kam Kasravi wrote:
> 
>> On Nov 2, 2011, at 11:29 AM, Brendan Eich  wrote:
>> 
>>> On Nov 2, 2011, at 11:17 AM, David Bruant wrote:
>>> 
> See my reply to Kam. We're not sugaring instance-private ivars. I am 
> proposing something we agreed to in Nov. 2008: sugaring class-private 
> ivars.
 Ok, that's what I was missing. What were the rationale? use cases?
>>> 
>> Doesn't the latest harmony class proposal define private within the 
>> constructor? I assume this proposal would supersede the Nov 2008 meeting 
>> Grammar pasted below:
> 
> Are you asking a procedural question, or something? If so, bzzzt. :-|
> 
> I'm hacking a gist forked from Jeremy's. But TC39 is sticking to consensus 
> where we can. The wiki'ed class proposal does have class-private instance 
> variables. It simply mislocates the private declaration inside the 
> constructor. Again, this proposal is in trouble and the gist'ing is an 
> attempt to rescue it, outside the confines of the somewhat-overconstrained 
> TC39 setting.
> 

Understood, just wanted to clarify exactly what the TC39 consensus was in 
respect to the harmony class proposal. I do think your gist has advantages over 
the harmony class proposal both in terms of removing the public keyword and 
clarifying private-class var declaration and semantics. My only concern would 
be users/framework writers opting for the closure pattern in lieu of using 
private to prevent the Account use case I noted. That is, I would normally 
interpret private to mean no access unless you're the instance and within class 
scope. Here private means no access unless you're any instance and within class 
scope. 

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

Re: Minimalist Classes

To bring the comments back around a little bit to this original proposal.

One thing I can't get over with this proposal is how obvious the syntax makes 
the semantics. I didn't actually have to read any of the descriptions to figure 
out how all of this works, my mind made a set of assumptions and they turned 
out to be correct.

While some of the alternate proposals shave the syntax in terms of bytes they 
are non-obvious and I'd happily take the hit in bytes for the simplicity and 
lack of explanation the original proposal has.

This is on par with the destructuring proposal in terms of obviousness which I 
felt the previous class proposal lacked.

This also *feels* a lot like JavaScript, like the syntax was already hiding out 
waiting to be used, it doesn't few "new", if that makes sense.

var generateModelClass = function(columns) {

  var definition = {};

  columns.forEach(function(col) {
definition['get' + col] = function() {
  return this[col];
};
definition['set' + col] = function(value) {
  return this[col] = value;
};
  });

  return class definition;

};

That is exactly what I would write if I was guessing how to generate dynamic 
classes.

In fact, all the examples in this proposal feel significantly more dynamic and 
less declarative than in 
http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar .

My 2 cents.

-Mikeal

On Oct 31, 2011, at October 31, 20117:08 PM, Axel Rauschmayer wrote:

>> Here is a proposal for minimalist JavaScript classes that enable behavior 
>> that JavaScripters today desire (as evidenced by libraries and languages 
>> galore), without adding any new semantics beyond what already exists in ES3.
>> 
>> https://gist.github.com/1329619
> 
> I like the philosophy behind it (as stated at the end of the file).
> 
> Question: If the RHS can be any expression, e.g.
> 
>  class Student objectContainingStudentProperties
> 
> Would extends work, too?
> 
>  class Student extends Human objectContainingStudentProperties
> 
> That could be a problem (grammatically) if Human could also be replaced by 
> any expression.
> 
> What is your take on object exemplars?
> 
> Axel
> 
> -- 
> Dr. Axel Rauschmayer
> a...@rauschma.de
> 
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
> 
> 
> 
> ___
> 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: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...


On Nov 2, 2011, at November 2, 201110:57 AM, Brendan Eich wrote:

> On Nov 2, 2011, at 9:51 AM, Mikeal Rogers wrote:
> 
>> On Nov 2, 2011, at November 2, 20119:30 AM, Quildreen Motta wrote:
>>> 
 "freeze" does not add anything new to an object. If you don't want to 
 change the shape of an object ... don't change the shape of the object.
>>> Again, immutability isn't just about security, but optimisation as well. 
>>> You could also look at shared-memory threads, because I think they make a 
>>> hell of an argument for "frozen" objects or immutability.
>> 
>> The last time we looked at freezing a few core objects in node.js we found 
>> that v8 was actually slower with them frozen and backed them out, which is 
>> probably a good thing.
>> 
>> I'm very skeptical of the "new language feature for optimization" argument 
>> ever since the static typing debate in ES4 and the tracer work Mozilla did 
>> shortly after.
> 
> Type inference is doing well for us now. I agree in general.
> 
> However, there's a reason Dart did what it did. With JS, you have to guard, 
> or provide an invalidation protocol, in case someone shadows an inherited 
> property:
> 
> var a = [],
> b = {m: function (i) { return i * i; }},
> c = Object.create(b),
> d = Object.create(c);
> 
> for (var i = 0; i < BIG; i++) {
>   a[i] = d.m(i);
>   if (rarely(i)) {
> c.m = function (i) { return 42 * i; };
>   }
> }
> 
> This is a contrived case, but in general, because JS objects are mutable, and 
> when they're used as prototypes they stand in for class vtables, something 
> has to pay a price. Either you worry about checking on every d.m(i) call that 
> the cached target method in b is still the one to call, or you emit code that 
> doesn't check but tear it up and throw it away when c.m is injected and 
> shadows b.m.
> 
> This is fine with me and worth the price, but it clearly is not for everyone.

I don't think I've ever heard an active JavaScript developer, who has been 
programming in JavaScript longer than 6 months, ask for private class or 
instance variables. Maybe you have, you talk to more people than I do. I do 
hear this a lot from people who don't use JavaScript and likely won't even if 
we add it.

> I'm not just talking about implementors, either. Some users will want to know 
> d.m isn't going to change. They may not want to know that it's b.m, mind you 
> -- they simply won't want that c.m assignment to be legal, or else if they do 
> support such a thing, they don't want it to affect d's "vtable".
> 
> Ok, so such people should use another language than JS. Or, perhaps, they 
> could freeze c and b.

I would argue that developers who rely on these kinds of assurances are 
actually slowing down their own, and others, productivity. Assuming they wrote 
the perfect method and it should never be changed is a grand claim for anyone 
who isn't Donald Knuth. Assuming that the consumer of their code is responsible 
for their own bugs if they introduce them with monkey patching class methods 
seems fair.

I think this is what Jeremy is getting at, not having these features (or at 
least obscuring their use to be a different, more explicit pattern, using 
closures) actually leads to longer term productivity and sustainability in the 
community and I tend to agree

I may have said this before, but the lack of these features may actually be 
part of what has allowed JavaScript to thrive and, for lack of a better term, 
to win. Jeremy brought up some compelling examples.

> Then they'd have parity, once V8 and other engines got around to optimizing 
> accordingly. (It's bogus for you to infer too much from the state of 
> optimization vs. new features.)

I was just trying to debunk the claim that these features are necessarily 
faster and will vary with implementation. Most features can lend themselves to 
optimizations but, as you pointed out, at what cost.

> 
> /be

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

Re: Minimalist Classes

On Nov 2, 2011, at 1:17 PM, Kam Kasravi wrote:

> On Nov 2, 2011, at 11:29 AM, Brendan Eich  wrote:
> 
>> On Nov 2, 2011, at 11:17 AM, David Bruant wrote:
>> 
 See my reply to Kam. We're not sugaring instance-private ivars. I am 
 proposing something we agreed to in Nov. 2008: sugaring class-private 
 ivars.
>>> Ok, that's what I was missing. What were the rationale? use cases?
>> 
> Doesn't the latest harmony class proposal define private within the 
> constructor? I assume this proposal would supersede the Nov 2008 meeting 
> Grammar pasted below:

Are you asking a procedural question, or something? If so, bzzzt. :-|

I'm hacking a gist forked from Jeremy's. But TC39 is sticking to consensus 
where we can. The wiki'ed class proposal does have class-private instance 
variables. It simply mislocates the private declaration inside the constructor. 
Again, this proposal is in trouble and the gist'ing is an attempt to rescue it, 
outside the confines of the somewhat-overconstrained TC39 setting.

/be

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

Re: Minimalist Classes



On Nov 2, 2011, at 11:29 AM, Brendan Eich  wrote:

> On Nov 2, 2011, at 11:17 AM, David Bruant wrote:
> 
>>> See my reply to Kam. We're not sugaring instance-private ivars. I am 
>>> proposing something we agreed to in Nov. 2008: sugaring class-private ivars.
>> Ok, that's what I was missing. What were the rationale? use cases?
> 
Doesn't the latest harmony class proposal define private within the 
constructor? I assume this proposal would supersede the Nov 2008 meeting 
Grammar pasted below:

CallExpression : ... private ( AssignmentExpression ) ConstructorElement : ... 
PrivateVariableDefinition PrivateVariableDefinition : private 
ExportableDefinition
> The rationale is that most mainstream OO languages with the most users 
> support class-private not instance-private ivars. Sorry, Smalltalkers!
> 
In java one cannot access a private declaration in this way without defining a 
protected getter/setter for example.
 
> Use cases are all around us in JS today, using public properties. Refactoring 
> to private should not require rewriting to add getter/setter method, etc.
But if you are locking down a private var, isn't refactoring implied by your 
statement 'avoid ... hostile attacks, on private data'.
Private instance vars would, for example, prevent the following:

class Account {
private balance = 0;
constructor(balance) {
@balance = balance;
}
compare(otheraccount) {
if(otheraccount@balance > 100) {
@balance += --otheraccount@balance;
}
if(@balance > otheraccount@balance) {
return 1;
} else if(@balance < otheraccount@balance) {
return -1;
}
return 0;
}
}
> 
> 
>>> You can make instance-private ivars yourself in the constructor using 
>>> Name.create, and go to town. Knock yourself out! (I mean that in a good 
>>> way, at least from where I sit :-P).
>> Hmm... Are you sure you can implement instance-private variables with no
>> leak?
> 
> You'd need to use the closure pattern:
> 
> class BnD {
>   constructor(x) {
> const my_x = Name.create('x');
> this[my_x] = x;
> this.method1 = function (...) {...};
> ...
> this.methodN = function (...) {...};
>   }
> }
> 
> The method1..N functions can use my_x, no one else can.

In Crockford terminology, method1..N are 'privileged' functions, but come at 
the cost of memory allocation per object.
Does class-private ivars enable the private names proposal? Eg, is there an 
implicit dependency?
> 
> /be
> ___
> 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: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

HAHA!

You'll pry JavaScript from my cold dead hands!

-Mikeal

On Nov 2, 2011, at November 2, 201110:49 AM, Brendan Eich wrote:

> On Nov 2, 2011, at 9:46 AM, Mikeal Rogers wrote:
> 
>> I agree with every sentence in this post.
>> 
>> +1K :)
> 
> Switching to CoffeeScript? :-P
> 
> /be
> 
>> 
>> -Mikeal
>> 
>> On Nov 2, 2011, at November 2, 20119:05 AM, Jeremy Ashkenas wrote:
>> 
>>> On Wed, Nov 2, 2011 at 11:01 AM, David Bruant  wrote:
>>> Could you elaborate on this point? 
>>> All object-lockdown I can think (non-configurability, non-writability, 
>>> non-enumerability, private names, const variables, const classes) of is 
>>> optional. Why are you against them?
>>> 
>>> I was about to say "if you're unsatisfied, create a language which doesn't 
>>> provide features you don't like, like Coffeescript", but... humm...
>>> So, why being against the introduction of features in the language?
>>> 
>>> I'd be glad to elaborate -- but since it's off topic for minimal classes, 
>>> changing the Subject here.
>>> 
>>> What draws people to dynamic languages is freedom.
>>> 
>>> And JavaScript is one of the *most* dynamic of the mainstream programming 
>>> languages. Not only can you can pass any object to any function, but you 
>>> can call a method with any number of arguments, easily modify the 
>>> prototypes of other objects, introspect on any object's properties with a 
>>> simple loop, replace any member function with a wrapped version, attach new 
>>> properties to any object ... the list goes on.
>>> 
>>> If I had my druthers, JS.next would generally embrace the spirit of 
>>> JavaScript's dynamism (and freedom), and try to push those aspects further 
>>> -- with better introspection and more flexibility -- instead of 
>>> compromising with more restrictive static languages and adding lock-down 
>>> keywords so that some programmers might "feel safer".
>>> 
>>> Let's set arguments about security and constraint guarantees aside for a 
>>> moment (although I'd be glad to have those as well), and talk about these 
>>> keywords as pure features:
>>> 
>>> "private" does not add anything new to a property. If you don't want the 
>>> property to be used outside of the class ... don't use the property outside 
>>> of the class. 
>>> 
>>> "const" does not add anything new to a variable. If you don't want to 
>>> change the value of a variable ... don't change the value of the variable. 
>>> 
>>> "freeze" does not add anything new to an object. If you don't want to 
>>> change the shape of an object ... don't change the shape of the object.
>>> 
>>> Note that Ruby, another very dynamic language, has "private" and constants. 
>>> And yet private methods can be called from the outside, with "send", and 
>>> contants can be explicitly overwritten with new values. They are simply red 
>>> tape, not concrete walls. For better or for worse, I have very rarely seen 
>>> a large-scale Ruby project that does *not* call a private method 
>>> externally, or overwrite a constant during configuration.
>>> 
>>> The recent JavaScript renaissance that we're all enjoying owes debts to 
>>> JavaScript's foresight as a "free", dynamic language. If all of the 
>>> JavaScript core object had been frozen, locked down with private methods, 
>>> and set as const properties on the global object, libraries like 
>>> Prototype.js never would have happened. Libraries like jQuery would have 
>>> been much more difficult to imagine. We might not have the new Array#map, 
>>> #reduce, #every, or #filter methods at all.
>>> 
>>> Can a free, dynamic language be abused? Certainly. Is Prototype.js 
>>> dangerous? For some websites, it can be (including NYTimes.com, where I 
>>> work).
>>> 
>>> The freedom of having every object and every property be configurable, 
>>> settable, introspectable, readable and writable, at least at the language 
>>> level, is worth the trade off. If we add const, private, and other 
>>> lock-down syntax, or make class properties private by default (shudder), I 
>>> guarantee you that many potential innovative libraries that otherwise might 
>>> spring up will never even be conceived, and frustrating situations that 
>>> could have otherwise been solved by a quick patch will instead require 
>>> convoluted work-arounds.
>>> 
>>> JavaScript should be about making it easier to write the right thing, and 
>>> not so much about making it harder to do the wrong thing. After all, the 
>>> former is purely positive, and the latter assumes that you know better than 
>>> the engineer who comes after you. In the real world, you often don't.
>>> 
>>> Cheers,
>>> Jeremy
>>> 
>>> ___
>>> 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
> 

___
e

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

2011-11-02 Thread James Burke

Accidentally sent this only to Brendan, meant to send to list, resending:

On Wed, Nov 2, 2011 at 10:39 AM, Brendan Eich  wrote:
> 2. Web developers both depend on and wish to minimize the size (to zero 
> bytes) of libraries.
>
> 3. Programming in the large, even ignoring security, means many of us want to 
> save ourselves from assigning to something we want non-writable and 
> initialize-only. That's const. Or we want to avoid name collision worries, 
> never mind hostile attacks, on private data. That's private, or else you use 
> closures and pay some non-trivial price (verbosity and object allocation).
>
> (3) implies adding encapsulation and integrity features, on an opt-in basis.

Does encapsulation and integrity mean adding more things to the JS
language or addressing the how JS is encapsulated and run?

The SES and mashup use cases can be used as examples. Are the problems
with the JS language or are they better served by securing not just JS
but the DOM and network calls and having efficient containers that can
communicate?

iframes/the FRAG proposal maybe, or some other JS container entity,
with postMessage async passing of JSON-friendly data might be the way
forward for those things.

Getting those to perform well and perhaps building better APIs around
them might be more effective solutions than to adding more
security/integrity features to JS syntax.

Similar to how focusing on improving the VM container to get JS to
perform better was a better route than adding static type checking
syntax.

The Harmony module loader API feels like another parallel. That is
more of an API to a JS container of sorts with certain isolation
properties. It does not necessarily mean that a JS module syntax needs
to exist for that type of API to be useful.

Since it is an API, a loader API is easier to integrate into existing
systems. With legacy upgrade costs (IE and even older android) and the
possibility for editors to support comment-based systems that allow
type and intellisense support (for quicker turnaround on a deeper set
of errors than the module syntax could provide), I give a loader API a
stronger chance of having a wider impact than module syntax.

> (2) means we keep working on the language, until it reaches some 
> macro-apotheosis.

In any game, it is tempting, particularly for the game designers, to
try to keep tweaking the game to "get better". But that easily turns
to destroying the reason the game existed in the first place, and why
it became popular.

I feel that getting to zero probably means not having a successful,
widely used and deployed language. This feedback is not so helpful
though, right? The devil is in the details. I just needed to get it
out of my system, and the mention of macros set off the "too much game
tweaking" bells.

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...


On 02/11/11 17:00, John J Barton wrote:

On Wed, Nov 2, 2011 at 10:51 AM, Quildreen Motta  wrote:

Imho, no users *SHOULD* use Object.create directly. That's why abstractions
exist —

Of course I agree with you!


and first class functions make it easy enough to make them.

But if we had Crockford's Object.create() rather than the one you
don't want us to use we would not need the class goop ;-)

Anyway this is all wishful thinking. Languages don't get simpler.

jjb

Racket seems simple as fuck to me :3 So does Haskell.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minimalist Classes

Le 02/11/2011 19:29, Brendan Eich a écrit :
> On Nov 2, 2011, at 11:17 AM, David Bruant wrote:
>
>>> See my reply to Kam. We're not sugaring instance-private ivars. I am
>>> proposing something we agreed to in Nov. 2008: sugaring
>>> class-private ivars.
>> Ok, that's what I was missing. What were the rationale? use cases?
>
> The rationale is that most mainstream OO languages with the most users
> support class-private not instance-private ivars. Sorry, Smalltalkers!
I thought Java had per-instance private properties, but not, it's
per-class as well. Interesting.

>
>>> You can make instance-private ivars yourself in the constructor
>>> using Name.create, and go to town. Knock yourself out! (I mean that
>>> in a good way, at least from where I sit :-P).
>> Hmm... Are you sure you can implement instance-private variables with no
>> leak?
>
> You'd need to use the closure pattern:
>
> class BnD {
>   constructor(x) {
> const my_x = Name.create('x');
> this[my_x] = x;
> this.method1 = function (...) {...};
> ...
> this.methodN = function (...) {...};
>   }
> }
>
> The method1..N functions can use my_x, no one else can.
Ok. Perfect.
It's unfortunate to loose the syntactic sugar ("this.method1 =
function(){};" and compulsory explicit |this| in the function body), but
it's doable.

Thanks,

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

On Nov 2, 2011, at 12:00 PM, John J Barton wrote:

> On Wed, Nov 2, 2011 at 10:51 AM, Quildreen Motta  wrote:
>> 
>> Imho, no users *SHOULD* use Object.create directly. That's why abstractions
>> exist —
> 
> Of course I agree with you!
> 
>> and first class functions make it easy enough to make them.
> 
> But if we had Crockford's Object.create()

You mean begetObject?

Anyway, who cares about the name? There's nothing super-magical about 
Object.create in my book. YMMV.

> rather than the one you
> don't want us to use we would not need the class goop ;-)
> 
> Anyway this is all wishful thinking. Languages don't get simpler.

English is. Moods such as the subjunctive are dying, spellings grow simpler, 
etc.

Let's take a long view. We removed 'with' in ES5 strict and thus in Harmony. 
There's time to remove other things.

This doesn't mean we should "get it wrong" or be ok with less than our best, of 
course.

OTOH reflection/meta-programming libraries are like plumbing (or plumbers at 
work :-P). Why are you staring at them and worrying, when they're behind the 
varnished cabinet door?

When I think of "language simplicity" as a good to optimize, I think about 
kernel semantics and common syntax, not every corner of every built-in or 
standard library.

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

2011-11-02 Thread John J Barton

On Wed, Nov 2, 2011 at 10:51 AM, Quildreen Motta  wrote:
>
> Imho, no users *SHOULD* use Object.create directly. That's why abstractions
> exist —

Of course I agree with you!

> and first class functions make it easy enough to make them.

But if we had Crockford's Object.create() rather than the one you
don't want us to use we would not need the class goop ;-)

Anyway this is all wishful thinking. Languages don't get simpler.

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

Re: Minimalist Classes


On 02/11/11 16:21, Brendan Eich wrote:

On Nov 2, 2011, at 10:52 AM, Quildreen Motta wrote:


On 02/11/11 15:42, Erik Corry wrote:

2011/11/2 Quildreen Motta:

I don't think hard coding the name of the super-constructor is a
problem.

It is when you take into account that functions in JavaScript are not bound
to an object, they are generic. You can simply assign any function to any
object and it'll most likely just work.

I think the chances are slim that you can take a function that does a
super call, put it on a different object, and it will 'just work'.
It's a pretty rare case.

"most likely". Also, it should work if |super| were dynamically resolved, as 
long as the object implemented what's required by the call.

We can't do dynamic super without adding a parameter to every function call 
everywhere (modulo optimization), or simulating Algolish nested scopes using 
dynamic scope hacks, or worse. This is something we won't do, I'm pretty sure 
Erik agrees.

Ah yeah, I'm well aware that dynamic super isn't happening.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minimalist Classes

On Nov 2, 2011, at 11:17 AM, David Bruant wrote:

>> See my reply to Kam. We're not sugaring instance-private ivars. I am 
>> proposing something we agreed to in Nov. 2008: sugaring class-private ivars.
> Ok, that's what I was missing. What were the rationale? use cases?

The rationale is that most mainstream OO languages with the most users support 
class-private not instance-private ivars. Sorry, Smalltalkers!

Use cases are all around us in JS today, using public properties. Refactoring 
to private should not require rewriting to add getter/setter method, etc.

>> You can make instance-private ivars yourself in the constructor using 
>> Name.create, and go to town. Knock yourself out! (I mean that in a good way, 
>> at least from where I sit :-P).
> Hmm... Are you sure you can implement instance-private variables with no
> leak?

You'd need to use the closure pattern:

class BnD {
  constructor(x) {
const my_x = Name.create('x');
this[my_x] = x;
this.method1 = function (...) {...};
...
this.methodN = function (...) {...};
  }
}

The method1..N functions can use my_x, no one else can.

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

Re: Minimalist Classes

On Nov 2, 2011, at 10:52 AM, Quildreen Motta wrote:

> On 02/11/11 15:42, Erik Corry wrote:
>> 2011/11/2 Quildreen Motta:
 I don't think hard coding the name of the super-constructor is a
 problem.
>>> It is when you take into account that functions in JavaScript are not bound
>>> to an object, they are generic. You can simply assign any function to any
>>> object and it'll most likely just work.
>> I think the chances are slim that you can take a function that does a
>> super call, put it on a different object, and it will 'just work'.
>> It's a pretty rare case.
> "most likely". Also, it should work if |super| were dynamically resolved, as 
> long as the object implemented what's required by the call.

We can't do dynamic super without adding a parameter to every function call 
everywhere (modulo optimization), or simulating Algolish nested scopes using 
dynamic scope hacks, or worse. This is something we won't do, I'm pretty sure 
Erik agrees.

The super proposal in Harmony is static, but you can Object.defineMethod to 
transplant (a method clone with different [[Super]], of course -- again modulo 
optimizations). [[Super]] is an internal property of function objects. I 
believe Allen is correct that this is how dynamic OO languages in general 
support 'super'.

/be

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

Re: Minimalist Classes

Le 02/11/2011 19:00, Brendan Eich a écrit :
> On Nov 2, 2011, at 10:35 AM, David Bruant wrote:
>
>> Le 02/11/2011 18:09, Brendan Eich a écrit :
>>> On Nov 2, 2011, at 4:10 AM, David Bruant wrote:
>>>
 Another topic:
 -
 class Monster {

  private name, health;

  sameName(other) {
return @name === other@name;
  }
 }
 -
 I am under this impression that you are accessing the private property 
 ("other@name") of an instance which isn't you (other !== this) and I'm not 
 sure it's a good idea.
>>> Private names do not leak via reflection, not even via proxies. So what's 
>>> the problem?
>> My problem is that private names are per-class instead of per-instance.
> See my reply to Kam. We're not sugaring instance-private ivars. I am 
> proposing something we agreed to in Nov. 2008: sugaring class-private ivars.
Ok, that's what I was missing. What were the rationale? use cases?

> You can make instance-private ivars yourself in the constructor using 
> Name.create, and go to town. Knock yourself out! (I mean that in a good way, 
> at least from where I sit :-P).
Hmm... Are you sure you can implement instance-private variables with no
leak?
Within the constructor, you can call Name.create, but where do you store
the name? If in a constructor local variable, it's not usable anywhere
else which is useless. If in a private class variable... well... that's
not an instance-private name anymore.
The private class variable could be a WeakMap indexed on instances, but
it means that any instance with a reference to another instance can
access the "private" value of the latter. That's not private.
Am I missing something?
If I can implement them myself, I promise, i'll knock myself out to town
(damn, it's hard being a non-native English speaker. So many expressions
I'm never sure I fully understand)



 Is "other" a monster? (how do you "recognize" a monster from any other 
 object?).
>>> You could do ad-hoc type or shape tests. For the example, and even in most 
>>> cases in general, there's no need. Duck typing works with private names too.
>> Who is "you" in your case? My "you" was "runtime". I think runtime
>> shouldn't do heuristic-tests like comparing shapes.
> We don't have types. I have no idea what you are proposing, but my point 
> stands: there's no need to recognize another Monster and no capability leak. 
> The code works as much JS today does with public property names.
Ok. I thought @health refered to a per-instance name. Now I know it's a
per-class name, other@health makes sense.

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

Re: Minimalist Classes

On Nov 2, 2011, at 10:52 AM, David Flanagan wrote:

> On 11/1/11 11:53 PM, Brendan Eich wrote:
>> 
>> On Nov 1, 2011, at 10:27 PM, David Flanagan wrote:
>>> 1) Class bodies are new syntax, so you can introduce new keywords, right?  
>>> So 'prop' or 'proto'?  'static' puts a property on the class.  'private' 
>>> puts a (private) property on the instance.  So 'proto' could put a property 
>>> on the prototype.
>> 
>> Yes, but prefix keywords in front of every member? Too heavy. Labeled 
>> sections are problematic grammatically and most on TC39 hate 'em. prefixed 
>> braced sub-bodies over-indent.
>> 
>> There ought to be a sane unprefixed default. Then, though, we still have two 
>> choices:
>> 
>> (a) Data property initialiser syntax (x: v with comma separator).
>> 
>> (b) Assignment expression form (x = v with semicolon separator or terminator 
>> and some kind of ASI consistency).
>> 
>> Neither is great. I lean toward (b). You?
>> 
>> 
> I don't see why you can't use var syntax but with 'proto' as the keyword 
> instead of 'var':

I lean toward (a) now. I've made my peace with object initialiser syntax -- but 
with the Cordoba extensions for classes and object literals, as discussed with 
Jeremy today.

>>> Your private instance variables are quite interesting.
>> 
>> Yes, that is a missing ingredient in most proposals we've seen.
>> 
> And inquiring minds want to know more about them.  I assume they're scoped to 
> the entire class body, right?

Certainly.

> And they hoist to the top?

That's how we roll where possible.

>   Could they have initializers that were automatically included in the 
> constructor?

I answered that in a gist comment. Yes, I like the CoffeeScript constructor(@x, 
@y){} shorthand. Dart picked up on it, but requires this. instead of @. I'll 
put it in the gist.

> A comment in your gist (lines 186-187) seems to say that with 'private x', we 
> can use @x or this[x].  Is that really what you meant?

Sorry, not quite. I will fix that comment.

>   Plain 'x' is bound to the Name object and @x is the value of the property 
> with that name?  Is x a variable?

x is a const binding in the "@ scope" of the class body. It does not collide 
with any lexically bound x (formal parameter name, e.g.). That's important -- 
see the Monster constructor with its name and health parameters and private 
property names.

So, o@x is *not* o[x] for such a private-declared x.

Some argue @ should work for any x, so if there were some x = "y" in scope, 
then o@x would be o[x] would be o.y. I think that's too error-prone. What if I 
typo @heath instead of @health and there's a non-private-declared heath in 
scope?

> Does this mean that the class desugars into something that has a let 
> statement surrounding the all the methods?

No, because private x does not bind a lexical name 'x' usable freely.

private/@ is new, the semantics are a slight extension to today's, not 
desugarable without gensym. I'll consult with my semantic betters on this one.

>>> One nit: you're using @ as both a sigil in @name and as an operator in 
>>> other@name.  I would expect other.@name instead.
>> 
>> No, it's a prefix operator if in operand context (like / starting a regexp), 
>> a binary operator in operator context (/ as division).
>> 
>> Trying to avoid .@ all over, and this.@ noise.
>> 
> I think ordinary unary @ would dominate and .@ would be relatively rare.  But 
> when used, it would at least look like noisy property access rather than an 
> email address.  My gut says that regularity of syntax wins over 
> conciseness and noise here.

Oh, I see -- you are suggesting @x as short for this.@x, and requiring other.@x 
for non-this-based references. That could work. IINM it even avoids the [no 
LineTerminator here] to the left of unary prefix @. Nice!

I hear you on the email thing. I'm big on grep, and I mourn the coming demise 
of codesearch.google.com.

> Do you expect the performance of private property lookup to be equivalent to 
> public property lookup?  That is will @foo take the same time as this.foo?

That is a requirement in my view.

/be

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

On 02/11/11 15:49, Brendan Eich wrote:

On Nov 2, 2011, at 9:30 AM, Quildreen Motta wrote:

Also, note that `with' makes a whole awesome use-case for `Object.freeze':

'with' is gone in ES5 strict, ES6, and beyond -- you knew that, right?
Yep, and I still think it's a sad thing. Not that I use it anyways, the
performance doesn't allow me to. And we're getting real `let'.

---
with (require({'library1': 'lib1'}, {'library2': 'lib2'})) {
lib1.foo(lib2.something)
}

This is still hard to optimize, even with the implied freeze under require.

Hm, not sure I understand why. I'm not a compiler writer though.

Also, you can't load code dynamically without nesting an event loop and
violating run-to-completion, so I'm not sure how such a require would work.
Yes, but `require' could take a plain object out of a map or something,
it could use a synchronous call. But I don't think that matters much here :3

This does remind me: JS's "freedom" is Dart's "cannot be tooled" and "inherent
performance problems", and without aggressive optimization work it can mean JS is measurably slower for
some kinds of code than Dart (or Java).

("cannot be tooled" is flat wrong, as past discussion here of
static+dynamic/live-system analysis concluded.)

To "inherent performance problems", I say "feature" and "optimize harder". But
it's worth mentioning, especially since you cited 'with', which is a bug that I brought ;-). Stupid-dynamic
is just stupid and we should avoid it.

Freedom without fences and other tools for accountability fails at scale.
I still don't agree with `with' being a failure (perhaps the syntax
ended up too ambiguous, yeah, and the thing about being able to change
the shape of the objects and all, but...), I agree with the "optimise
harder" though.

I wonder if it was the Racket guys who said that languages should indeed
be dynamic, so compiler writers have more work to do :3

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

Re: Minimalist Classes

On Nov 2, 2011, at 10:42 AM, Erik Corry wrote:

>  C++ requires you to state the name of the super-class in super
> calls, and Java doesn't.  Do we want to be like Java? 

Wimpy Troll, easily defeated. We want to be like Ruby and CoffeeScript!

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

Re: Minimalist Classes

On Nov 2, 2011, at 10:35 AM, David Bruant wrote:

> Le 02/11/2011 18:09, Brendan Eich a écrit :
>> On Nov 2, 2011, at 4:10 AM, David Bruant wrote:
>> 
>>> Another topic:
>>> -
>>> class Monster {
>>> 
>>>  private name, health;
>>> 
>>>  sameName(other) {
>>>return @name === other@name;
>>>  }
>>> }
>>> -
>>> I am under this impression that you are accessing the private property 
>>> ("other@name") of an instance which isn't you (other !== this) and I'm not 
>>> sure it's a good idea.
>> Private names do not leak via reflection, not even via proxies. So what's 
>> the problem?
> My problem is that private names are per-class instead of per-instance.

See my reply to Kam. We're not sugaring instance-private ivars. I am proposing 
something we agreed to in Nov. 2008: sugaring class-private ivars.

You can make instance-private ivars yourself in the constructor using 
Name.create, and go to town. Knock yourself out! (I mean that in a good way, at 
least from where I sit :-P).

>>> Is "other" a monster? (how do you "recognize" a monster from any other 
>>> object?).
>> You could do ad-hoc type or shape tests. For the example, and even in most 
>> cases in general, there's no need. Duck typing works with private names too.
> Who is "you" in your case? My "you" was "runtime". I think runtime
> shouldn't do heuristic-tests like comparing shapes.

We don't have types. I have no idea what you are proposing, but my point 
stands: there's no need to recognize another Monster and no capability leak. 
The code works as much JS today does with public property names.

/be

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

On Nov 2, 2011, at 9:51 AM, Mikeal Rogers wrote:

> On Nov 2, 2011, at November 2, 20119:30 AM, Quildreen Motta wrote:
>> 
>>> "freeze" does not add anything new to an object. If you don't want to 
>>> change the shape of an object ... don't change the shape of the object.
>> Again, immutability isn't just about security, but optimisation as well. You 
>> could also look at shared-memory threads, because I think they make a hell 
>> of an argument for "frozen" objects or immutability.
> 
> The last time we looked at freezing a few core objects in node.js we found 
> that v8 was actually slower with them frozen and backed them out, which is 
> probably a good thing.
> 
> I'm very skeptical of the "new language feature for optimization" argument 
> ever since the static typing debate in ES4 and the tracer work Mozilla did 
> shortly after.

Type inference is doing well for us now. I agree in general.

However, there's a reason Dart did what it did. With JS, you have to guard, or 
provide an invalidation protocol, in case someone shadows an inherited property:

var a = [],
b = {m: function (i) { return i * i; }},
c = Object.create(b),
d = Object.create(c);

for (var i = 0; i < BIG; i++) {
  a[i] = d.m(i);
  if (rarely(i)) {
c.m = function (i) { return 42 * i; };
  }
}

This is a contrived case, but in general, because JS objects are mutable, and 
when they're used as prototypes they stand in for class vtables, something has 
to pay a price. Either you worry about checking on every d.m(i) call that the 
cached target method in b is still the one to call, or you emit code that 
doesn't check but tear it up and throw it away when c.m is injected and shadows 
b.m.

This is fine with me and worth the price, but it clearly is not for everyone. 
I'm not just talking about implementors, either. Some users will want to know 
d.m isn't going to change. They may not want to know that it's b.m, mind you -- 
they simply won't want that c.m assignment to be legal, or else if they do 
support such a thing, they don't want it to affect d's "vtable".

Ok, so such people should use another language than JS. Or, perhaps, they could 
freeze c and b. Then they'd have parity, once V8 and other engines got around 
to optimizing accordingly. (It's bogus for you to infer too much from the state 
of optimization vs. new features.)

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

Le 02/11/2011 17:05, Jeremy Ashkenas a écrit :
> On Wed, Nov 2, 2011 at 11:01 AM, David Bruant  > wrote:
>
> Could you elaborate on this point? 
> All object-lockdown I can think (non-configurability,
> non-writability, non-enumerability, private names, const
> variables, const classes) of is optional. Why are you against them?
>
> I was about to say "if you're unsatisfied, create a language which
> doesn't provide features you don't like, like Coffeescript",
> but... humm...
> So, why being against the introduction of features in the language?
>
>
> I'd be glad to elaborate -- but since it's off topic for minimal
> classes, changing the Subject here.
Thanks for your response.

>
> What draws people to dynamic languages is freedom.
What drew people to JavaScript originally was that it was the only
language of the web on the client-side. No other reason. If the language
used to manipulate the DOM had been strongly typed, that's what we would
be using. If from the start it had non-mutable prototype, we couldn't
have fixed most browser bugs, write things like es5-shim or a bunch of
other polyfills. (by the way, thanks M.Eich for including this brilliant
idea in JS!)

> If I had my druthers, JS.next would generally embrace the spirit of
> JavaScript's dynamism (and freedom), and try to push those aspects
> further -- with better introspection and more flexibility -- instead
> of compromising with more restrictive static languages and adding
> lock-down keywords so that some programmers might "feel safer".
>
> Let's set arguments about security and constraint guarantees aside for
> a moment (although I'd be glad to have those as well)
Well, let's talk about it. Why on Earth am I forced to open an iframe to
safely discuss with another script? That's such a waste of resources.
And how can mutually suspicious scripts can communicate safely in JS
environment where there are no iframes? Well... they can't... (with SES,
now they can, but it took some time)
We have accepted that people can't use scripts from different origins
for the only reason that JS had no way to write programs defensively and
because there is no way to take a script from somewhere else and prevent
it from breaking everything.


> and talk about these keywords as pure features:
>
> "private" does not add anything new to a property. If you don't want
> the property to be used outside of the class ... don't use the
> property outside of the class.
>
> "const" does not add anything new to a variable. If you don't want to
> change the value of a variable ... don't change the value of the
> variable. 
>
> "freeze" does not add anything new to an object. If you don't want to
> change the shape of an object ... don't change the shape of the object.
Following this logic, "var" does not add anything to a variable. If you
don't want the variable to be used outside a function... don't use it
outside the function.
Are you also against "let"? it reduces even more where a variable can be
accessed.

More seriously, if you're the only programmer, yes, I agree with what
you said. If I give you a library, without telling you what is private
and what isn't, you are likely to break the library. If I keep private
what should be, you won't mess with my code. Using private
variables/properties is a way for me to make sure you do not use what
you shouldn't. It protects you from changes if I do internal changes to
my library.
The less I allow you to do, the stricter is your use of my library and
the less work you need to do.


> Note that Ruby, another very dynamic language, has "private" and
> constants. And yet private methods can be called from the outside,
> with "send", and contants can be explicitly overwritten with new
> values. They are simply red tape, not concrete walls. For better or
> for worse, I have very rarely seen a large-scale Ruby project that
> does *not* call a private method externally, or overwrite a constant
> during configuration.
If a private method can be accessed externally, well, it's not private.
If you can change a constant, it is not a constant, regardless of what
keyword can say.


> The recent JavaScript renaissance that we're all enjoying owes debts
> to JavaScript's foresight as a "free", dynamic language. If all of the
> JavaScript core object had been frozen, locked down with private
> methods, and set as const properties on the global object, libraries
> like Prototype.js never would have happened. Libraries like jQuery
> would have been much more difficult to imagine. We might not have the
> new Array#map, #reduce, #every, or #filter methods at all.
I cannot agree more. In no way I am advocating for "locked-down by default".
What I'm advocating for is "i can lock things down if I want to in my
application". This is what "const", "private" and the like offer. The
option for me to make my choice.
I don't want locking things down. I just want the choice to do it myself
in my ap

Re: Minimalist Classes


On 02/11/11 15:42, Erik Corry wrote:

2011/11/2 Quildreen Motta:

I don't think hard coding the name of the super-constructor is a
problem.

It is when you take into account that functions in JavaScript are not bound
to an object, they are generic. You can simply assign any function to any
object and it'll most likely just work.

I think the chances are slim that you can take a function that does a
super call, put it on a different object, and it will 'just work'.
It's a pretty rare case.
"most likely". Also, it should work if |super| were dynamically 
resolved, as long as the object implemented what's required by the call.

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

Re: Minimalist Classes

2011-11-02 Thread David Flanagan


On 11/1/11 11:53 PM, Brendan Eich wrote:

On Nov 1, 2011, at 10:27 PM, David Flanagan wrote:
1) Class bodies are new syntax, so you can introduce new keywords, 
right?  So 'prop' or 'proto'?  'static' puts a property on the class. 
 'private' puts a (private) property on the instance.  So 'proto' 
could put a property on the prototype.


Yes, but prefix keywords in front of every member? Too heavy. Labeled 
sections are problematic grammatically and most on TC39 hate 'em. 
prefixed braced sub-bodies over-indent.


There ought to be a sane unprefixed default. Then, though, we still 
have two choices:


(a) Data property initialiser syntax (x: v with comma separator).

(b) Assignment expression form (x = v with semicolon separator or 
terminator and some kind of ASI consistency).


Neither is great. I lean toward (b). You?


I don't see why you can't use var syntax but with 'proto' as the keyword 
instead of 'var':


// All instances inherit these default values:
proto x = 0, y = 0;

Similarly for static members as well:

   static const ORIGIN = new Point(0,0), ONE = new Point(1,0);

Of course, that takes you away from unification with object literals 
again...  Though I don't think unifiying class bodies and object 
literals was one of your original goals.



Your private instance variables are quite interesting.


Yes, that is a missing ingredient in most proposals we've seen.

And inquiring minds want to know more about them.  I assume they're 
scoped to the entire class body, right?  And they hoist to the top?  
Could they have initializers that were automatically included in the 
constructor?


A comment in your gist (lines 186-187) seems to say that with 'private 
x', we can use @x or this[x].  Is that really what you meant?  Plain 'x' 
is bound to the Name object and @x is the value of the property with 
that name?  Is x a variable? Does this mean that the class desugars into 
something that has a let statement surrounding the all the methods?


One nit: you're using @ as both a sigil in @name and as an operator 
in other@name.  I would expect other.@name instead.


No, it's a prefix operator if in operand context (like / starting a 
regexp), a binary operator in operator context (/ as division).


Trying to avoid .@ all over, and this.@ noise.

I think ordinary unary @ would dominate and .@ would be relatively 
rare.  But when used, it would at least look like noisy property access 
rather than an email address.  My gut says that regularity of syntax 
wins over conciseness and noise here.




And a question: do we really need both the private declaration and 
the sigil?


Yes. Otherwise the private declaration takes over all dot references 
of any such name, and that's wrong. We have no static types to 
consult, so we have to use a different sigil/operator.


I'm not convinced that public and private properties ought to be in 
different namespaces, though I can see that that would have some advantages.


Note @ in Ruby for instance-private ivars. You have to message an 
"other" parameter to get its x and y (if it's a point) or have that 
message send fail at runtime -- or check its type in your dyadic 
method and double-dispatch, etc.



But more to the point, you've defined a syntax that allows us to drop 
'this' from our methods!  That's seriously cool.


Only for private vars.


So cool that I expect using private properties will become the 
default and normal public properties will be the exception. 
 Unless... Can you also allow 'this' to be dropped for public 
instance variables? With a 'public' declaration and/or a different sigil?


We could use the same sigil/namespace, but then public and private 
names could collide and that seems future hostile. I may have API 
growth where a common name I've used for a private is now required for 
a public in order to interface to some third party code.



Because the private names are private, changing them would be easy to 
do, at least...


Do you expect the performance of private property lookup to be 
equivalent to public property lookup?  That is will @foo take the same 
time as this.foo?  Because everyone is going to want to use @foo for its 
convenience if there is not an equivalent trick for public properties.


What about just a dot with nothing on the left hand side?  Can '.foo' 
be shorthand for 'this.foo'?  Or are there grammatical issues with that?


That could work with [no LineTerminator here] restriction on the left, 
which is awkward -- it mandates manual semicolon insertion of you 
assign .foo = bar after a baz() statement. We thought about this in 
consider how to reform with, but that's a dead end.

You're right.  Plain dot doesn't work.


Another sigil is hard to justify for the this.publicProp case, and for 
dyadic methods, etc., other.publicProp is how you spell it -- the dot, 
I mean. So one would want this.publicProp anyway. Between this 
consideration and the preference for private, I'm fine stopping with @ 
for priva

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...


On 02/11/11 15:41, Brendan Eich wrote:

On Nov 2, 2011, at 9:26 AM, John J Barton wrote:


Of course these details are
important for the use-cases that need them. Unfortunately everyone
else has to carry the baggage.

What exactly do you mean by "carry"?

Implementors have to implement. They get the big bucks and bear the burden for 
the greater good.

Most users *do not* have to carry all the ES5 APIs in their head. Almost no users ever 
even need to use Object.create. Perhaps this is a missed opportunity, but that's a 
different argument from what your use of "carry" implies.
Imho, no users *SHOULD* use Object.create directly. That's why 
abstractions exist — and first class functions make it easy enough to 
make them.


Also, there are plenty of libraries provide nice abstractions over the 
low-level part of the language (pd being the simplest one, I guess), to 
a point I think criticising a built-in feature for being "too generic" 
is kind of missing the point...


It's been this way with the DOOM too, isn't it?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

On Nov 2, 2011, at 9:46 AM, Mikeal Rogers wrote:

> I agree with every sentence in this post.
> 
> +1K :)

Switching to CoffeeScript? :-P

/be

> 
> -Mikeal
> 
> On Nov 2, 2011, at November 2, 20119:05 AM, Jeremy Ashkenas wrote:
> 
>> On Wed, Nov 2, 2011 at 11:01 AM, David Bruant  wrote:
>> Could you elaborate on this point? 
>> All object-lockdown I can think (non-configurability, non-writability, 
>> non-enumerability, private names, const variables, const classes) of is 
>> optional. Why are you against them?
>> 
>> I was about to say "if you're unsatisfied, create a language which doesn't 
>> provide features you don't like, like Coffeescript", but... humm...
>> So, why being against the introduction of features in the language?
>> 
>> I'd be glad to elaborate -- but since it's off topic for minimal classes, 
>> changing the Subject here.
>> 
>> What draws people to dynamic languages is freedom.
>> 
>> And JavaScript is one of the *most* dynamic of the mainstream programming 
>> languages. Not only can you can pass any object to any function, but you can 
>> call a method with any number of arguments, easily modify the prototypes of 
>> other objects, introspect on any object's properties with a simple loop, 
>> replace any member function with a wrapped version, attach new properties to 
>> any object ... the list goes on.
>> 
>> If I had my druthers, JS.next would generally embrace the spirit of 
>> JavaScript's dynamism (and freedom), and try to push those aspects further 
>> -- with better introspection and more flexibility -- instead of compromising 
>> with more restrictive static languages and adding lock-down keywords so that 
>> some programmers might "feel safer".
>> 
>> Let's set arguments about security and constraint guarantees aside for a 
>> moment (although I'd be glad to have those as well), and talk about these 
>> keywords as pure features:
>> 
>> "private" does not add anything new to a property. If you don't want the 
>> property to be used outside of the class ... don't use the property outside 
>> of the class. 
>> 
>> "const" does not add anything new to a variable. If you don't want to change 
>> the value of a variable ... don't change the value of the variable. 
>> 
>> "freeze" does not add anything new to an object. If you don't want to change 
>> the shape of an object ... don't change the shape of the object.
>> 
>> Note that Ruby, another very dynamic language, has "private" and constants. 
>> And yet private methods can be called from the outside, with "send", and 
>> contants can be explicitly overwritten with new values. They are simply red 
>> tape, not concrete walls. For better or for worse, I have very rarely seen a 
>> large-scale Ruby project that does *not* call a private method externally, 
>> or overwrite a constant during configuration.
>> 
>> The recent JavaScript renaissance that we're all enjoying owes debts to 
>> JavaScript's foresight as a "free", dynamic language. If all of the 
>> JavaScript core object had been frozen, locked down with private methods, 
>> and set as const properties on the global object, libraries like 
>> Prototype.js never would have happened. Libraries like jQuery would have 
>> been much more difficult to imagine. We might not have the new Array#map, 
>> #reduce, #every, or #filter methods at all.
>> 
>> Can a free, dynamic language be abused? Certainly. Is Prototype.js 
>> dangerous? For some websites, it can be (including NYTimes.com, where I 
>> work).
>> 
>> The freedom of having every object and every property be configurable, 
>> settable, introspectable, readable and writable, at least at the language 
>> level, is worth the trade off. If we add const, private, and other lock-down 
>> syntax, or make class properties private by default (shudder), I guarantee 
>> you that many potential innovative libraries that otherwise might spring up 
>> will never even be conceived, and frustrating situations that could have 
>> otherwise been solved by a quick patch will instead require convoluted 
>> work-arounds.
>> 
>> JavaScript should be about making it easier to write the right thing, and 
>> not so much about making it harder to do the wrong thing. After all, the 
>> former is purely positive, and the latter assumes that you know better than 
>> the engineer who comes after you. In the real world, you often don't.
>> 
>> Cheers,
>> Jeremy
>> 
>> ___
>> 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: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

On Nov 2, 2011, at 9:30 AM, Quildreen Motta wrote:

> Also, note that `with' makes a whole awesome use-case for `Object.freeze':

'with' is gone in ES5 strict, ES6, and beyond -- you knew that, right?

> ---
> with (require({'library1': 'lib1'}, {'library2': 'lib2'})) {
>   lib1.foo(lib2.something)
> }

This is still hard to optimize, even with the implied freeze under require.

Also, you can't load code dynamically without nesting an event loop and 
violating run-to-completion, so I'm not sure how such a require would work.

This does remind me: JS's "freedom" is Dart's "cannot be tooled" and "inherent 
performance problems", and without aggressive optimization work it can mean JS 
is measurably slower for some kinds of code than Dart (or Java).

("cannot be tooled" is flat wrong, as past discussion here of 
static+dynamic/live-system analysis concluded.)

To "inherent performance problems", I say "feature" and "optimize harder". But 
it's worth mentioning, especially since you cited 'with', which is a bug that I 
brought ;-). Stupid-dynamic is just stupid and we should avoid it.

Freedom without fences and other tools for accountability fails at scale.

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

Re: Minimalist Classes

2011-11-02 Thread Erik Corry

2011/11/2 Quildreen Motta :
>> I don't think hard coding the name of the super-constructor is a
>> problem.
>
> It is when you take into account that functions in JavaScript are not bound
> to an object, they are generic. You can simply assign any function to any
> object and it'll most likely just work.

I think the chances are slim that you can take a function that does a
super call, put it on a different object, and it will 'just work'.
It's a pretty rare case.

 C++ requires you to state the name of the super-class in super
calls, and Java doesn't.  Do we want to be like Java? 

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

On Nov 2, 2011, at 9:26 AM, John J Barton wrote:

> Of course these details are
> important for the use-cases that need them. Unfortunately everyone
> else has to carry the baggage.

What exactly do you mean by "carry"?

Implementors have to implement. They get the big bucks and bear the burden for 
the greater good.

Most users *do not* have to carry all the ES5 APIs in their head. Almost no 
users ever even need to use Object.create. Perhaps this is a missed 
opportunity, but that's a different argument from what your use of "carry" 
implies.

/be

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

On Nov 2, 2011, at 9:05 AM, Jeremy Ashkenas wrote:

> I'd be glad to elaborate -- but since it's off topic for minimal classes, 
> changing the Subject here.

Thanks for that.

> What draws people to dynamic languages is freedom.
> 
> And JavaScript is one of the *most* dynamic of the mainstream programming 
> languages. Not only can you can pass any object to any function, but you can 
> call a method with any number of arguments, easily modify the prototypes of 
> other objects, introspect on any object's properties with a simple loop, 
> replace any member function with a wrapped version, attach new properties to 
> any object ... the list goes on.

This was a calculated move on my part. I didn't have time to get everything 
hooked up (or upholstered ;-), so I made almost everything mutable (note how 
Date.prototype, the property not the object value it references, is 
non-configurable and non-writable; same for other built-ins). This let JS 
library and app authors monkeypatch and finish things.

Now, 16 years later, JS is in a bigger world, it has grown, and three things 
have happened:

1. Library authors learned the hard way not to patch built-ins, unless the 
library is Prototype or you take Andrew's "everything is permitted" seriously 
(many do not).

2. Web developers both depend on and wish to minimize the size (to zero bytes) 
of libraries.

3. Programming in the large, even ignoring security, means many of us want to 
save ourselves from assigning to something we want non-writable and 
initialize-only. That's const. Or we want to avoid name collision worries, 
never mind hostile attacks, on private data. That's private, or else you use 
closures and pay some non-trivial price (verbosity and object allocation).

(3) implies adding encapsulation and integrity features, on an opt-in basis.

(2) means we keep working on the language, until it reaches some 
macro-apotheosis.

(1) does not imply the standard built-in constructors and their prototypes 
could be frozen -- don't worry about that. We won't break the web. But it 
suggests that users do not always need all dynamic degrees of freedom, all the 
time. Some, say SES users, will need to freeze their built-ins in order to 
build secure mash-ups. ES5 allows this. Why not?

My freedom to build a fence doesn't mean I lock the gate. But if I'm dealing 
with miscreants in the neighborhood, maybe I do put in a lock. Maybe I put in 
ice-guns and snowball launchers. My choice to do so is part of this "freedom" 
you advocate. Right?

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

Re: Minimalist Classes

Le 02/11/2011 18:09, Brendan Eich a écrit :
> On Nov 2, 2011, at 4:10 AM, David Bruant wrote:
>
>> Another topic:
>> -
>> class Monster {
>>
>>   private name, health;
>>
>>   sameName(other) {
>> return @name === other@name;
>>   }
>> }
>> -
>> I am under this impression that you are accessing the private property 
>> ("other@name") of an instance which isn't you (other !== this) and I'm not 
>> sure it's a good idea.
> Private names do not leak via reflection, not even via proxies. So what's the 
> problem?
My problem is that private names are per-class instead of per-instance.
This is saying that an instance cannot isolate itself from other
instances of the same class.
It doesn't smell good to me in terms of encapsulation.
I am a human being, you are a human being. It doesn't mean we can trust
each other. If I have a password in my head, I don't want you to be able
to access it just because we are both human beings. I want my password
to be safe from foxes, cats, but also other human beings.

>> Is "other" a monster? (how do you "recognize" a monster from any other 
>> object?).
> You could do ad-hoc type or shape tests. For the example, and even in most 
> cases in general, there's no need. Duck typing works with private names too.
Who is "you" in your case? My "you" was "runtime". I think runtime
shouldn't do heuristic-tests like comparing shapes.

>> If so, is it a good enough reason for you to be able to access its private 
>> state?
> It must be an instance of this class or the name would not be bound.
Is it a good idea that all instances of the same class can access each
others private state? I don't think this is possible in Java, I don't
know an object-oriented language where this is possible. Is there a
precedent of this? Doesn't it break encapsulation?
I think that private names should be "per-instance per-property" rather
than "per-class per-property".

"it must be an instance of this class". I'd like to ask the question
again, how does runtime knows that an object is a instance of a given
class? Will there be an internal property for this? [[Class]]? What is
the value of this internal property for objects not created with classes?

>> What happens in the following case?
>> -
>> class Monster{
>>   private health;
>>   
>>   constructor(health) {
>> @health = health;
>>   }
>> }
>>
>> let m = new Monster(100);
>>
>> // pass m to a potentially malicious script:
>>
>> m.kill = function(){
>>   @health = 0;
> health is not in scope here!
Ok, cool :-)

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

Re: Minimalist Classes

On Nov 2, 2011, at 8:25 AM, Kam Kasravi wrote:

> Does object@name break encapsulation? One could mutate object@name for any 
> instance of the class passed in via a parameter for example. 

At the Nov. 2008 TC39 meeting, we agreed on class-private instance variables, 
not instance-private ivars. There's no "break encapsulation" -- this is a 
difference in point of view. Classes are the locus or privacy, not instances. 
You cannot access a class-private ivar outside of the class's methods.

/be


> 
> On Nov 2, 2011, at 8:01 AM, David Bruant  wrote:
> 
>> Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
>>> 
>>> (Full Disclosure: I'm still very opposed to const, private, and their 
>>> object-lockdown friends, ) 
>> Could you elaborate on this point? 
>> All object-lockdown I can think (non-configurability, non-writability, 
>> non-enumerability, private names, const variables, const classes) of is 
>> optional. Why are you against them?
>> 
>> Regarding "const", it's an optional keyword basically telling the 
>> interpreter "hey, the value isn't suppose to change at runtime, please 
>> ensure it!". It prevents bugs of mistakenly redefining something that 
>> shouldn't be redefined. Why are you opposed to this?
>> 
>> Regarding "private", I'm puzzled. Having private attributes in objects is 
>> necessary to implement encapsulation and get all the benefits of good 
>> object-oriented practices.
>> A generation of JS programmers have used scope constructs and the "var" 
>> keyword to enable some privacy. I'm all in favor of providing a declarative 
>> support for what people have done for years anyway. What is wrong with 
>> "private"?
>> 
>> Once again, all of this is optional, nothing forces you to use new features 
>> of the language. I will personnally never use multi-line strings, but I 
>> don't mind the feature being in the language.
>> 
>> I was about to say "if you're unsatisfied, create a language which doesn't 
>> provide features you don't like, like Coffeescript", but... humm...
>> So, why being against the introduction of features in the language?
>> 
>> David
>> ___
>> 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: Minimalist Classes

On Nov 2, 2011, at 6:26 AM, Jeremy Ashkenas wrote:

> That said, we should take care to have the two things be fully consistent: A 
> class body should *be* an object literal, with no subtle differences in the 
> grammar leading to stumbling blocks down the line. If class bodies can have:
> 
> class Runner {
>   run() {
> ...
>   }
>   private quit() {
> ...
>   }  
>   const speed: 10
> }
> 
> ... then an object literal should equally be able to have an identical body:
> 
> var runner = {
>   run() {
> ...
>   }
>   private quit() {
> ...
>   }  
>   const speed: 10
> };
> 
> ... as const properties and private methods on single objects are just as 
> useful and important as const properties and private methods on objects that 
> happen to be instances of a class.

I quite agree -- but I was focused on classes in that gist, not ready to take 
on object literals. I am sure Allen agrees, and probably most of TC39. We'll 
see.

> (Full Disclosure: I'm still very opposed to const, private, and their 
> object-lockdown friends, but that should have no bearing on Brendan's 
> proposal.) 

Sometimes you need to lock a door. Not having these facilities means you can't 
guarantee certain invariants. OTOH I bet you're worried everyone will do the 
stupid thing and lock down by default. That's not likely to survive on github 
or any JS library ecosystem where consumers have choice, so why worry?

As for private, if it's ok for Ruby to have @vars, it's ok for JS :-P.

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

Re: Minimalist Classes

On Nov 2, 2011, at 5:34 AM, Axel Rauschmayer wrote:

> I think the namespacing via this is a feature, it give the code a nice 
> uniform look:
> if (this.foo === other.foo)

You can use this@priv == other@priv if you like. My proposal, after Ruby and 
CoffeeScript, is to support @priv (with [no LineTerminator here] before the @) 
as shorthand for this@priv.

Try it out, you'll like it -- especially where there's no other@priv in sight.

/be

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

Re: Minimalist Classes

On Nov 2, 2011, at 4:10 AM, David Bruant wrote:

> Another topic:
> -
> class Monster {
> 
>   private name, health;
> 
>   sameName(other) {
> return @name === other@name;
>   }
> }
> -
> I am under this impression that you are accessing the private property 
> ("other@name") of an instance which isn't you (other !== this) and I'm not 
> sure it's a good idea.

Private names do not leak via reflection, not even via proxies. So what's the 
problem?


> Is "other" a monster? (how do you "recognize" a monster from any other 
> object?).

You could do ad-hoc type or shape tests. For the example, and even in most 
cases in general, there's no need. Duck typing works with private names too.


> If so, is it a good enough reason for you to be able to access its private 
> state?

It must be an instance of this class or the name would not be bound.


> If other is not a monster, what is the behavior?

You'd get undefined.


> What happens in the following case?
> -
> class Monster{
>   private health;
>   
>   constructor(health) {
> @health = health;
>   }
> }
> 
> let m = new Monster(100);
> 
> // pass m to a potentially malicious script:
> 
> m.kill = function(){
>   @health = 0;

health is not in scope here!

/be

> }
> m.kill();
> -
> Or, how do you prevent someone who has access to the object to define a 
> function which accesses the private state?
> Is the @-syntax only allowed within a class body?
> 
> David

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

On Nov 2, 2011, at November 2, 20119:30 AM, Quildreen Motta wrote:
> 
>> "freeze" does not add anything new to an object. If you don't want to change 
>> the shape of an object ... don't change the shape of the object.
> Again, immutability isn't just about security, but optimisation as well. You 
> could also look at shared-memory threads, because I think they make a hell of 
> an argument for "frozen" objects or immutability.

The last time we looked at freezing a few core objects in node.js we found that 
v8 was actually slower with them frozen and backed them out, which is probably 
a good thing.

I'm very skeptical of the "new language feature for optimization" argument ever 
since the static typing debate in ES4 and the tracer work Mozilla did shortly 
after.

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

2011-11-02 Thread Peter van der Zee

On Wed, Nov 2, 2011 at 5:44 PM, David Bruant  wrote:
> I agree that the second argument is a design mistake. But ES6 will fix
> this with the proto operator.

"fix"

It has the same kind of baggage and goes into the "minor features"
category, at least in terms of syntax, in my opinion.

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

I agree with every sentence in this post.

+1K :)

-Mikeal

On Nov 2, 2011, at November 2, 20119:05 AM, Jeremy Ashkenas wrote:

> On Wed, Nov 2, 2011 at 11:01 AM, David Bruant  wrote:
> Could you elaborate on this point? 
> All object-lockdown I can think (non-configurability, non-writability, 
> non-enumerability, private names, const variables, const classes) of is 
> optional. Why are you against them?
> 
> I was about to say "if you're unsatisfied, create a language which doesn't 
> provide features you don't like, like Coffeescript", but... humm...
> So, why being against the introduction of features in the language?
> 
> I'd be glad to elaborate -- but since it's off topic for minimal classes, 
> changing the Subject here.
> 
> What draws people to dynamic languages is freedom.
> 
> And JavaScript is one of the *most* dynamic of the mainstream programming 
> languages. Not only can you can pass any object to any function, but you can 
> call a method with any number of arguments, easily modify the prototypes of 
> other objects, introspect on any object's properties with a simple loop, 
> replace any member function with a wrapped version, attach new properties to 
> any object ... the list goes on.
> 
> If I had my druthers, JS.next would generally embrace the spirit of 
> JavaScript's dynamism (and freedom), and try to push those aspects further -- 
> with better introspection and more flexibility -- instead of compromising 
> with more restrictive static languages and adding lock-down keywords so that 
> some programmers might "feel safer".
> 
> Let's set arguments about security and constraint guarantees aside for a 
> moment (although I'd be glad to have those as well), and talk about these 
> keywords as pure features:
> 
> "private" does not add anything new to a property. If you don't want the 
> property to be used outside of the class ... don't use the property outside 
> of the class. 
> 
> "const" does not add anything new to a variable. If you don't want to change 
> the value of a variable ... don't change the value of the variable. 
> 
> "freeze" does not add anything new to an object. If you don't want to change 
> the shape of an object ... don't change the shape of the object.
> 
> Note that Ruby, another very dynamic language, has "private" and constants. 
> And yet private methods can be called from the outside, with "send", and 
> contants can be explicitly overwritten with new values. They are simply red 
> tape, not concrete walls. For better or for worse, I have very rarely seen a 
> large-scale Ruby project that does *not* call a private method externally, or 
> overwrite a constant during configuration.
> 
> The recent JavaScript renaissance that we're all enjoying owes debts to 
> JavaScript's foresight as a "free", dynamic language. If all of the 
> JavaScript core object had been frozen, locked down with private methods, and 
> set as const properties on the global object, libraries like Prototype.js 
> never would have happened. Libraries like jQuery would have been much more 
> difficult to imagine. We might not have the new Array#map, #reduce, #every, 
> or #filter methods at all.
> 
> Can a free, dynamic language be abused? Certainly. Is Prototype.js dangerous? 
> For some websites, it can be (including NYTimes.com, where I work).
> 
> The freedom of having every object and every property be configurable, 
> settable, introspectable, readable and writable, at least at the language 
> level, is worth the trade off. If we add const, private, and other lock-down 
> syntax, or make class properties private by default (shudder), I guarantee 
> you that many potential innovative libraries that otherwise might spring up 
> will never even be conceived, and frustrating situations that could have 
> otherwise been solved by a quick patch will instead require convoluted 
> work-arounds.
> 
> JavaScript should be about making it easier to write the right thing, and not 
> so much about making it harder to do the wrong thing. After all, the former 
> is purely positive, and the latter assumes that you know better than the 
> engineer who comes after you. In the real world, you often don't.
> 
> Cheers,
> Jeremy
> 
> ___
> 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: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

Le 02/11/2011 17:26, John J Barton a écrit :
> On Wed, Nov 2, 2011 at 9:05 AM, Jeremy Ashkenas  wrote:
>> On Wed, Nov 2, 2011 at 11:01 AM, David Bruant  wrote:
>>> Could you elaborate on this point?
>>> All object-lockdown I can think (non-configurability, non-writability,
>>> non-enumerability, private names, const variables, const classes) of is
>>> optional. Why are you against them?
> ...
>> The freedom of having every object and every property be configurable,
>> settable, introspectable, readable and writable, at least at the language
>> level, is worth the trade off. If we add const, private, and other lock-down
>> syntax, or make class properties private by default (shudder), I guarantee
>> you that many potential innovative libraries that otherwise might spring up
>> will never even be conceived, and frustrating situations that could have
>> otherwise been solved by a quick patch will instead require convoluted
>> work-arounds.
> Another maybe stronger argument is simplicity: these myriad new minor
> features create a blizzard of chaff in the way of developers. One
> excellent example is Object.create(). Here was a terrific opportunity
> to simplify the language based on years of experience and analysis.
> But instead of an object as a second argument, we got a descriptor
> requiring many details for each property. Of course these details are
> important for the use-cases that need them. Unfortunately everyone
> else has to carry the baggage.
I agree that the second argument is a design mistake. But ES6 will fix
this with the proto operator.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...


On 02/11/11 14:26, John J Barton wrote:
Another maybe stronger argument is simplicity: these myriad new minor 
features create a blizzard of chaff in the way of developers. One 
excellent example is Object.create(). Here was a terrific opportunity 
to simplify the language based on years of experience and analysis. 
But instead of an object as a second argument, we got a descriptor 
requiring many details for each property. Of course these details are 
important for the use-cases that need them. Unfortunately everyone 
else has to carry the baggage.
`Object.create' is not supposed to be used directly by end-users. It's 
for library writers. Library writers get the heavy weight and generic 
things, and transform that for a specific use-case. Of course, not 
having an `Object.extend' and other object composition functionality 
makes things a little too meh.

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

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...


On 02/11/11 14:05, Jeremy Ashkenas wrote:
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant > wrote:


Could you elaborate on this point?
All object-lockdown I can think (non-configurability,
non-writability, non-enumerability, private names, const
variables, const classes) of is optional. Why are you against them?

I was about to say "if you're unsatisfied, create a language which
doesn't provide features you don't like, like Coffeescript",
but... humm...
So, why being against the introduction of features in the language?


I'd be glad to elaborate -- but since it's off topic for minimal 
classes, changing the Subject here.


What draws people to dynamic languages is freedom.
I'd put `extensibility' and `expressivity' here instead, but sure. And 
JavaScript does pretty good at that --- not as much as Lisp, but oh 
well, it's not like I expected a C-family language to be that extensible :3


If I had my druthers, JS.next would generally embrace the spirit of 
JavaScript's dynamism (and freedom), and try to push those aspects 
further -- with better introspection and more flexibility -- instead 
of compromising with more restrictive static languages and adding 
lock-down keywords so that some programmers might "feel safer".

Agreed. But there are other things here other than "security constraints".

"private" does not add anything new to a property. If you don't want 
the property to be used outside of the class ... don't use the 
property outside of the class.
I still haven't found an use to private either, to be honest. Granted I 
often declare "private" functions and variables inside a closure, I 
always export them in an `internal' object, so it doesn't clutter the 
core API.


"const" does not add anything new to a variable. If you don't want to 
change the value of a variable ... don't change the value of the 
variable.
I'm not sure I agree here. Constants are not about security they're 
about abstractions. You name something that you'd otherwise have to 
write as a regular expression. In this case, they'd be like a really 
simple inline function, except they do no transformations.


"freeze" does not add anything new to an object. If you don't want to 
change the shape of an object ... don't change the shape of the object.
Again, immutability isn't just about security, but optimisation as well. 
You could also look at shared-memory threads, because I think they make 
a hell of an argument for "frozen" objects or immutability.


JavaScript should be about making it easier to write the right thing, 
and not so much about making it harder to do the wrong thing. After 
all, the former is purely positive, and the latter assumes that you 
know better than the engineer who comes after you. In the real world, 
you often don't.
Agreed, but note that none of the features above preclude JavaScript 
from being a free language that makes it easier to write the right 
thing. It'll be just as expressive as before. Also note that you can 
already achieve all of those functionality in current JavaScript, so 
having class-literals, as a declarative syntax, support them in a nice 
way is okay.


It's not like any feature can't be abused as you say. But the fact that 
a feature can be abused doesn't mean it should be never considered. 
JavaScript's `with' is a good example of that. You could create the most 
awesome and expressive module library using that, but no vendors have 
optimized it (as far as I know) because people considered it could only 
ever be abused and haven't used it.


Also, note that `with' makes a whole awesome use-case for `Object.freeze':

---
with (require({'library1': 'lib1'}, {'library2': 'lib2'})) {
  lib1.foo(lib2.something)
}
// Would be equivalent to Python's
// import library1 as lib1
// import library2 as lib2
//
// But restricted to a block.
---

You could also use it as a dynamic let, and just as long as you freeze 
the object passed to `with', there's no reason one shouldn't optimize it 
as just a regular EnvironmentRecord lookup. Using `let' instead of `var' 
removes the thing about variable hoisting declaring the variable outside 
of the `with' scope, etc.


tl;dr; While `private', `const' and `freeze' could certainly be abused, 
that doesn't mean they don't have value... well, perhaps except for 
`private'.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

2011-11-02 Thread John J Barton

On Wed, Nov 2, 2011 at 9:05 AM, Jeremy Ashkenas  wrote:
> On Wed, Nov 2, 2011 at 11:01 AM, David Bruant  wrote:
>>
>> Could you elaborate on this point?
>> All object-lockdown I can think (non-configurability, non-writability,
>> non-enumerability, private names, const variables, const classes) of is
>> optional. Why are you against them?
...
> The freedom of having every object and every property be configurable,
> settable, introspectable, readable and writable, at least at the language
> level, is worth the trade off. If we add const, private, and other lock-down
> syntax, or make class properties private by default (shudder), I guarantee
> you that many potential innovative libraries that otherwise might spring up
> will never even be conceived, and frustrating situations that could have
> otherwise been solved by a quick patch will instead require convoluted
> work-arounds.

Another maybe stronger argument is simplicity: these myriad new minor
features create a blizzard of chaff in the way of developers. One
excellent example is Object.create(). Here was a terrific opportunity
to simplify the language based on years of experience and analysis.
But instead of an object as a second argument, we got a descriptor
requiring many details for each property. Of course these details are
important for the use-cases that need them. Unfortunately everyone
else has to carry the baggage.

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

Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

2011-11-02 Thread Jeremy Ashkenas

On Wed, Nov 2, 2011 at 11:01 AM, David Bruant  wrote:

> Could you elaborate on this point?
> All object-lockdown I can think (non-configurability, non-writability,
> non-enumerability, private names, const variables, const classes) of is
> optional. Why are you against them?
>
> I was about to say "if you're unsatisfied, create a language which doesn't
> provide features you don't like, like Coffeescript", but... humm...
> So, why being against the introduction of features in the language?
>

I'd be glad to elaborate -- but since it's off topic for minimal classes,
changing the Subject here.

What draws people to dynamic languages is freedom.

And JavaScript is one of the *most* dynamic of the mainstream programming
languages. Not only can you can pass any object to any function, but you
can call a method with any number of arguments, easily modify the
prototypes of other objects, introspect on any object's properties with a
simple loop, replace any member function with a wrapped version, attach new
properties to any object ... the list goes on.

If I had my druthers, JS.next would generally embrace the spirit of
JavaScript's dynamism (and freedom), and try to push those aspects further
-- with better introspection and more flexibility -- instead of
compromising with more restrictive static languages and adding lock-down
keywords so that some programmers might "feel safer".

Let's set arguments about security and constraint guarantees aside for a
moment (although I'd be glad to have those as well), and talk about these
keywords as pure features:

"private" does not add anything new to a property. If you don't want the
property to be used outside of the class ... don't use the property outside
of the class.

"const" does not add anything new to a variable. If you don't want to
change the value of a variable ... don't change the value of the variable.

"freeze" does not add anything new to an object. If you don't want to
change the shape of an object ... don't change the shape of the object.

Note that Ruby, another very dynamic language, has "private" and constants.
And yet private methods can be called from the outside, with "send", and
contants can be explicitly overwritten with new values. They are simply red
tape, not concrete walls. For better or for worse, I have very rarely seen
a large-scale Ruby project that does *not* call a private method
externally, or overwrite a constant during configuration.

The recent JavaScript renaissance that we're all enjoying owes debts to
JavaScript's foresight as a "free", dynamic language. If all of the
JavaScript core object had been frozen, locked down with private methods,
and set as const properties on the global object, libraries like
Prototype.js never would have happened. Libraries like jQuery would have
been much more difficult to imagine. We might not have the new Array#map,
#reduce, #every, or #filter methods at all.

Can a free, dynamic language be abused? Certainly. Is Prototype.js
dangerous? For some websites, it can be (including NYTimes.com, where I
work).

The freedom of having every object and every property be configurable,
settable, introspectable, readable and writable, at least at the language
level, is worth the trade off. If we add const, private, and other
lock-down syntax, or make class properties private by default (shudder), I
guarantee you that many potential innovative libraries that otherwise might
spring up will never even be conceived, and frustrating situations that
could have otherwise been solved by a quick patch will instead require
convoluted work-arounds.

JavaScript should be about making it easier to write the right thing, and
not so much about making it harder to do the wrong thing. After all, the
former is purely positive, and the latter assumes that you know better than
the engineer who comes after you. In the real world, you often don't.

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

Re: Minimalist Classes

>> That said, there are some valid use-cases for it... I guess?
> Encapsulation? Stability of interfaces? Better readability? The use case is 
> more about code quality and expressiveness rather than adding a new 
> capability to the language. 


The two most interesting use cases I see are (for all my other privacy needs I 
use naming conventions, but there are people who don’t like that):
- Avoid name clashes (e.g. when mixing in a trait, but also when doing 
subtyping).
- Enable special functionality. You could also use a naming convention here, 
but using a name object is nicer.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



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

Re: Minimalist Classes

Le 02/11/2011 16:15, Quildreen Motta a écrit :
> On 02/11/11 13:01, David Bruant wrote:
>> Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
>>> (Full Disclosure: I'm still very opposed to const, private, and
>>> their object-lockdown friends, )
>>
>> Regarding "const", it's an optional keyword basically telling the
>> interpreter "hey, the value isn't suppose to change at runtime,
>> please ensure it!". It prevents bugs of mistakenly redefining
>> something that shouldn't be redefined. Why are you opposed to this?
> Yeah, immutability and referential transparency are wonderful things.
> I wish JavaScript developers would rely more on it, it makes things
> saner to work with. Though is `const' the same as Object.freeze(thing)
> when `thing' is an object? Or does it just ensure that the slot in the
> object isn't reassigned?
It depends on the context. If const is used in front of a variable, the
variable value will remains constant. The definition of a const class is
given by Brendan (https://gist.github.com/1332193 ~l.239). There is a
semantics of const functions I don't remember.

>> Regarding "private", I'm puzzled. Having private attributes in
>> objects is necessary to implement encapsulation and get all the
>> benefits of good object-oriented practices.
> I still think `private' is quite overrated. It gets terrible if you
> want to test something and the developer went through all the trouble
> of making proxies to access everything, as well as making everything
> stateful.
If you stab me, I won't accuse the knife.
I agree with what you describe, but it's the problem of the developer
misusing the feature rather than an inherent problem of the feature itself.

> That said, there are some valid use-cases for it... I guess?
Encapsulation? Stability of interfaces? Better readability? The use case
is more about code quality and expressiveness rather than adding a new
capability to the language.

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

Re: Minimalist Classes

Does object@name break encapsulation? One could mutate object@name for any 
instance of the class passed in via a parameter for example. 

On Nov 2, 2011, at 8:01 AM, David Bruant  wrote:

> Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
>> 
>> (Full Disclosure: I'm still very opposed to const, private, and their 
>> object-lockdown friends, ) 
> Could you elaborate on this point? 
> All object-lockdown I can think (non-configurability, non-writability, 
> non-enumerability, private names, const variables, const classes) of is 
> optional. Why are you against them?
> 
> Regarding "const", it's an optional keyword basically telling the interpreter 
> "hey, the value isn't suppose to change at runtime, please ensure it!". It 
> prevents bugs of mistakenly redefining something that shouldn't be redefined. 
> Why are you opposed to this?
> 
> Regarding "private", I'm puzzled. Having private attributes in objects is 
> necessary to implement encapsulation and get all the benefits of good 
> object-oriented practices.
> A generation of JS programmers have used scope constructs and the "var" 
> keyword to enable some privacy. I'm all in favor of providing a declarative 
> support for what people have done for years anyway. What is wrong with 
> "private"?
> 
> Once again, all of this is optional, nothing forces you to use new features 
> of the language. I will personnally never use multi-line strings, but I don't 
> mind the feature being in the language.
> 
> I was about to say "if you're unsatisfied, create a language which doesn't 
> provide features you don't like, like Coffeescript", but... humm...
> So, why being against the introduction of features in the language?
> 
> David
> ___
> 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: Minimalist Classes


On 02/11/11 13:01, David Bruant wrote:

Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
(Full Disclosure: I'm still very opposed to const, private, and their 
object-lockdown friends, )


Regarding "const", it's an optional keyword basically telling the 
interpreter "hey, the value isn't suppose to change at runtime, please 
ensure it!". It prevents bugs of mistakenly redefining something that 
shouldn't be redefined. Why are you opposed to this?
Yeah, immutability and referential transparency are wonderful things. I 
wish JavaScript developers would rely more on it, it makes things saner 
to work with. Though is `const' the same as Object.freeze(thing) when 
`thing' is an object? Or does it just ensure that the slot in the object 
isn't reassigned?


Regarding "private", I'm puzzled. Having private attributes in objects 
is necessary to implement encapsulation and get all the benefits of 
good object-oriented practices.
I still think `private' is quite overrated. It gets terrible if you want 
to test something and the developer went through all the trouble of 
making proxies to access everything, as well as making everything stateful.


That said, there are some valid use-cases for it... I guess?

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

Re: Minimalist Classes

I don’t think Allen’s proposal is controversial, any more. It’s how things work 
in almost all mainstream (OO) languages. I don’t see myself using `super` 
anywhere outside an object literal – except for a few cases where 
Object.defineMethod() works just fine. Do you have any real-world examples 
where you want to use `super` outside an object literal? Caveat: In some 
contexts, you need the extension "monocle" operator to make object literals 
viable.

>> So it only works inside an object literal, whereas mine is easier to
>> understand and works anywhere.  If you are using it without any of the
>> other stuff you can even trivially get your minifier to desugar for
>> older browsers.
>> I don't think hard coding the name of the super-constructor is a
>> problem.


-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



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

Re: Minimalist Classes

Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
> (Full Disclosure: I'm still very opposed to const, private, and their
> object-lockdown friends, )
Could you elaborate on this point?
All object-lockdown I can think (non-configurability, non-writability,
non-enumerability, private names, const variables, const classes) of is
optional. Why are you against them?

Regarding "const", it's an optional keyword basically telling the
interpreter "hey, the value isn't suppose to change at runtime, please
ensure it!". It prevents bugs of mistakenly redefining something that
shouldn't be redefined. Why are you opposed to this?

Regarding "private", I'm puzzled. Having private attributes in objects
is necessary to implement encapsulation and get all the benefits of good
object-oriented practices.
A generation of JS programmers have used scope constructs and the "var"
keyword to enable some privacy. I'm all in favor of providing a
declarative support for what people have done for years anyway. What is
wrong with "private"?

Once again, all of this is optional, nothing forces you to use new
features of the language. I will personnally never use multi-line
strings, but I don't mind the feature being in the language.

I was about to say "if you're unsatisfied, create a language which
doesn't provide features you don't like, like Coffeescript", but... humm...
So, why being against the introduction of features in the language?

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

Re: Minimalist Classes


On 02/11/11 11:01, Erik Corry wrote:

2011/11/2 Axel Rauschmayer:

super Foo.bar(x) should desugar to Foo.prototype.bar.call(this, x)

http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super

What is that you don’t like about Allen’s proposal? You are still hard-coding 
the name of the super-constructor (which is what `super` nicely avoids).

"lookup starts with the object that is the prototype of the object
defined by the object literal that contains the reference to super."

So it only works inside an object literal, whereas mine is easier to
understand and works anywhere.  If you are using it without any of the
other stuff you can even trivially get your minifier to desugar for
older browsers.
I don't think hard coding the name of the super-constructor is a
problem.
It is when you take into account that functions in JavaScript are not 
bound to an object, they are generic. You can simply assign any function 
to any object and it'll most likely just work.


So, what I mean is that, if you have `super' resolve to a hard-coded 
constructor name this is what you get (hell, I don't even use 
constructors anymore, those ugly, ugly things):


---
function Thing(name) {
  this.name = name
}
Thing.prototype.describe = function(){
  console.log('A thing ' + this.name)
}

function Subject(name) {
  super.constructor(name)
}
Subject.prototype = Object.create(Thing.prototype)
Subject.prototype.constructor = Subject
Subject.prototype.describe = function() {
  super.describe()
  console.log('A subject ' + this.name)
}

// For now, all is well, `super' in Subject will always resolve to Thing.
var car = new Subject('car')
car.describe()
// => 'A thing car'
// => 'A subject car'

// But remember that you can take any function and assign to any object
// Such that the following wouldn't work -- we want Teddy to be just
// a Subject here, not a Thing.
var teddy = { name: 'teddy', describe: Subject.describe }
teddy.describe()
// => 'A subject teddy'
// => 'A thing teddy'.


// Whereas with Allen's proposal, everything would work okay:
var teddy = { name: 'teddy' }

// The defineMethod call creates a new function `describe' that
// has its |super| reference bound to teddy's prototype
Object.defineMethod(teddy, 'describe', Subject.describe)

// And the new `describe' function can use this static |super| to
// determine where lookup starts
teddy.describe()
// => 'A subject teddy'
---

Of course, applying a function to another object is a different matter, 
which won't be solved by static super.

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

Re: Minimalist Classes

2011-11-02 Thread Jeremy Ashkenas

On Tue, Nov 1, 2011 at 8:18 PM, Brendan Eich  wrote:

>
> Thanks, I did fork, and I made a Rich Corinthian Leather version, for the
> reasons given in the comments. In brief, I contend that over-minimizing
> will please no one: class haters still gonna hate, while class lovers used
> to batteries-and-leather-included will find the bare sheet metal poky and
> painful.
>
> Love it or hate it, I'm ok either way :-P. But I do crave intelligent
> responses.
>

When it comes to classes ... one man's minimalist is another man's baroque
;)

Since you've updated the Rich Corinthian Leather edition to return to
(extended) object literals as the RHS of the class definition -- we're now
effectively in agreement about the class proposal: the two flavors are the
same, if object literal extensions are added to JS.next, and the RHS is
restricted to be a literal instead of an expression, as super() calls might
necessitate. Groovy.

I think that if class bodies must be statically analyzable lists of
properties, then you can't go wrong with object literals. They're already
widely renowned syntax for such purposes -- so much so that languages like
Ruby are re-syntaxing their hashes to follow suit.

That said, we should take care to have the two things be fully consistent:
A class body should *be* an object literal, with no subtle differences in
the grammar leading to stumbling blocks down the line. If class bodies can
have:

class Runner {
  run() {
...
  }
  private quit() {
...
  }
  const speed: 10
}

... then an object literal should equally be able to have an identical body:

var runner = {
  run() {
...
  }
  private quit() {
...
  }
  const speed: 10
};

... as const properties and private methods on single objects are just as
useful and important as const properties and private methods on objects
that happen to be instances of a class.

Hopefully, unifying the two will have the side effect of making it easier
for TC39 to come to consensus on classes, if folks can agree to the general
"class name objectLiteral" scheme. You can do it (and desugar it) today
with ES3 object literals, and if ES6 object literals happen to have public,
const, and shorthand method syntax, ES6 classes will naturally have those
features as well.

(Full Disclosure: I'm still very opposed to const, private, and their
object-lockdown friends, but that should have no bearing on Brendan's
proposal.)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minimalist Classes

2011-11-02 Thread Erik Corry

2011/11/2 Axel Rauschmayer :
>> super Foo.bar(x) should desugar to Foo.prototype.bar.call(this, x)
>
> http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super
>
> What is that you don’t like about Allen’s proposal? You are still hard-coding 
> the name of the super-constructor (which is what `super` nicely avoids).

"lookup starts with the object that is the prototype of the object
defined by the object literal that contains the reference to super."

So it only works inside an object literal, whereas mine is easier to
understand and works anywhere.  If you are using it without any of the
other stuff you can even trivially get your minifier to desugar for
older browsers.

I don't think hard coding the name of the super-constructor is a
problem.  On the contrary it is documentation of something that is
implicit in the normal use of super, which I regard as a problem.
It's not like the programmer doesn't know what the superclass is at
the moment when he writes it, so it's nice if he documents that
knowledge right there where the reader needs it.

I don't think you can refactor a prototype hierarchy without taking a
good long look at every use of the super keyword, whether or not it
requires explicit statement of the expected prototype.

>> If people make constructors of the type that are designed to be called
>> with new then it works for constructors too.
>>
>> // Works with super, used with var foo = new Foo.prototype.constructor()
>> constructor: function() {
>>  this.x = 0;
>>  this.y = 0;
>> }
>>
>> // Doesn't work with super, used with var foo = Foo.prototype.constructor()
>> constructor: function() {
>>  return {x: 0, y: 0}
>> }
>>
>> // Also doesn't work with super
>> constructor: function() {
>>  var self = factory();
>>  self.x = 0;
>>  self.y = 0;
>>  return self;
>> }
>
>
> I don’t understand. Are you really pointing out something that will cause 
> difficulty with your proposal or a general problem?

It's a limitation of my proposal, but not a serious one IMHO.  The
proposal is simple enough that it hardly qualifies as a surprise.

I don't know how other super proposals deal with calling constructors
that are not designed to work with the object that the new keyword
brings into being and passes as 'this'.

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

Re: Minimalist Classes

> super Foo.bar(x) should desugar to Foo.prototype.bar.call(this, x)

http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super

What is that you don’t like about Allen’s proposal? You are still hard-coding 
the name of the super-constructor (which is what `super` nicely avoids).

> If people make constructors of the type that are designed to be called
> with new then it works for constructors too.
> 
> // Works with super, used with var foo = new Foo.prototype.constructor()
> constructor: function() {
>  this.x = 0;
>  this.y = 0;
> }
> 
> // Doesn't work with super, used with var foo = Foo.prototype.constructor()
> constructor: function() {
>  return {x: 0, y: 0}
> }
> 
> // Also doesn't work with super
> constructor: function() {
>  var self = factory();
>  self.x = 0;
>  self.y = 0;
>  return self;
> }


I don’t understand. Are you really pointing out something that will cause 
difficulty with your proposal or a general problem?

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



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

Re: Minimalist Classes

The new more object-literal-style syntax is great. "private" sticks out a bit, 
but it’s not a deal-breaker. It could even be good for the code if it had to 
appear at the beginning (kind of like a section). Such a section would be great 
for object literals, too. Maybe we can find a syntax that works for both (as in 
future-friendly)!

>> And if we're trying to emulate classical OO, then how about just dropping 
>> the ability to define data properties on the prototype.
> 
> I am all for that! I kept it for parity with jashkenas's three.js example, 
> but the r, g, and b props there are vacuous default proto-props (ditto the 
> Monster example's proto var and const).

Great great idea! Very newbie-friendly. The error message could tell you: put 
those properties into the constructor.

>> Your private instance variables are quite interesting.
> 
> Yes, that is a missing ingredient in most proposals we've seen.

+1

>> One nit: you're using @ as both a sigil in @name and as an operator in 
>> other@name.  I would expect other.@name instead.
> 
> No, it's a prefix operator if in operand context (like / starting a regexp), 
> a binary operator in operator context (/ as division).
> 
> Trying to avoid .@ all over, and this.@ noise.

I think people have certain expectations for how property access looks (and 
JavaScript is a better language for it; I don’t like how Java instance 
properties become part of the local scope). My guess: The expectation would be 
either one of two notations.

this@name, other@name
this.@name, other.@name

>> What about just a dot with nothing on the left hand side?  Can '.foo' be 
>> shorthand for 'this.foo'?  Or are there grammatical issues with that?
> 
> That could work with [no LineTerminator here] restriction on the left, which 
> is awkward -- it mandates manual semicolon insertion of you assign .foo = bar 
> after a baz() statement. We thought about this in consider how to reform 
> with, but that's a dead end.
> 
> Another sigil is hard to justify for the this.publicProp case, and for dyadic 
> methods, etc., other.publicProp is how you spell it -- the dot, I mean. So 
> one would want this.publicProp anyway. Between this consideration and the 
> preference for private, I'm fine stopping with @ for private.


I think the namespacing via this is a feature, it give the code a nice uniform 
look:
if (this.foo === other.foo)

Axel

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



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

Re: Minimalist Classes

2011-11-02 Thread Erik Corry

Here's a simple super suggestion:

super Foo.bar(x) should desugar to Foo.prototype.bar.call(this, x)

If people make constructors of the type that are designed to be called
with new then it works for constructors too.

// Works with super, used with var foo = new Foo.prototype.constructor()
constructor: function() {
  this.x = 0;
  this.y = 0;
}

// Doesn't work with super, used with var foo = Foo.prototype.constructor()
constructor: function() {
  return {x: 0, y: 0}
}

// Also doesn't work with super
constructor: function() {
  var self = factory();
  self.x = 0;
  self.y = 0;
  return self;
}


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

Re: Minimalist Classes