Re: prototype focus

[Axel Rauschmayer]

 I don't think
 JavaScript has ever been far from its prototype roots especially if
 the programmer shifts to thinking about a prototype object instead of
 thinking about a functions prototype property.

That is basically the point that the proposal tries to make. Have you taken a 
look at the library code? It is very short and not a radical overhaul.
http://dl.2ality.com/dl/2011/06/Proto.js

Note how below, there is always an extra prototype in there with constructor 
functions.

Super-calls (there will be syntactic sugar for this):
- Constructor functions: Superclass.prototype.foo.call(this)
- PAC: Superclass.foo.call(this)

Subclassing:
- Constructor functions: Subclass.prototype = 
Object.create(Superclass.prototype)
- PAC: let Subclass = Object.create(Superclass)

Instanceof (internally):
- Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
- PAC: o instanceof C === C.isPrototypeOf(o)


 Problems that both prototypes-as-classes (PAC) and class literals (CL) are
 trying to solve are:
 - Subclassing is hard and not directly supported by the language: connecting
 prototypes, chaining constructors, super-references.
 
 Object.getPrototypeOf(this).foo.call(this) is pretty long.

See above.

 It seems to me that perhaps the PaC drifted too far or perhaps started
 too far from what JavaScript has already. If the idea is to shift the
 focus more towards prototypes, then starting from something like what
 I've written and adding super syntax would be more consistent with
 what JavaScript already has.


“too far from what JavaScript has already” is very vague. How so? With class 
literals, your code will look like PAC, anyway. Have you taken a look at Sect. 
3? Do you agree that the mentioned conceptual simplifications hold?
http://www.2ality.com/2011/06/prototypes-as-classes.html#3

I find Brendan’s anti-PAC argument much more convincing: that all people might 
find it more natural to think in terms of constructors than in terms of 
prototypes. If that is the case then PAC would be a bad idea. The other 
convincing anti-PAC argument is that it is a bad idea to have two class 
mechanisms.

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



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

Re: prototype focus

[Tim Smart]

I quite the current prototype model we have in ecma5. My only gripes would
be that `prototype` to too wordy, and `__proto__` needs to become standard.
If you replaced `prototype` with `::` or something everything would be
swell.

function Parent (name) {
  this.name = name || this.constructor.DEFAULT_NAME
}
Parent.DEFAULT_NAME = 'bob'

function Child (name, age) {
  Parent.call(this, name)
  this.age = age
}
Child.__proto__ = Parent
Child::__proto__ = Parent.prototype
Child::describe = function () {
  return 'I am called ' + this.name + ' and I am ' + this.age + ' years old'
}

Tim.

On 1 July 2011 21:10, Axel Rauschmayer a...@rauschma.de wrote:

  I don't think
  JavaScript has ever been far from its prototype roots especially if
  the programmer shifts to thinking about a prototype object instead of
  thinking about a functions prototype property.

 That is basically the point that the proposal tries to make. Have you taken
 a look at the library code? It is very short and not a radical overhaul.
 http://dl.2ality.com/dl/2011/06/Proto.js

 Note how below, there is always an extra prototype in there with
 constructor functions.

 Super-calls (there will be syntactic sugar for this):
 - Constructor functions: Superclass.prototype.foo.call(this)
 - PAC: Superclass.foo.call(this)

 Subclassing:
 - Constructor functions: Subclass.prototype =
 Object.create(Superclass.prototype)
 - PAC: let Subclass = Object.create(Superclass)

 Instanceof (internally):
 - Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
 - PAC: o instanceof C === C.isPrototypeOf(o)


  Problems that both prototypes-as-classes (PAC) and class literals (CL)
 are
  trying to solve are:
  - Subclassing is hard and not directly supported by the language:
 connecting
  prototypes, chaining constructors, super-references.
 
  Object.getPrototypeOf(this).foo.call(this) is pretty long.

 See above.

  It seems to me that perhaps the PaC drifted too far or perhaps started
  too far from what JavaScript has already. If the idea is to shift the
  focus more towards prototypes, then starting from something like what
  I've written and adding super syntax would be more consistent with
  what JavaScript already has.


 “too far from what JavaScript has already” is very vague. How so? With
 class literals, your code will look like PAC, anyway. Have you taken a look
 at Sect. 3? Do you agree that the mentioned conceptual simplifications hold?
 http://www.2ality.com/2011/06/prototypes-as-classes.html#3

 I find Brendan’s anti-PAC argument much more convincing: that all people
 might find it more natural to think in terms of constructors than in terms
 of prototypes. If that is the case then PAC would be a bad idea. The other
 convincing anti-PAC argument is that it is a bad idea to have two class
 mechanisms.

 --
 Dr. Axel Rauschmayer

 a...@rauschma.de
 twitter.com/rauschma

 home: rauschma.de
 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: prototype focus

[Axel Rauschmayer]

What I’m asking for is the following (and I might not convince anyone, but just 
consider the possibility):

If you are using a constructor function C only once, during construction and 
otherwise always use C.prototype, wouldn’t it be better to focus on
C' = C.prototype
Then you would use C'.constructor (or C'.initialize or C'.init) once and C' the 
remaining times.

To paraphrase: Hasn’t the prototype been always the core construct? And if yes, 
shouldn’t we make that explicit?

I would like people to agree with me that there is *some* merit in that. After 
that, there are still arguments against PAC, though...

As for __proto__: Have you taken a look at the | operator? It does everything 
you want, it’s really cool.

On Jul 1, 2011, at 11:21 , Tim Smart wrote:

 I quite the current prototype model we have in ecma5. My only gripes would be 
 that `prototype` to too wordy, and `__proto__` needs to become standard. If 
 you replaced `prototype` with `::` or something everything would be swell.
 
 function Parent (name) {
   this.name = name || this.constructor.DEFAULT_NAME
 }
 Parent.DEFAULT_NAME = 'bob'
 
 function Child (name, age) {
   Parent.call(this, name)
   this.age = age
 }
 Child.__proto__ = Parent
 Child::__proto__ = Parent.prototype
 Child::describe = function () {
   return 'I am called ' + this.name + ' and I am ' + this.age + ' years old'
 }

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



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

Re: prototype focus

[Axel Rauschmayer]

BTW: I like the :: proposal (Brendan will remind you that it’s already taken, 
though...).
What you are in fact creating is the illusion that the class name refers to the 
prototype (with PAC, the :: would turn into a dot).

On Jul 1, 2011, at 11:21 , Tim Smart wrote:

 I quite the current prototype model we have in ecma5. My only gripes would be 
 that `prototype` to too wordy, and `__proto__` needs to become standard. If 
 you replaced `prototype` with `::` or something everything would be swell.
 
 function Parent (name) {
   this.name = name || this.constructor.DEFAULT_NAME
 }
 Parent.DEFAULT_NAME = 'bob'
 
 function Child (name, age) {
   Parent.call(this, name)
   this.age = age
 }
 Child.__proto__ = Parent
 Child::__proto__ = Parent.prototype
 Child::describe = function () {
   return 'I am called ' + this.name + ' and I am ' + this.age + ' years old'
 }
 
 Tim.
 
 On 1 July 2011 21:10, Axel Rauschmayer a...@rauschma.de wrote:
  I don't think
  JavaScript has ever been far from its prototype roots especially if
  the programmer shifts to thinking about a prototype object instead of
  thinking about a functions prototype property.
 
 That is basically the point that the proposal tries to make. Have you taken a 
 look at the library code? It is very short and not a radical overhaul.
 http://dl.2ality.com/dl/2011/06/Proto.js
 
 Note how below, there is always an extra prototype in there with 
 constructor functions.
 
 Super-calls (there will be syntactic sugar for this):
 - Constructor functions: Superclass.prototype.foo.call(this)
 - PAC: Superclass.foo.call(this)
 
 Subclassing:
 - Constructor functions: Subclass.prototype = 
 Object.create(Superclass.prototype)
 - PAC: let Subclass = Object.create(Superclass)
 
 Instanceof (internally):
 - Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
 - PAC: o instanceof C === C.isPrototypeOf(o)
 
 
  Problems that both prototypes-as-classes (PAC) and class literals (CL) are
  trying to solve are:
  - Subclassing is hard and not directly supported by the language: 
  connecting
  prototypes, chaining constructors, super-references.
 
  Object.getPrototypeOf(this).foo.call(this) is pretty long.
 
 See above.
 
  It seems to me that perhaps the PaC drifted too far or perhaps started
  too far from what JavaScript has already. If the idea is to shift the
  focus more towards prototypes, then starting from something like what
  I've written and adding super syntax would be more consistent with
  what JavaScript already has.
 
 
 “too far from what JavaScript has already” is very vague. How so? With class 
 literals, your code will look like PAC, anyway. Have you taken a look at 
 Sect. 3? Do you agree that the mentioned conceptual simplifications hold?
 http://www.2ality.com/2011/06/prototypes-as-classes.html#3
 
 I find Brendan’s anti-PAC argument much more convincing: that all people 
 might find it more natural to think in terms of constructors than in terms of 
 prototypes. If that is the case then PAC would be a bad idea. The other 
 convincing anti-PAC argument is that it is a bad idea to have two class 
 mechanisms.
 
 --
 Dr. Axel Rauschmayer
 
 a...@rauschma.de
 twitter.com/rauschma
 
 home: rauschma.de
 blog: 2ality.com
 
 
 
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss
 

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



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

