(function () {}) creates two object, not one.
I'm not sure what you meant here. ..
the empty object for the function's .prototype
currently seems to elude me in all its forms..
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
Allen Wirfs-Brock wrote:
On Mar 17, 2012, at 1:20 PM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
This has nothing to do with classes. It is just basic prototypal
inheritance and the semantics of the new operator and function
expressions.
Well, seems convincing... but nevertheless, I see it
Hi Allen,
Thanks for taking the time to read and respond. I've read your reply in
detail and I feel like it deserves a point-by-point response, but I think
the following might get us on the same page more quickly.
The important point to consider is that I'm *not* comparing this:
A.)
let
Axel Rauschmayer wrote:
private x,y; is syntactically tricky inside an object initializer. The previous
consensus was to use
private { x, y }
I don't like object literal syntax, it takes over like a weed. If
classes are worth adding with higher-level (but still desugarable)
semantics
That makes sense.
One thing to look out for: Not loosing one’s mind due to subtle syntactic
differences between modules, class declarations and object initializers (and
possibly cascades). There needs to be consistency. But (implicit) rules such as
“colon = separator is comma” and “equals =
Kevin Smith wrote:
var Blah = BaseClass | function(){}
Blah.prototype.{
a: function(){},
b: function(){}
}
The point I'm trying to drive home is that the above is no better
(worse, in fact) from a user experience standpoint, than what I have
now.
var Blah = BaseClass | function(){}
Blah.prototype.{
a: function(){},
b: function(){}
}
let Blah = BaseClass | function() {
}.prototype.(
a() {},
b() {}
}.constructor.{};
1. I don't like the imperative approximations of a declarative API.
Since we're
The example you gave produces a constructor that wraps a handful of
instance method definitions along with several function declarations -
which I'm arguing could just as easily be outside of that function
declaration, but inside of an IIFE.
There are two issues here:
1) “Private methods”
Claus Reinke wrote:
var Blah = BaseClass | function(){}
Blah.prototype.{
a: function(){},
b: function(){}
}
let Blah = BaseClass | function() {
}.prototype.(
a() {},
b() {}
}.constructor.{};
1. I don't like the imperative approximations of a declarative API.
Since we're designing new
1. I don't like the imperative approximations of a declarative API.
Since we're designing new language features, approximations
should not be necessary.
There have been suggestions to interpret '|' declaratively,
and to avoid the special case for function rhs, ie, to interpret
(p | obj) simply
Currently, | sets the [[prototype]] field of the RHS object,
and -if the RHS is a function literal- also specifies the [[prototype]]
field of objects generated from it. I suggest to remove that special
case for function RHS.
Ultimately, this is my suggestion as well. And for class
On Mar 17, 2012, at 12:18 PM, Kevin Smith khs4...@gmail.com wrote:
Currently, | sets the [[prototype]] field of the RHS object,
and -if the RHS is a function literal- also specifies the [[prototype]]
field of objects generated from it. I suggest to remove that special
case for function RHS.
On Mar 16, 2012, at 11:42 PM, Kevin Smith wrote:
Hi Allen,
Thanks for taking the time to read and respond. I've read your reply in
detail and I feel like it deserves a point-by-point response, but I think the
following might get us on the same page more quickly.
The important point
On Mar 17, 2012, at 8:39 AM, Claus Reinke wrote:
1. I don't like the imperative approximations of a declarative API.
Since we're designing new language features, approximations
should not be necessary.
There have been suggestions to interpret '|' declaratively,
and to avoid the special
Claus Reinke wrote:
1. I don't like the imperative approximations of a declarative API.
Since we're designing new language features, approximations
should not be necessary.
There have been suggestions to interpret '|' declaratively,
and to avoid the special case for function rhs, ie, to
Allen Wirfs-Brock wrote:
On Mar 17, 2012, at 8:39 AM, Claus Reinke wrote:
1. I don't like the imperative approximations of a declarative API.
Since we're designing new language features, approximations
should not be necessary.
There have been suggestions to interpret '|' declaratively,
and
On Mar 17, 2012, at 1:20 PM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
...
(function () {}) creates two object, not one. We have to set the
[[Prototype]] of both objects to something. In deciding how to do
this it is important to look at the role of each member of that
object
While you wouldn't use A because it can't express the full semantics of C,
that doesn't mean that many users who currently have to write B wouldn't
prefer to be able to write A.
Yes - many (most?) users will benefit from being able to write A. But the
thrust of my argument is not that there
Kevin Smith wrote:
Rather than abuse your inbox, I published this as a blog entry:
http://blog.khs4473.com/2012/03/using-object-literals-as-classes.html
Summary: It has been suggested that extended object literals can be
used to define class-like abstractions, and that consequently class
Le 16/03/2012 17:53, Herby Vojčík a écrit :
And second, it is not a tragedy if such classes leak.
What do you mean exactly by leak. Like private name leaking?
David
___
es-discuss mailing list
es-discuss@mozilla.org
Hi,
I'll do a 2 parts answer. First, I'll answer the blog post, second, I'll
try to take a step back and discuss composition in JavaScript.
=== Part I ===
Le 16/03/2012 17:04, Kevin Smith a écrit :
Rather than abuse your inbox, I published this as a blog entry:
David Bruant wrote:
Le 16/03/2012 17:53, Herby Vojčík a écrit :
And second, it is not a tragedy if such classes leak.
What do you mean exactly by leak. Like private name leaking?
Some of the underlying mechanics.
David
___
es-discuss mailing
Thanks, David.
First, I'd like to point out that in the blog post I'm putting on the hat
of a library author (I happen to be one, but that's beside the point).
One of the first conclusions that I come to (as a library author) is that
the idiom described here:
On Fri, Mar 16, 2012 at 4:26 PM, Kevin Smith khs4...@gmail.com wrote:
Thanks, David.
First, I'd like to point out that in the blog post I'm putting on the hat
of a library author (I happen to be one, but that's beside the point).
One of the first conclusions that I come to (as a library
16, 2012 17:07
To: Kevin Smith
Cc: es-discuss
Subject: Re: Using Object Literals as Classes
On Fri, Mar 16, 2012 at 4:26 PM, Kevin Smith
khs4...@gmail.commailto:khs4...@gmail.com wrote:
Thanks, David.
First, I'd like to point out that in the blog post I'm putting on the hat of a
library author (I
Domenic Denicola wrote:
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no prototype
methods at all), since we value encapsulation. I can't imagine we're alone.
So any class solution that doesn't fully incorporate private names (e.g.
by
, March 16, 2012 17:20
To: Domenic Denicola
Cc: Russell Leggett; Kevin Smith; es-discuss
Subject: usable enough private names (was: Re: Using Object Literals as Classes)
Domenic Denicola wrote:
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e
Le 16/03/2012 21:26, Kevin Smith a écrit :
Thanks, David.
First, I'd like to point out that in the blog post I'm putting on the
hat of a library author (I happen to be one, but that's beside the point).
One of the first conclusions that I come to (as a library author) is
that the idiom
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no prototype
methods at all), since we value encapsulation. I can't imagine we're alone.
For my own
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
dome...@domenicdenicola.com mailto:dome...@domenicdenicola.com wrote:
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no
On Fri, Mar 16, 2012 at 6:04 PM, David Bruant bruan...@gmail.com wrote:
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Just to contribute to this... er... fun-thread...
My team uses the closure pattern
On Mar 16, 2012, at 18:05, David Bruant
bruan...@gmail.commailto:bruan...@gmail.com wrote:
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
Just to contribute to this... er...
On Mar 16, 2012, at 18:12, Rick Waldron
waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote:
On Fri, Mar 16, 2012 at 6:04 PM, David Bruant
bruan...@gmail.commailto:bruan...@gmail.com wrote:
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
Le 16/03/2012 23:12, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 6:04 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
dome...@domenicdenicola.com
On Fri, Mar 16, 2012 at 3:04 PM, David Bruant bruan...@gmail.com wrote:
Unfortunately, methods on prototype require to have properties that are
public.
If you avoid prototype methods, all your attributes and private methods can
be shared by public method scopes.
I think you are mixing up
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no prototype methods
at all), since we value encapsulation. I can't imagine we're alone.
Do you see privacy via closures and prototypes as mutually exclusive? In my
experience, they
On Fri, Mar 16, 2012 at 6:20 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
On Mar 16, 2012, at 18:12, Rick Waldron waldron.r...@gmail.com wrote:
On Fri, Mar 16, 2012 at 6:04 PM, David Bruant bruan...@gmail.com wrote:
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Friday, March 16, 2012 18:40
To: Domenic Denicola
Cc: David Bruant; es-discuss
Subject: Re: Using Object Literals as Classes
On Fri, Mar 16, 2012 at 6:20 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com
From: Axel Rauschmayer [mailto:a...@rauschma.de]
Sent: Friday, March 16, 2012 18:35
To: Domenic Denicola
Cc: Russell Leggett; Kevin Smith; es-discuss
Subject: Re: Using Object Literals as Classes
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes
On Mar 16, 2012, at 7:11 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Friday, March 16, 2012 18:40
To: Domenic Denicola
Cc: David Bruant; es-discuss
Subject: Re: Using Object Literals as Classes
On Fri, Mar
On Fri, Mar 16, 2012 at 4:23 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
In theory I see them as complementary, but in practice I have never been
able to integrate prototypes. Consider: a method can only be attached to a
prototype if it needs access to an instance’s public state
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Friday, March 16, 2012 19:28
To: Domenic Denicola
Cc: David Bruant; es-discuss
Subject: Re: Using Object Literals as Classes
On Mar 16, 2012, at 7:11 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote
On Mar 16, 2012, at 7:37 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Friday, March 16, 2012 19:28
To: Domenic Denicola
Cc: David Bruant; es-discuss
Subject: Re: Using Object Literals as Classes
On Mar 16, 2012
var Blah = BaseClass | function(){}
Blah.prototype.{
a: function(){},
b: function(){}
}
The point I'm trying to drive home is that the above is no better (worse,
in fact) from a user experience standpoint, than what I have now. To be
blunt, I would not use the above
Kevin,
Thanks for taking the time to write up your thoughts[1] in this area. I won't
try to make a point by point response because I think others on this list are
already doing a good job at this. However, I do what do clarify a few points
about the intent and likely usage patterns of of
On Mar 16, 2012, at 6:05 PM, Kevin Smith wrote:
var Blah = BaseClass | function(){}
Blah.prototype.{
a: function(){},
b: function(){}
}
The point I'm trying to drive home is that the above is no better (worse, in
fact) from a user experience standpoint, than what I
On Fri, Mar 16, 2012 at 6:28 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On this point, I probably should
define what I mean by declarative. I consider code to be declarative, if
a human (or an appropriately programmed machine) can understand its meaning
without actually (or
private x,y; is syntactically tricky inside an object initializer. The previous
consensus was to use
private { x, y }
For example here:
https://gist.github.com/1332193 (Brendan’s class proposal)
https://gist.github.com/1336846 (my class proposal)
On Mar 16, 2012, at 22:24 , Domenic
48 matches
Mail list logo
