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
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 ||
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
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
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);
}
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))
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
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
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
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
-discuss-requ...@mozilla.org
es-discuss-requ...@mozilla.org wrote:
From: Peter Michaux petermich...@gmail.competermich...@gmail.com
Date: June 30, 2011 21:54:47 GMT+02:00
To: es-discuss es-discuss@mozilla.orges-discuss@mozilla.org
Subject: prototype focus
There seems to have been
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
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.
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
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?
|, super and possibly some support for subclassing (to set up the constructor
property in subclasses etc.) would
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
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) { ... },
On Thu, Jun 30, 2011 at 12:54 PM, Peter Michaux petermich...@gmail.comwrote:
There seems to have been a lot of fuss here about focusing on
prototypes first rather than on constructor functions. As it stands
now, I don't see how JavaScript makes focusing on prototypes
difficult.
// focus on
, at 1:07 , es-discuss-requ...@mozilla.org wrote:
From: Peter Michaux petermich...@gmail.com
Date: June 30, 2011 21:54:47 GMT+02:00
To: es-discuss es-discuss@mozilla.org
Subject: prototype focus
There seems to have been a lot of fuss here about focusing on
prototypes first rather than
@mozilla.org
Subject: prototype focus
There seems to have been a lot of fuss here about focusing on
prototypes first rather than on constructor functions. As it stands
now, I don't see how JavaScript makes focusing on prototypes
difficult.
// focus on the prototype first
// Make it non-abstract
21 matches
Mail list logo