Minor type confusion in proxies proposal?

[Andreas Rossberg]

I believe there is some type confusion in the proxy proposal spec
wrt property descriptors and their reification into attributes
objects.

1. In a note on the def of [[DefineOwnProperty]] for proxies, the proposal says:

The Desc argument to this trap is a property descriptor object
validated by ToPropertyDescriptor, except that it also retains any
non-standard attributes present in the original property descriptor
passed to Object.defineProperty. See the semantics of the modified
Object.defineProperty built-in, below.

That seems fishy, since according to ES5 8.10:

Values of the Property Descriptor type are records composed of named
fields where each field‘s name is an attribute name and its value is a
corresponding attribute value as specified in 8.6.1.

In particular, I take this to mean that property descriptors are not
objects (but abstract records), and that there cannot be any fields
whose name is not an attribute name. (In fact, in V8 we currently
encode property descriptors using objects, but the encoding is
different from the reified attributes object representation, and not
quite compatible with the idea of adding arbitrary other fields.)

2. In the modified definition of Object.defineProperty, the proposal
says in step 4.c:

Call the [[DefineOwnProperty]] internal method of O with arguments
name, descObj, and true.

This is passing descObj, which in fact is _not_ a descriptor, but its
reification as an attributes object.

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

Re: Minor type confusion in proxies proposal?

[Andreas Rossberg]

On 1 July 2011 12:12, Andreas Rossberg rossb...@google.com wrote:
 I believe there is some type confusion in the proxy proposal spec
 wrt property descriptors and their reification into attributes
 objects.

 1. In a note on the def of [[DefineOwnProperty]] for proxies, the proposal 
 says:

 The Desc argument to this trap is a property descriptor object
 validated by ToPropertyDescriptor, except that it also retains any
 non-standard attributes present in the original property descriptor
 passed to Object.defineProperty. See the semantics of the modified
 Object.defineProperty built-in, below.

 That seems fishy, since according to ES5 8.10:

 Values of the Property Descriptor type are records composed of named
 fields where each field‘s name is an attribute name and its value is a
 corresponding attribute value as specified in 8.6.1.

 In particular, I take this to mean that property descriptors are not
 objects (but abstract records), and that there cannot be any fields
 whose name is not an attribute name. (In fact, in V8 we currently
 encode property descriptors using objects, but the encoding is
 different from the reified attributes object representation, and not
 quite compatible with the idea of adding arbitrary other fields.)

I forgot to say: step 5 of the definition invokes the defineProperty
trap of the handler passing Desc as the second argument. But the
handler expects a reified attributes object.

 2. In the modified definition of Object.defineProperty, the proposal
 says in step 4.c:

 Call the [[DefineOwnProperty]] internal method of O with arguments
 name, descObj, and true.

 This is passing descObj, which in fact is _not_ a descriptor, but its
 reification as an attributes object.

 /Andreas

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

Re: prototype focus

[Irakli Gozalishvili]

I absolutely agree with Alex and have few other points:

1. Does this code looks familiar ?

 function Foo(options) {  }
 Foo.prototype.do_foo_job = function() { ... }
 
 function Bar(options) {
 if (!(this instanceof Bar))
  return this new Bar(options);
 Foo.apply(this, arguments);
 }
 Bar.prototype.do_bar_job = function() {
  
 }
 

With focus on prototype this is so much simpler: 


var Foo = Object.extend({
 initialize: function(options) { ... },
do_foo_job: function() { ... }
})


On Friday, 2011-07-01 at 11:10 , Axel Rauschmayer wrote:

  I don't think
  JavaScript has ever been far from its prototype roots especially if
  the programmer shifts to thinking about a prototype object instead of
  thinking about a functions prototype property.
 
 That is basically the point that the proposal tries to make. Have you taken a 
 look at the library code? It is very short and not a radical overhaul.
 http://dl.2ality.com/dl/2011/06/Proto.js
 
 Note how below, there is always an extra prototype in there with 
 constructor functions.
 
 Super-calls (there will be syntactic sugar for this):
 - Constructor functions: Superclass.prototype.foo.call(this)
 - PAC: Superclass.foo.call(this)
 
 Subclassing:
 - Constructor functions: Subclass.prototype = 
 Object.create(Superclass.prototype)
 - PAC: let Subclass = Object.create(Superclass)
 
 Instanceof (internally):
 - Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
 - PAC: o instanceof C === C.isPrototypeOf(o)
 
 
   Problems that both prototypes-as-classes (PAC) and class literals (CL) are
   trying to solve are:
   - Subclassing is hard and not directly supported by the language: 
   connecting
   prototypes, chaining constructors, super-references.
  
  Object.getPrototypeOf(this).foo.call(this) is pretty long.
 
 See above.
 
  It seems to me that perhaps the PaC drifted too far or perhaps started
  too far from what JavaScript has already. If the idea is to shift the
  focus more towards prototypes, then starting from something like what
  I've written and adding super syntax would be more consistent with
  what JavaScript already has.
 
 
 “too far from what JavaScript has already” is very vague. How so? With class 
 literals, your code will look like PAC, anyway. Have you taken a look at 
 Sect. 3? Do you agree that the mentioned conceptual simplifications hold?
 http://www.2ality.com/2011/06/prototypes-as-classes.html#3
 
 I find Brendan’s anti-PAC argument much more convincing: that all people 
 might find it more natural to think in terms of constructors than in terms of 
 prototypes. If that is the case then PAC would be a bad idea. The other 
 convincing anti-PAC argument is that it is a bad idea to have two class 
 mechanisms.
 
 -- 
 Dr. Axel Rauschmayer
 
 a...@rauschma.de (mailto:a...@rauschma.de)
 twitter.com/rauschma (http://twitter.com/rauschma)
 
 home: rauschma.de (http://rauschma.de)
 blog: 2ality.com (http://2ality.com)
 
 
 
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto: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: prototype focus

[Irakli Gozalishvili]

Sorry I did not intended to send email yet:

So here is my points:

1. Does this looks familiar (version with syntax highlighting 
https://gist.github.com/1058534) 

function Foo(options) {  }
Foo.prototype.do_foo_job = function() { ... }

function Bar(options) {
if (!(this instanceof Bar))
return this new Bar(options);
Foo.apply(this, arguments);
}
Bar.prototype = Object.create(Foo.prototype);
Bar.prototype.do_bar_job = function() {  };

With focus on prototypes it's as simple as this:
var Foo = Object.extend({
initialize: function(options) { ... },
do_foo_job: function() { ... }
})

var Bar = Foo.extend({
do_bar_job: function() { ... }
})

Why should not be I able to reuse initialization function, or why do I have to 
create constructor function for all classes / subclasses ?

2. With a constructor focused classes you end up maintaing two sets of 
properties: 1. prototype properties and 2. (java static like) constructor 
properties, which adds complexity requires dedicated syntax in declarative 
classes syntax.

3. It could be my personal, internal conflict, but I seriously can't see any 
reason for `constructor` to be a special among all other methods, by having 
privilege to hold a reference to a prototype object (I don't even mention that 
this reference is circular by default). Overall `prototype` property feels like 
hack to emulate Java like classes.

4. With focus on prototypes there is potential to further reduce language 
syntax (hopefully new, instanceof will die off) instead of cluttering even 
further. 

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Friday, 2011-07-01 at 15:19 , Irakli Gozalishvili wrote:

 I absolutely agree with Alex and have few other points:
 
 1. Does this code looks familiar ?
 
  function Foo(options) {  }
  Foo.prototype.do_foo_job = function() { ... }
  
  function Bar(options) {
  if (!(this instanceof Bar))
   return this new Bar(options);
  Foo.apply(this, arguments);
  }
  Bar.prototype.do_bar_job = function() {
   
  }
  
 
 With focus on prototype this is so much simpler: 
 
 
 var Foo = Object.extend({
  initialize: function(options) { ... },
 do_foo_job: function() { ... }
 })
 
 
 On Friday, 2011-07-01 at 11:10 , Axel Rauschmayer wrote:
 
   I don't think
   JavaScript has ever been far from its prototype roots especially if
   the programmer shifts to thinking about a prototype object instead of
   thinking about a functions prototype property.
  
  That is basically the point that the proposal tries to make. Have you taken 
  a look at the library code? It is very short and not a radical overhaul.
  http://dl.2ality.com/dl/2011/06/Proto.js
  
  Note how below, there is always an extra prototype in there with 
  constructor functions.
  
  Super-calls (there will be syntactic sugar for this):
  - Constructor functions: Superclass.prototype.foo.call(this)
  - PAC: Superclass.foo.call(this)
  
  Subclassing:
  - Constructor functions: Subclass.prototype = 
  Object.create(Superclass.prototype)
  - PAC: let Subclass = Object.create(Superclass)
  
  Instanceof (internally):
  - Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
  - PAC: o instanceof C === C.isPrototypeOf(o)
  
  
Problems that both prototypes-as-classes (PAC) and class literals (CL) 
are
trying to solve are:
- Subclassing is hard and not directly supported by the language: 
connecting
prototypes, chaining constructors, super-references.
   
   Object.getPrototypeOf(this).foo.call(this) is pretty long.
  
  See above.
  
   It seems to me that perhaps the PaC drifted too far or perhaps started
   too far from what JavaScript has already. If the idea is to shift the
   focus more towards prototypes, then starting from something like what
   I've written and adding super syntax would be more consistent with
   what JavaScript already has.
  
  
  “too far from what JavaScript has already” is very vague. How so? With 
  class literals, your code will look like PAC, anyway. Have you taken a look 
  at Sect. 3? Do you agree that the mentioned conceptual simplifications hold?
  http://www.2ality.com/2011/06/prototypes-as-classes.html#3
  
  I find Brendan’s anti-PAC argument much more convincing: that all people 
  might find it more natural to think in terms of constructors than in terms 
  of prototypes. If that is the case then PAC would be a bad idea. The other 
  convincing anti-PAC argument is that it is a bad idea to have two class 
  mechanisms.
  
  -- 
  Dr. Axel Rauschmayer
  
  a...@rauschma.de (mailto:a...@rauschma.de)
  twitter.com/rauschma (http://twitter.com/rauschma)
  
  home: rauschma.de (http://rauschma.de)
  blog: 2ality.com (http://2ality.com)
  
  
  
  ___
  es-discuss mailing list
  es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
  

Re: Mailing list reminder: password is sent in the clear

[André Bargull]

Log-in at [1] and remove the option to send a monthly password remainder?


*Get password reminder email for this list?*

Once a month, you will get an email containing a password reminder for 
every list at this host to which you are subscribed. You can turn this 
off on a per-list basis by selecting /No/ for this option. If you turn 
off password reminders for all the lists you are subscribed to, no 
reminder email will be sent to you.





[1] https://mail.mozilla.org/options/es-discuss


Can this be fixed? I've already sent feedback, but didn't get a response.

Preferably, passwords would also be encrypted for storage.

--
Dr. Axel Rauschmayer
axel at rauschma.de  https://mail.mozilla.org/listinfo/es-discuss
twitter.com/rauschma

Home: rauschma.de
Blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mailing list reminder: password is sent in the clear

[Axel Rauschmayer]

That’s a good start, thanks. Still find it a bit scary that there’s no 
encryption.

On Jul 1, 2011, at 16:07 , André Bargull wrote:

 Log-in at [1] and remove the option to send a monthly password remainder?
 
 Get password reminder email for this list?
 Once a month, you will get an email containing a password reminder for every 
 list at this host to which you are subscribed. You can turn this off on a 
 per-list basis by selecting No for this option. If you turn off password 
 reminders for all the lists you are subscribed to, no reminder email will be 
 sent to you.
 
 
 
 [1] https://mail.mozilla.org/options/es-discuss
 
 Can this be fixed? I’ve already sent feedback, but didn’t get a response.
 
 Preferably, passwords would also be encrypted for storage.
 
 -- 
 Dr. Axel Rauschmayer
 axel at rauschma.de
 twitter.com/rauschma
 
 Home: rauschma.de
 Blog: 2ality.com

-- 
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma

Home: rauschma.de
Blog: 2ality.com

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

Re: prototype focus

[Sean Eagan]

On Fri, Jul 1, 2011 at 8:45 AM, Irakli Gozalishvili rfo...@gmail.com wrote:

 why do I have to create constructor function for all classes / subclasses ?

This could be handled by class literals by allowing for default
constructors.  If one doesn't provide a constructor, the following one
could be provided:

constructor(... args) {
  super(... args);
}

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

Re: prototype focus

[Mark S. Miller]

On Fri, Jul 1, 2011 at 7:18 AM, Sean Eagan seaneag...@gmail.com wrote:

 On Fri, Jul 1, 2011 at 8:45 AM, Irakli Gozalishvili rfo...@gmail.com
 wrote:

  why do I have to create constructor function for all classes / subclasses
 ?


This magic trades confusion for convenience. In any earlier version of the
proposal, I actually had a traditional default constructor, the equivalent
of

constructor() { super(); }

but others argued against it. Sorry don't remember who. There were plenty of
off list discussions to gather consensus. On this one, I didn't feel
strongly either way, but I eventually agreed with the objectors. When in
doubt, throw it out -- even more important in language design than in
writing.




 This could be handled by class literals by allowing for default
 constructors.  If one doesn't provide a constructor, the following one
 could be provided:

 constructor(... args) {
  super(... args);
 }


This one I object to because those used to other languages that provide such
default constructors will only call the super constructor with no arguments.
Though now that you mention it, I can see why JSers without exposure to
other languages may naturally expect your's.

With two expectations for the semantics of something that does not appear in
the code, and without a static or dynamic rejection to prevent progress of
the code written to the wrong assumption, I now finally feel strongly about
this. The critics were right -- we should not provide any default
constructor. Thanks for pointing out the problem case.

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

Re: prototype focus

[Irakli Gozalishvili]

On Friday, 2011-07-01 at 16:38 , Mark S. Miller wrote:

 On Fri, Jul 1, 2011 at 7:18 AM, Sean Eagan seaneag...@gmail.com 
 (mailto:seaneag...@gmail.com) wrote:
  On Fri, Jul 1, 2011 at 8:45 AM, Irakli Gozalishvili rfo...@gmail.com 
  (mailto:rfo...@gmail.com) wrote:
  
   why do I have to create constructor function for all classes / subclasses 
   ?
 
 This magic trades confusion for convenience. In any earlier version of the 
 proposal, I actually had a traditional default constructor, the equivalent of 
 
  constructor() { super(); }
 
 but others argued against it. Sorry don't remember who. There were plenty of 
 off list discussions to gather consensus. On this one, I didn't feel strongly 
 either way, but I eventually agreed with the objectors. When in doubt, throw 
 it out -- even more important in language design than in writing. 
 
  
  This could be handled by class literals by allowing for default
   constructors. If one doesn't provide a constructor, the following one
   could be provided:
  
   constructor(... args) {
  super(... args);
   }
 
 This one I object to because those used to other languages that provide such 
 default constructors will only call the super constructor with no arguments. 
 Though now that you mention it, I can see why JSers without exposure to other 
 languages may naturally expect your's. 
 
 With two expectations for the semantics of something that does not appear in 
 the code, and without a static or dynamic rejection to prevent progress of 
 the code written to the wrong assumption, I now finally feel strongly about 
 this. The critics were right -- we should not provide any default 
 constructor. Thanks for pointing out the problem case. 
 
 
 
 


Do you think prototype focused version:

Prototype.new(foo);

also suggest wrong assumptions ? If not (which I think is the case) is another 
+ in favor of prototype focus. 

 -- 
  Cheers,
  --MarkM

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

Re: prototype focus

[Sean Eagan]

On Fri, Jul 1, 2011 at 9:38 AM, Mark S. Miller erig...@google.com wrote:
 This could be handled by class literals by allowing for default
 constructors.  If one doesn't provide a constructor, the following one
 could be provided:

 constructor(... args) {
  super(... args);
 }

 This one I object to because those used to other languages that provide such
 default constructors will only call the super constructor with no arguments.

I'm sure there is good reason to only default the zero-argument
constructor in languages with multiple constructors per class,
however, ES makes it obvious that there is only one constructor per
class, which class literal syntax reinforces further, so I don't think
users would have a hard time understanding that a default constructor
merely forwards its arguments to the superclass constructor.  I don't
think users would ever expect arguments passed to a default
constructor not to be forwarded to the superclass constructor.

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

Re: Unifying Block and ObjectLiteral (was: Re: block-lambda revival)

[Brendan Eich]

On Jun 30, 2011, at 9:46 PM, Brendan Eich wrote:

 Oops -- thanks. I will fix in a strawman that captures all of this.

Done:

http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal

/be

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

Re: prototype focus

[Quildreen Motta]

Ah, oh yes. I think I fail at mailing lists :3

2011/7/1 Peter Michaux petermich...@gmail.com

 Did you mean to send this to es-discuss?

 Peter

 On 2011-07-01, at 8:51 AM, Quildreen Motta quildr...@gmail.com wrote:

 Actually, in my opinion, constructor functions add needless complexity on
 JavaScript's inheritance mechanism, and yes, they do shift the focus from
 prototypical inheritance -- using constructors feels much more like creating
 a layer of metadata to extend some behaviours, than extending objects.

 With constructors, you basically have the following:

 1.) Want to extend Foo (an object).
 2.) Create a function Bar, write initialisation code (even if you don't
 need one).
 3.) Set Bar.prototype to an object that clones Foo.
 4.) use new Bar to construct a new object that extends Foo (and does
 initialisation) -- which might return some other object.
 5.) Extend the new Bar object as you see fit.
 6.) Use the object.

 With prototypes you have the following:

 1.) Want to extend Foo (an object).
 2.) Create a new object that points to Foo.
 3.) Extend this new object -- which you can do either manually or by
 calling an initialisation function on the object.
 4.) Use the object.

 The thing is: by removing the additional constructor function you simplify
 it. I had a really hard time trying to wrap my head around constructors and
 how they play with prototypes, lots of people out there face the very same
 problem when trying to use the OOP mechanisms that JavaScript provides,
 since it *looks* like the classical pattern they're used to, but in reality
 it works mostly different.

 You still see code around that does:

 function Foo() { }
 Foo.prototype = { describe: function(){ return 'Foo' } }

 function Bar() { }
 Bar.prototype = new Foo

 Some people are simply not aware that Foo is not a class, but something
 that is used to group initialisation and inheritance, so it would be only
 natural(?) for them to think that way when trying to extend something. Some
 people also think that `prototype' is a magical property used for
 inheritance of anything.

 With PaC you solve those problems by making the mechanisms that JS uses for
 inheritance explicit. That is, if you want to extend Foo, you just extend
 Foo.

 2011/6/30 Peter Michaux  petermich...@gmail.competermich...@gmail.com

 On Thu, Jun 30, 2011 at 4:46 PM, Axel Rauschmayer  a...@rauschma.de
 a...@rauschma.de wrote:
  What problem have you solved by giving the prototype a name?

 The names I choose makes it clear to the reader that the prototype is
 one element (zero) in a set of elements (complex numbers).

 A name gives a reference to the object that is not related to any
 constructor function. Constructor functions are something separate
 from the prototype object (zero).


  The proposal is
  not (just) about giving prototypes names.

 Understood but it seemed that the proposal started from the idea that
 JavaScript needs to get back to its prototype roots. I don't think
 JavaScript has ever been far from its prototype roots especially if
 the programmer shifts to thinking about a prototype object instead of
 thinking about a functions prototype property.


  Problems that both prototypes-as-classes (PAC) and class literals (CL)
 are
  trying to solve are:
  - Subclassing is hard and not directly supported by the language:
 connecting
  prototypes, chaining constructors, super-references.

 Object.getPrototypeOf(this).foo.call(this) is pretty long.


  - Class properties are not inherited

 Class property inheritance is definitely a secondary issue compared
 with the instance objects themselves.

  (CoffeeScript copies them “manually”).

 Which I think is unsatisfactory and has a lot of gotchas when some
 properties are arrays and other properties have primitive values.

 --

 It seems to me that perhaps the PaC drifted too far or perhaps started
 too far from what JavaScript has already. If the idea is to shift the
 focus more towards prototypes, then starting from something like what
 I've written and adding super syntax would be more consistent with
 what JavaScript already has.

 Peter


  If none of these issues are involved then today’s constructor functions
 are
  OK.
  Pros of each approach:
  (1) Pro CL: no need to support two kinds of classes: prototypes *and*
  constructor functions.
  (2) Pro PAC: look the same as class literals, but don’t need an extra
  translation step.
  (1) weighs heavily and will probably make it impossible to sell PAC to
 TC39.
  There is the precedent of Python having two styles of classes [1] at the
  same time, but I don’t think they diverged as heavily as constructor
  functions and PAC.
  If you want to argue against PAC benefits, take a look at Sect. 3 here:
  http://www.2ality.com/2011/06/prototypes-as-classes.html#3
 http://www.2ality.com/2011/06/prototypes-as-classes.html#3
  [1] 
  http://stackoverflow.com/questions/54867/old-style-and-new-style-classes-in-python
 

Module grammar

[Kam Kasravi]

Should this 

ImportDeclaration(load) ::= import ImportBinding(load) (, 
ImportBinding(load))* ;
ImportPath(load) ::= ImportSpecifierSet from ModuleExpression(load)
ImportSpecifierSet ::= *
| IdentifierName
| { (ImportSpecifier (, ImportSpecifier)*)? ,? }
ImportSpecifier ::= IdentifierName (: Identifier)?
Be this?

ImportDeclaration(load) ::= import ImportBinding(load) (, 
ImportBinding(load))* ;
ImportBinding(load) ::= ImportSpecifierSet from ModuleExpression(load)
ImportSpecifierSet ::= *
| IdentifierName
| { (ImportSpecifier (, ImportSpecifier)*)? ,? }
ImportSpecifier ::= IdentifierName (: Identifier)?

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

Re: Module grammar

[David Herman]

Thanks-- missed one when manually doing s/ImportPath/ImportBinding/g. Fixed.

Thanks,
Dave

On Jul 1, 2011, at 9:55 AM, Kam Kasravi wrote:

 Should this 
 
 ImportDeclaration(load) ::= import ImportBinding(load) (, 
 ImportBinding(load))* ;
 ImportPath(load) ::= ImportSpecifierSet from ModuleExpression(load)
 ImportSpecifierSet ::= *
 | IdentifierName
 | { (ImportSpecifier (, ImportSpecifier)*)? ,? }
 ImportSpecifier ::= IdentifierName (: Identifier)?
 Be this?
 
 ImportDeclaration(load) ::= import ImportBinding(load) (, 
 ImportBinding(load))* ;
 ImportBinding(load) ::= ImportSpecifierSet from ModuleExpression(load)
 ImportSpecifierSet ::= *
 | IdentifierName
 | { (ImportSpecifier (, ImportSpecifier)*)? ,? }
 ImportSpecifier ::= IdentifierName (: Identifier)?
 
 ___
 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: prototype focus

[Brendan Eich]

On Jul 1, 2011, at 2:21 AM, Tim Smart wrote:

 I quite the current prototype model we have in ecma5. My only gripes would be 
 that `prototype` to too wordy,

Do you use it that often?


 and `__proto__` needs to become standard.

The | operator is the future there. __proto__ won't be standardized in any 
form, certainly not writable __proto__.


 If you replaced `prototype` with `::` or something everything would be swell.

Yeah, CoffeeScript does that. However, 
http://wiki.ecmascript.org/doku.php?id=strawman:guards wants :: for optional 
declaration guards. Could these be disjoint from :: in expressions, used as you 
want? Not sure grammatically, might be doable without ambiguity -- but it seems 
a bad idea to have :: mean two very different things.

Again I'm wondering why C.prototype. is written so much. You can decorate 
constructor prototypes that way, for sure, but you can also set C.prototype = 
{...} once and avoid saying .prototype. a lot.

/be


 
 function Parent (name) {
   this.name = name || this.constructor.DEFAULT_NAME
 }
 Parent.DEFAULT_NAME = 'bob'
 
 function Child (name, age) {
   Parent.call(this, name)
   this.age = age
 }
 Child.__proto__ = Parent
 Child::__proto__ = Parent.prototype
 Child::describe = function () {
   return 'I am called ' + this.name + ' and I am ' + this.age + ' years old'
 }
 
 Tim.
 
 On 1 July 2011 21:10, Axel Rauschmayer a...@rauschma.de wrote:
  I don't think
  JavaScript has ever been far from its prototype roots especially if
  the programmer shifts to thinking about a prototype object instead of
  thinking about a functions prototype property.
 
 That is basically the point that the proposal tries to make. Have you taken a 
 look at the library code? It is very short and not a radical overhaul.
 http://dl.2ality.com/dl/2011/06/Proto.js
 
 Note how below, there is always an extra prototype in there with 
 constructor functions.
 
 Super-calls (there will be syntactic sugar for this):
 - Constructor functions: Superclass.prototype.foo.call(this)
 - PAC: Superclass.foo.call(this)
 
 Subclassing:
 - Constructor functions: Subclass.prototype = 
 Object.create(Superclass.prototype)
 - PAC: let Subclass = Object.create(Superclass)
 
 Instanceof (internally):
 - Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
 - PAC: o instanceof C === C.isPrototypeOf(o)
 
 
  Problems that both prototypes-as-classes (PAC) and class literals (CL) are
  trying to solve are:
  - Subclassing is hard and not directly supported by the language: 
  connecting
  prototypes, chaining constructors, super-references.
 
  Object.getPrototypeOf(this).foo.call(this) is pretty long.
 
 See above.
 
  It seems to me that perhaps the PaC drifted too far or perhaps started
  too far from what JavaScript has already. If the idea is to shift the
  focus more towards prototypes, then starting from something like what
  I've written and adding super syntax would be more consistent with
  what JavaScript already has.
 
 
 “too far from what JavaScript has already” is very vague. How so? With class 
 literals, your code will look like PAC, anyway. Have you taken a look at 
 Sect. 3? Do you agree that the mentioned conceptual simplifications hold?
 http://www.2ality.com/2011/06/prototypes-as-classes.html#3
 
 I find Brendan’s anti-PAC argument much more convincing: that all people 
 might find it more natural to think in terms of constructors than in terms of 
 prototypes. If that is the case then PAC would be a bad idea. The other 
 convincing anti-PAC argument is that it is a bad idea to have two class 
 mechanisms.
 
 --
 Dr. Axel Rauschmayer
 
 a...@rauschma.de
 twitter.com/rauschma
 
 home: rauschma.de
 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

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

Re: prototype focus

[Brendan Eich]

On Jul 1, 2011, at 6:19 AM, Irakli Gozalishvili wrote:

 With focus on prototype this is so much simpler: 
 
 var Foo = Object.extend({
initialize: function(options) { ... },
do_foo_job: function() { ... }
 })

With | and 'super' in functions, I think you are set. It's hard to add more. 
The main debate is about whether this is enough, or do classes as sugar provide 
enough added value?

(But you didn't show Bar as well as Foo.)

/be


 
 On Friday, 2011-07-01 at 11:10 , Axel Rauschmayer wrote:
 
 I don't think
 JavaScript has ever been far from its prototype roots especially if
 the programmer shifts to thinking about a prototype object instead of
 thinking about a functions prototype property.
 
 That is basically the point that the proposal tries to make. Have you taken 
 a look at the library code? It is very short and not a radical overhaul.
 http://dl.2ality.com/dl/2011/06/Proto.js
 
 Note how below, there is always an extra prototype in there with 
 constructor functions.
 
 Super-calls (there will be syntactic sugar for this):
 - Constructor functions: Superclass.prototype.foo.call(this)
 - PAC: Superclass.foo.call(this)
 
 Subclassing:
 - Constructor functions: Subclass.prototype = 
 Object.create(Superclass.prototype)
 - PAC: let Subclass = Object.create(Superclass)
 
 Instanceof (internally):
 - Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
 - PAC: o instanceof C === C.isPrototypeOf(o)
 
 
 Problems that both prototypes-as-classes (PAC) and class literals (CL) are
 trying to solve are:
 - Subclassing is hard and not directly supported by the language: 
 connecting
 prototypes, chaining constructors, super-references.
 
 Object.getPrototypeOf(this).foo.call(this) is pretty long.
 
 See above.
 
 It seems to me that perhaps the PaC drifted too far or perhaps started
 too far from what JavaScript has already. If the idea is to shift the
 focus more towards prototypes, then starting from something like what
 I've written and adding super syntax would be more consistent with
 what JavaScript already has.
 
 
 “too far from what JavaScript has already” is very vague. How so? With class 
 literals, your code will look like PAC, anyway. Have you taken a look at 
 Sect. 3? Do you agree that the mentioned conceptual simplifications hold?
 http://www.2ality.com/2011/06/prototypes-as-classes.html#3
 
 I find Brendan’s anti-PAC argument much more convincing: that all people 
 might find it more natural to think in terms of constructors than in terms 
 of prototypes. If that is the case then PAC would be a bad idea. The other 
 convincing anti-PAC argument is that it is a bad idea to have two class 
 mechanisms.
 
 -- 
 Dr. Axel Rauschmayer
 
 a...@rauschma.de
 twitter.com/rauschma
 
 home: rauschma.de
 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

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

Re: Unifying Block and ObjectLiteral (was: Re: block-lambda revival)

[Mike Samuel]

What is

   ({
 get
 x()
 {
   return 42;
 }
   })

?

Could it match both as an object literal with a getter

   ({ get x() { return 42; } })

or as a block with 3 statements?

   ({ get; x(); { return 42; } })


2011/7/1 Brendan Eich bren...@mozilla.com:
 On Jun 30, 2011, at 9:46 PM, Brendan Eich wrote:

 Oops -- thanks. I will fix in a strawman that captures all of this.

 Done:

 http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal

 /be


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

Re: prototype focus

[Mike Shaver]

On Jul 1, 2011 1:14 PM, Brendan Eich bren...@mozilla.com wrote:

 On Jul 1, 2011, at 2:21 AM, Tim Smart wrote:

 I quite the current prototype model we have in ecma5. My only gripes
would be that `prototype` to too wordy,


 Do you use it that often?

15 years ago, writing an overwrought prototype hierarchy for a server-side
JS project, I experimented with

P = prototype;

function Thing () { }
Thing[P] = { ... }

Wasn't worth it, I decided, because it didn't match the (then scant, now
abundant) documentation of delegation. Same principle applies here for
adding synonyms, I think.

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

Re: Mailing list reminder: password is sent in the clear

[Mike Shaver]

What can someone do with that password, though? Just change your
subscription settings, afaik, so the security in place seems proportionate.

Could report it upstream to the mailman team, I suppose.

Mike
 On Jul 1, 2011 10:09 AM, Axel Rauschmayer a...@rauschma.de wrote:
 That’s a good start, thanks. Still find it a bit scary that there’s no
encryption.

 On Jul 1, 2011, at 16:07 , André Bargull wrote:

 Log-in at [1] and remove the option to send a monthly password remainder?

 Get password reminder email for this list?
 Once a month, you will get an email containing a password reminder for
every list at this host to which you are subscribed. You can turn this off
on a per-list basis by selecting No for this option. If you turn off
password reminders for all the lists you are subscribed to, no reminder
email will be sent to you.



 [1] https://mail.mozilla.org/options/es-discuss

 Can this be fixed? I’ve already sent feedback, but didn’t get a
response.

 Preferably, passwords would also be encrypted for storage.

 --
 Dr. Axel Rauschmayer
 axel at rauschma.de
 twitter.com/rauschma

 Home: rauschma.de
 Blog: 2ality.com

 --
 Dr. Axel Rauschmayer
 a...@rauschma.de
 twitter.com/rauschma

 Home: rauschma.de
 Blog: 2ality.com

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

Re: Mailing list reminder: password is sent in the clear

[Mike Samuel]

2011/7/1 Mike Shaver mike.sha...@gmail.com:
 What can someone do with that password, though? Just change your
 subscription settings, afaik, so the security in place seems proportionate.

 Could report it upstream to the mailman team, I suppose.

Use it to do a better job of impersonating.  Try it out on other sites.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mailing list reminder: password is sent in the clear

[Mike Shaver]

On Fri, Jul 1, 2011 at 2:30 PM, Mike Samuel mikesam...@gmail.com wrote:
 2011/7/1 Mike Shaver mike.sha...@gmail.com:
 What can someone do with that password, though? Just change your
 subscription settings, afaik, so the security in place seems proportionate.

 Could report it upstream to the mailman team, I suppose.

 Use it to do a better job of impersonating.  Try it out on other sites.

I don't understand how you could impersonate better, could you
explain?  You can send mail with any From: you want without bothering
to go through someone's mailman account, and you can't even send mail
from the mailman interface!

Since mailman passwords are randomly generated at subscription time
(and virtually never changed), password reuse is pretty unlikely.

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

Re: Minor type confusion in proxies proposal?

[Andreas Gal]

In our implementation we are using a generic object. It has some overhead, and 
a specific internal descriptor object representation might be a bit faster, 
but such magic objects that don't allow expando properties are usually pretty 
surprising to programers. Most of the HTML5 DOM allows arbitrary expando 
properties. I think we should stick to that theme.

Andreas

On Jul 1, 2011, at 5:54 AM, Andreas Rossberg wrote:

 On 1 July 2011 12:12, Andreas Rossberg rossb...@google.com wrote:
 I believe there is some type confusion in the proxy proposal spec
 wrt property descriptors and their reification into attributes
 objects.
 
 1. In a note on the def of [[DefineOwnProperty]] for proxies, the proposal 
 says:
 
 The Desc argument to this trap is a property descriptor object
 validated by ToPropertyDescriptor, except that it also retains any
 non-standard attributes present in the original property descriptor
 passed to Object.defineProperty. See the semantics of the modified
 Object.defineProperty built-in, below.
 
 That seems fishy, since according to ES5 8.10:
 
 Values of the Property Descriptor type are records composed of named
 fields where each field‘s name is an attribute name and its value is a
 corresponding attribute value as specified in 8.6.1.
 
 In particular, I take this to mean that property descriptors are not
 objects (but abstract records), and that there cannot be any fields
 whose name is not an attribute name. (In fact, in V8 we currently
 encode property descriptors using objects, but the encoding is
 different from the reified attributes object representation, and not
 quite compatible with the idea of adding arbitrary other fields.)
 
 I forgot to say: step 5 of the definition invokes the defineProperty
 trap of the handler passing Desc as the second argument. But the
 handler expects a reified attributes object.
 
 2. In the modified definition of Object.defineProperty, the proposal
 says in step 4.c:
 
 Call the [[DefineOwnProperty]] internal method of O with arguments
 name, descObj, and true.
 
 This is passing descObj, which in fact is _not_ a descriptor, but its
 reification as an attributes object.
 
 /Andreas
 
 ___
 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: Mailing list reminder: password is sent in the clear

[Mike Samuel]

2011/7/1 Mike Shaver mike.sha...@gmail.com:
 On Fri, Jul 1, 2011 at 2:30 PM, Mike Samuel mikesam...@gmail.com wrote:
 2011/7/1 Mike Shaver mike.sha...@gmail.com:
 What can someone do with that password, though? Just change your
 subscription settings, afaik, so the security in place seems proportionate.

 Could report it upstream to the mailman team, I suppose.

 Use it to do a better job of impersonating.  Try it out on other sites.

 I don't understand how you could impersonate better, could you
 explain?  You can send mail with any From: you want without bothering
 to go through someone's mailman account, and you can't even send mail
 from the mailman interface!

 Since mailman passwords are randomly generated at subscription time
 (and virtually never changed), password reuse is pretty unlikely.

Can't a mailman account holder associate a public key with a mailman instance?
Obviously, few email recipients check public keys, but to the degree
that mailman facilitates public key exchange and signed email, being
able to change a public key means being able to impersonate.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mailing list reminder: password is sent in the clear

[Mike Shaver]

On Fri, Jul 1, 2011 at 2:50 PM, Mike Samuel mikesam...@gmail.com wrote:
 2011/7/1 Mike Shaver mike.sha...@gmail.com:
 On Fri, Jul 1, 2011 at 2:30 PM, Mike Samuel mikesam...@gmail.com wrote:
 2011/7/1 Mike Shaver mike.sha...@gmail.com:
 What can someone do with that password, though? Just change your
 subscription settings, afaik, so the security in place seems proportionate.

 Could report it upstream to the mailman team, I suppose.

 Use it to do a better job of impersonating.  Try it out on other sites.

 I don't understand how you could impersonate better, could you
 explain?  You can send mail with any From: you want without bothering
 to go through someone's mailman account, and you can't even send mail
 from the mailman interface!

 Since mailman passwords are randomly generated at subscription time
 (and virtually never changed), password reuse is pretty unlikely.

 Can't a mailman account holder associate a public key with a mailman instance?

Not in stock mailman (http://www.gnu.org/s/mailman/features.html), but
there is a fork which permits it, I think.

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

Re: Minor type confusion in proxies proposal?

[David Bruant]

Hi Andreas,

Property descriptors as specific type is an internal construct of the
ES spec. Their definition in ES5 was used in the context of ES5 (with
normal objects, host objects but no proxies). The proxy API needed a way
to represent them. Objects sound like the natural construct to do so.

First, you have to notice that the object is copied, so a different
object is passed as argument to the defineProperty trap and as argument
within the trap. Same for the return value of getOwnPropertyDescriptor.
So there is no way the proxy can magically change a property descriptor
(since within the proxy, there are only proxies)
Then, the intention behind letting custom attribute pass is to encourage
innovation.
Proxies have the potential to be arbitrarily complicated; so should be
their dialog interface (defineProperty, getOwnPropertyDescriptor). For
instance, in an experiment of mine [1], I use a custom index property
attribute. If some good idea come out (unlike my experiment), they could
be integrated to a next version of ECMAScript.

So I agree that objects as property descriptors within traps instead of
a custom type are a derivation from the spec, but I think it's a good thing.

Tom: about ...except that it also retains any non-standard attributes
present in the original property descriptor passed to
Object.defineProperty., what do you mean by any?
Is it Object.keys(desc)?
Object.enumerate(desc) (I mean the prop list enumerated over with for-in)?
Object.getOwnPropertyNames(desc)?

David

[1] https://github.com/DavidBruant/PropStackObjects (see the HTMLs to
see how it works)

Le 01/07/2011 14:54, Andreas Rossberg a écrit :
 On 1 July 2011 12:12, Andreas Rossberg rossb...@google.com wrote:
 I believe there is some type confusion in the proxy proposal spec
 wrt property descriptors and their reification into attributes
 objects.

 1. In a note on the def of [[DefineOwnProperty]] for proxies, the proposal 
 says:

 The Desc argument to this trap is a property descriptor object
 validated by ToPropertyDescriptor, except that it also retains any
 non-standard attributes present in the original property descriptor
 passed to Object.defineProperty. See the semantics of the modified
 Object.defineProperty built-in, below.

 That seems fishy, since according to ES5 8.10:

 Values of the Property Descriptor type are records composed of named
 fields where each field‘s name is an attribute name and its value is a
 corresponding attribute value as specified in 8.6.1.

 In particular, I take this to mean that property descriptors are not
 objects (but abstract records), and that there cannot be any fields
 whose name is not an attribute name. (In fact, in V8 we currently
 encode property descriptors using objects, but the encoding is
 different from the reified attributes object representation, and not
 quite compatible with the idea of adding arbitrary other fields.)
 I forgot to say: step 5 of the definition invokes the defineProperty
 trap of the handler passing Desc as the second argument. But the
 handler expects a reified attributes object.

 2. In the modified definition of Object.defineProperty, the proposal
 says in step 4.c:

 Call the [[DefineOwnProperty]] internal method of O with arguments
 name, descObj, and true.

 This is passing descObj, which in fact is _not_ a descriptor, but its
 reification as an attributes object.

 /Andreas

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

Date.prototype mutable internal properties

[David Bruant]

Hi,

I just wanted to put on es-discuss the concern raised by Mark Miller [1]
about mutable internal properties of Date.prototype and that it should
be fixed in the next version of ECMAScript.

David

[1] http://code.google.com/p/google-caja/issues/detail?id=1362
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: prototype focus

[Irakli Gozalishvili]

On Friday, 2011-07-01 at 19:31 , Brendan Eich wrote:

 On Jul 1, 2011, at 6:19 AM, Irakli Gozalishvili wrote:
 
  With focus on prototype this is so much simpler: 
  
  
  var Foo = Object.extend({
   initialize: function(options) { ... },
  do_foo_job: function() { ... }
  })
  
  
  
  
  
  
 
 
 With | and 'super' in functions, I think you are set. It's hard to add more. 
 The main debate is about whether this is enough, or do classes as sugar 
 provide enough added value?
 
 (But you didn't show Bar as well as Foo.)
 

Sorry I don't understand what did I failed to show in Bar ?

My intent was to show that classes don't necessary need to have own 
constructors / initialization methods as they can be
simply inherited via prototype chain. Or did you meant something else ? 

 /be
 
 
  
  
  On Friday, 2011-07-01 at 11:10 , Axel Rauschmayer wrote:
  
I don't think
JavaScript has ever been far from its prototype roots especially if
the programmer shifts to thinking about a prototype object instead of
thinking about a functions prototype property.
   
   That is basically the point that the proposal tries to make. Have you 
   taken a look at the library code? It is very short and not a radical 
   overhaul.
   http://dl.2ality.com/dl/2011/06/Proto.js
   
   Note how below, there is always an extra prototype in there with 
   constructor functions.
   
   Super-calls (there will be syntactic sugar for this):
   - Constructor functions: Superclass.prototype.foo.call(this)
   - PAC: Superclass.foo.call(this)
   
   Subclassing:
   - Constructor functions: Subclass.prototype = 
   Object.create(Superclass.prototype)
   - PAC: let Subclass = Object.create(Superclass)
   
   Instanceof (internally):
   - Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
   - PAC: o instanceof C === C.isPrototypeOf(o)
   
   
 Problems that both prototypes-as-classes (PAC) and class literals 
 (CL) are
 trying to solve are:
 - Subclassing is hard and not directly supported by the language: 
 connecting
 prototypes, chaining constructors, super-references.

Object.getPrototypeOf(this).foo.call(this) is pretty long.
   
   See above.
   
It seems to me that perhaps the PaC drifted too far or perhaps started
too far from what JavaScript has already. If the idea is to shift the
focus more towards prototypes, then starting from something like what
I've written and adding super syntax would be more consistent with
what JavaScript already has.
   
   
   “too far from what JavaScript has already” is very vague. How so? With 
   class literals, your code will look like PAC, anyway. Have you taken a 
   look at Sect. 3? Do you agree that the mentioned conceptual 
   simplifications hold?
   http://www.2ality.com/2011/06/prototypes-as-classes.html#3
   
   I find Brendan’s anti-PAC argument much more convincing: that all people 
   might find it more natural to think in terms of constructors than in 
   terms of prototypes. If that is the case then PAC would be a bad idea. 
   The other convincing anti-PAC argument is that it is a bad idea to have 
   two class mechanisms.
   
   -- 
   Dr. Axel Rauschmayer
   
   a...@rauschma.de (mailto:a...@rauschma.de)
   twitter.com/rauschma (http://twitter.com/rauschma)
   
   home: rauschma.de (http://rauschma.de/)
   blog: 2ality.com (http://2ality.com/)
   
   
   
   ___
   es-discuss mailing list
   es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
   https://mail.mozilla.org/listinfo/es-discuss
  
  ___
  es-discuss mailing list
  es-discuss@mozilla.org (mailto: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: prototype focus

[Axel Rauschmayer]

 With | and 'super' in functions, I think you are set. It's hard to add more. 
 The main debate is about whether this is enough, or do classes as sugar 
 provide enough added value?

|, super and possibly some support for subclassing (to set up the constructor 
property in subclasses etc.) would cover *a lot* of ground (if we can’t have 
something more sophisticated – I’m wondering if we are at a “now or never” 
point in this regard. That is: If we don’t make breaking changes for insert 
your favorite class-like construct now, will we ever?).

One thing that should be kept in mind is tool support: How do IDEs get enough 
information for auto-expansion etc. Lack of a good IDE still makes it slightly 
painful to write JavaScript for me (while I really like the language). Is there 
someone with experience in that department that could comment? I’m guessing 
that type guards would help(?) What else?

IDE support would be a pro-class literal argument, I guess. Another question: 
If *everything* is encapsulated (instantiation, subclassing, instanceof, etc.) 
then it doesn’t matter any more what goes on under the hood.

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



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

Re: prototype focus

[Brendan Eich]

On Jul 1, 2011, at 8:40 AM, Irakli Gozalishvili wrote:
 On Friday, 2011-07-01 at 16:38 , Mark S. Miller wrote:
 
 With two expectations for the semantics of something that does not appear in 
 the code, and without a static or dynamic rejection to prevent progress of 
 the code written to the wrong assumption, I now finally feel strongly about 
 this. The critics were right -- we should not provide any default 
 constructor. Thanks for pointing out the problem case.
  
 
 Do you think prototype focused version:
 
  Prototype.new(foo);
 
 also suggest wrong assumptions ?

What's the constructor protocol here? If I don't implement Prototype.new or 
Prototype.constructor, then what in the super-prototype is called, with what 
arguments?


 If not (which I think is the case) is another + in favor of prototype focus. 

This scoring is silly. The trouble with OOP default-constructor protocols is 
there are so many of them. Having none, as Mark points out, avoids trouble. 
Having a different one from any in the language as conventionally used 
(including built-ins, DOM, etc.), even with prototype focus, does not guarantee 
anything.

As Axel has acknowledged, any .new protocol will coexist with 
constructor.prototype, forever. Adding explicit super-constructor calling is 
part of the classes deal, whatever the focus (constructor or prototype). 
Defaulting the super-constructor call or even the constructor implementation is 
trouble.

/be

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

Re: Minor type confusion in proxies proposal?

[Brendan Eich]

On Jul 1, 2011, at 11:37 AM, Andreas Gal wrote:

 In our implementation we are using a generic object. It has some overhead, 
 and a specific internal descriptor object representation might be a bit 
 faster, but such magic objects that don't allow expando properties are 
 usually pretty surprising to programers. Most of the HTML5 DOM allows 
 arbitrary expando properties. I think we should stick to that theme.

IIRC Tom and Mark's http://traitsjs.org/ work relies on being able to extend 
property descriptors with .required and other ad-hoc (expando) properties. 
This is important: it allows developers to blaze trails and tread paths that we 
later pave with standards.

/be

 
 Andreas
 
 On Jul 1, 2011, at 5:54 AM, Andreas Rossberg wrote:
 
 On 1 July 2011 12:12, Andreas Rossberg rossb...@google.com wrote:
 I believe there is some type confusion in the proxy proposal spec
 wrt property descriptors and their reification into attributes
 objects.
 
 1. In a note on the def of [[DefineOwnProperty]] for proxies, the proposal 
 says:
 
 The Desc argument to this trap is a property descriptor object
 validated by ToPropertyDescriptor, except that it also retains any
 non-standard attributes present in the original property descriptor
 passed to Object.defineProperty. See the semantics of the modified
 Object.defineProperty built-in, below.
 
 That seems fishy, since according to ES5 8.10:
 
 Values of the Property Descriptor type are records composed of named
 fields where each field‘s name is an attribute name and its value is a
 corresponding attribute value as specified in 8.6.1.
 
 In particular, I take this to mean that property descriptors are not
 objects (but abstract records), and that there cannot be any fields
 whose name is not an attribute name. (In fact, in V8 we currently
 encode property descriptors using objects, but the encoding is
 different from the reified attributes object representation, and not
 quite compatible with the idea of adding arbitrary other fields.)
 
 I forgot to say: step 5 of the definition invokes the defineProperty
 trap of the handler passing Desc as the second argument. But the
 handler expects a reified attributes object.
 
 2. In the modified definition of Object.defineProperty, the proposal
 says in step 4.c:
 
 Call the [[DefineOwnProperty]] internal method of O with arguments
 name, descObj, and true.
 
 This is passing descObj, which in fact is _not_ a descriptor, but its
 reification as an attributes object.
 
 /Andreas
 
 ___
 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: prototype focus

[Brendan Eich]

On Jul 1, 2011, at 2:28 PM, Irakli Gozalishvili wrote:
 On Friday, 2011-07-01 at 19:31 , Brendan Eich wrote:
 
 On Jul 1, 2011, at 6:19 AM, Irakli Gozalishvili wrote:
 
 With focus on prototype this is so much simpler: 
 
 var Foo = Object.extend({
initialize: function(options) { ... },
do_foo_job: function() { ... }
 })
 
 With | and 'super' in functions, I think you are set. It's hard to add 
 more. The main debate is about whether this is enough, or do classes as 
 sugar provide enough added value?
 
 (But you didn't show Bar as well as Foo.)
 
 
 Sorry I don't understand what did I failed to show in Bar ?

I was replying to your message sent too soon; sorry, I should have looked ahead 
for your complete followup.


 My intent was to show that classes don't necessary need to have own 
 constructors / initialization methods as they can be
 simply inherited via prototype chain. Or did you meant something else ?  

No, I was looking for your version of Bar as prototype not constructor function.

/be

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

Re: Unifying Block and ObjectLiteral (was: Re: block-lambda revival)

[Mike Samuel]

2011/7/1 Brendan Eich bren...@mozilla.com:
 On Jul 1, 2011, at 10:51 AM, Mike Samuel wrote:

 What is

   ({
     get
     x()
     {
       return 42;
     }
   })

 ?

 Could it match both as an object literal with a getter

   ({ get x() { return 42; } })

 Only that.


 or as a block with 3 statements?

   ({ get; x(); { return 42; } })

 No, never. You're forgetting the first rule of ASI fight-club: if there's no 
 error there is no semicolon insertion.

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

Re: Date.prototype mutable internal properties

[Mark S. Miller]

Thanks David,

Yes, this is important. The way I noticed it is that the same issue came up
for the FF implementation of WeakMaps 
https://bugzilla.mozilla.org/show_bug.cgi?id=656828. I will be proposing
the to-be-fixed Mozilla API to the committee to become the new WeakMap
proposal -- making it more consistent with Map and Set. But not at the
upcoming meeting -- it's not on the agenda.

In the meantime, 
http://google-caja.googlecode.com/svn/trunk/src/com/google/caja/ses/repairES5.js
repairs this and many other problems encountered in today's almost-ES5
implementations. Except for this issue with Date and WeakMap, all the other
repairs in that file are spec non-conformances. See the kludges list at 
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#989
for cross referencing between these repairs, various bug threads, and
Sputnik/test262 test names.


On Fri, Jul 1, 2011 at 12:28 PM, David Bruant david.bru...@labri.fr wrote:

 Hi,

 I just wanted to put on es-discuss the concern raised by Mark Miller [1]
 about mutable internal properties of Date.prototype and that it should
 be fixed in the next version of ECMAScript.

 David

 [1] http://code.google.com/p/google-caja/issues/detail?id=1362




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

Re: Minor type confusion in proxies proposal?

[Mark S. Miller]

On Fri, Jul 1, 2011 at 2:55 PM, Brendan Eich bren...@mozilla.com wrote:

 On Jul 1, 2011, at 11:37 AM, Andreas Gal wrote:

  In our implementation we are using a generic object. It has some
 overhead, and a specific internal descriptor object representation might
 be a bit faster, but such magic objects that don't allow expando properties
 are usually pretty surprising to programers. Most of the HTML5 DOM allows
 arbitrary expando properties. I think we should stick to that theme.

 IIRC Tom and Mark's http://traitsjs.org/ work relies on being able to
 extend property descriptors with .required and other ad-hoc (expando)
 properties. This is important: it allows developers to blaze trails and
 tread paths that we later pave with standards.


These are present in the user visible descriptor objects, but traits.js does
not assume they are preserved in the internal descriptors. It can't assume
that, since trait.js works on current ES5 browsers whose internal
descriptors don't. Maybe Tom has thought about it, but we haven't discussed
how this change would effect traits.js. My guess it is would have a positive
effect. Tom?




 /be

 
  Andreas
 
  On Jul 1, 2011, at 5:54 AM, Andreas Rossberg wrote:
 
  On 1 July 2011 12:12, Andreas Rossberg rossb...@google.com wrote:
  I believe there is some type confusion in the proxy proposal spec
  wrt property descriptors and their reification into attributes
  objects.
 
  1. In a note on the def of [[DefineOwnProperty]] for proxies, the
 proposal says:
 
  The Desc argument to this trap is a property descriptor object
  validated by ToPropertyDescriptor, except that it also retains any
  non-standard attributes present in the original property descriptor
  passed to Object.defineProperty. See the semantics of the modified
  Object.defineProperty built-in, below.
 
  That seems fishy, since according to ES5 8.10:
 
  Values of the Property Descriptor type are records composed of named
  fields where each field‘s name is an attribute name and its value is a
  corresponding attribute value as specified in 8.6.1.
 
  In particular, I take this to mean that property descriptors are not
  objects (but abstract records), and that there cannot be any fields
  whose name is not an attribute name. (In fact, in V8 we currently
  encode property descriptors using objects, but the encoding is
  different from the reified attributes object representation, and not
  quite compatible with the idea of adding arbitrary other fields.)
 
  I forgot to say: step 5 of the definition invokes the defineProperty
  trap of the handler passing Desc as the second argument. But the
  handler expects a reified attributes object.
 
  2. In the modified definition of Object.defineProperty, the proposal
  says in step 4.c:
 
  Call the [[DefineOwnProperty]] internal method of O with arguments
  name, descObj, and true.
 
  This is passing descObj, which in fact is _not_ a descriptor, but its
  reification as an attributes object.
 
  /Andreas
 
  ___
  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




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