On Nov 1, 2011, at 10:27 PM, David Flanagan wrote:
[Oops. Replied to Brendan personally rather than reply-all to the list.]
My reply was private too. Here it is:
On Nov 1, 2011, at 10:15 PM, David Flanagan wrote:
On 11/1/11 5:18 PM, Brendan Eich wrote:
Love it or hate it, I'm ok either
A working draft of the ECMAScript Globalization API Specification for review at
the November TC 39 meeting is available at
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
There are still a number of open issues, and the algorithms still need
significant work, but the
The new more object-literal-style syntax is great. private sticks out a bit,
but it’s not a deal-breaker. It could even be good for the code if it had to
appear at the beginning (kind of like a section). Such a section would be great
for object literals, too. Maybe we can find a syntax that
super Foo.bar(x) should desugar to Foo.prototype.bar.call(this, x)
http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super
What is that you don’t like about Allen’s proposal? You are still hard-coding
the name of the super-constructor (which is what `super` nicely avoids).
If
On 02/11/11 11:01, Erik Corry wrote:
2011/11/2 Axel Rauschmayera...@rauschma.de:
super Foo.bar(x) should desugar to Foo.prototype.bar.call(this, x)
http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super
What is that you don’t like about Allen’s proposal? You are still
Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
(Full Disclosure: I'm still very opposed to const, private, and their
object-lockdown friends, )
Could you elaborate on this point?
All object-lockdown I can think (non-configurability, non-writability,
non-enumerability, private names, const
I don’t think Allen’s proposal is controversial, any more. It’s how things work
in almost all mainstream (OO) languages. I don’t see myself using `super`
anywhere outside an object literal – except for a few cases where
Object.defineMethod() works just fine. Do you have any real-world examples
On 02/11/11 13:01, David Bruant wrote:
Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
(Full Disclosure: I'm still very opposed to const, private, and their
object-lockdown friends, )
Regarding const, it's an optional keyword basically telling the
interpreter hey, the value isn't suppose
Does object@name break encapsulation? One could mutate object@name for any
instance of the class passed in via a parameter for example.
On Nov 2, 2011, at 8:01 AM, David Bruant bruan...@gmail.com wrote:
Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
(Full Disclosure: I'm still very opposed
Le 02/11/2011 16:15, Quildreen Motta a écrit :
On 02/11/11 13:01, David Bruant wrote:
Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
(Full Disclosure: I'm still very opposed to const, private, and
their object-lockdown friends, )
Regarding const, it's an optional keyword basically
That said, there are some valid use-cases for it... I guess?
Encapsulation? Stability of interfaces? Better readability? The use case is
more about code quality and expressiveness rather than adding a new
capability to the language.
The two most interesting use cases I see are (for all my
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant bruan...@gmail.com wrote:
Could you elaborate on this point?
All object-lockdown I can think (non-configurability, non-writability,
non-enumerability, private names, const variables, const classes) of is
optional. Why are you against them?
I was
On Wed, Nov 2, 2011 at 9:05 AM, Jeremy Ashkenas jashke...@gmail.com wrote:
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant bruan...@gmail.com wrote:
Could you elaborate on this point?
All object-lockdown I can think (non-configurability, non-writability,
non-enumerability, private names, const
On 02/11/11 14:05, Jeremy Ashkenas wrote:
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Could you elaborate on this point?
All object-lockdown I can think (non-configurability,
non-writability, non-enumerability, private names,
On 02/11/11 14:26, John J Barton wrote:
Another maybe stronger argument is simplicity: these myriad new minor
features create a blizzard of chaff in the way of developers. One
excellent example is Object.create(). Here was a terrific opportunity
to simplify the language based on years of
Le 02/11/2011 17:26, John J Barton a écrit :
On Wed, Nov 2, 2011 at 9:05 AM, Jeremy Ashkenas jashke...@gmail.com wrote:
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant bruan...@gmail.com wrote:
Could you elaborate on this point?
All object-lockdown I can think (non-configurability,
I agree with every sentence in this post.
+1K :)
-Mikeal
On Nov 2, 2011, at November 2, 20119:05 AM, Jeremy Ashkenas wrote:
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant bruan...@gmail.com wrote:
Could you elaborate on this point?
All object-lockdown I can think (non-configurability,
On Wed, Nov 2, 2011 at 5:44 PM, David Bruant bruan...@gmail.com wrote:
I agree that the second argument is a design mistake. But ES6 will fix
this with the proto operator.
fix
It has the same kind of baggage and goes into the minor features
category, at least in terms of syntax, in my opinion.
On Nov 2, 2011, at November 2, 20119:30 AM, Quildreen Motta wrote:
freeze does not add anything new to an object. If you don't want to change
the shape of an object ... don't change the shape of the object.
Again, immutability isn't just about security, but optimisation as well. You
could
On Nov 2, 2011, at 4:10 AM, David Bruant wrote:
Another topic:
-
class Monster {
private name, health;
sameName(other) {
return @name === other@name;
}
}
-
I am under this impression that you are accessing the private property
(other@name) of an instance which
On Nov 2, 2011, at 5:34 AM, Axel Rauschmayer wrote:
I think the namespacing via this is a feature, it give the code a nice
uniform look:
if (this.foo === other.foo)
You can use this@priv == other@priv if you like. My proposal, after Ruby and
CoffeeScript, is to support @priv (with [no
On Nov 2, 2011, at 6:26 AM, Jeremy Ashkenas wrote:
That said, we should take care to have the two things be fully consistent: A
class body should *be* an object literal, with no subtle differences in the
grammar leading to stumbling blocks down the line. If class bodies can have:
class
On Nov 2, 2011, at 8:25 AM, Kam Kasravi wrote:
Does object@name break encapsulation? One could mutate object@name for any
instance of the class passed in via a parameter for example.
At the Nov. 2008 TC39 meeting, we agreed on class-private instance variables,
not instance-private ivars.
On Nov 2, 2011, at 9:05 AM, Jeremy Ashkenas wrote:
I'd be glad to elaborate -- but since it's off topic for minimal classes,
changing the Subject here.
Thanks for that.
What draws people to dynamic languages is freedom.
And JavaScript is one of the *most* dynamic of the mainstream
On Nov 2, 2011, at 9:26 AM, John J Barton wrote:
Of course these details are
important for the use-cases that need them. Unfortunately everyone
else has to carry the baggage.
What exactly do you mean by carry?
Implementors have to implement. They get the big bucks and bear the burden for
2011/11/2 Quildreen Motta quildr...@gmail.com:
I don't think hard coding the name of the super-constructor is a
problem.
It is when you take into account that functions in JavaScript are not bound
to an object, they are generic. You can simply assign any function to any
object and it'll most
On Nov 2, 2011, at 9:46 AM, Mikeal Rogers wrote:
I agree with every sentence in this post.
+1K :)
Switching to CoffeeScript? :-P
/be
-Mikeal
On Nov 2, 2011, at November 2, 20119:05 AM, Jeremy Ashkenas wrote:
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant bruan...@gmail.com wrote:
On 02/11/11 15:41, Brendan Eich wrote:
On Nov 2, 2011, at 9:26 AM, John J Barton wrote:
Of course these details are
important for the use-cases that need them. Unfortunately everyone
else has to carry the baggage.
What exactly do you mean by carry?
Implementors have to implement. They get
On 11/1/11 11:53 PM, Brendan Eich wrote:
On Nov 1, 2011, at 10:27 PM, David Flanagan wrote:
1) Class bodies are new syntax, so you can introduce new keywords,
right? So 'prop' or 'proto'? 'static' puts a property on the class.
'private' puts a (private) property on the instance. So 'proto'
On 02/11/11 15:42, Erik Corry wrote:
2011/11/2 Quildreen Mottaquildr...@gmail.com:
I don't think hard coding the name of the super-constructor is a
problem.
It is when you take into account that functions in JavaScript are not bound
to an object, they are generic. You can simply assign any
Le 02/11/2011 17:05, Jeremy Ashkenas a écrit :
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Could you elaborate on this point?
All object-lockdown I can think (non-configurability,
non-writability, non-enumerability, private
On Nov 2, 2011, at 9:51 AM, Mikeal Rogers wrote:
On Nov 2, 2011, at November 2, 20119:30 AM, Quildreen Motta wrote:
freeze does not add anything new to an object. If you don't want to
change the shape of an object ... don't change the shape of the object.
Again, immutability isn't just
On Nov 2, 2011, at 10:35 AM, David Bruant wrote:
Le 02/11/2011 18:09, Brendan Eich a écrit :
On Nov 2, 2011, at 4:10 AM, David Bruant wrote:
Another topic:
-
class Monster {
private name, health;
sameName(other) {
return @name === other@name;
}
}
-
I am under this
On Nov 2, 2011, at 10:42 AM, Erik Corry wrote:
troll C++ requires you to state the name of the super-class in super
calls, and Java doesn't. Do we want to be like Java? /troll
Wimpy Troll, easily defeated. We want to be like Ruby and CoffeeScript!
/be
On 02/11/11 15:49, Brendan Eich wrote:
On Nov 2, 2011, at 9:30 AM, Quildreen Motta wrote:
Also, note that `with' makes a whole awesome use-case for `Object.freeze':
'with' is gone in ES5 strict, ES6, and beyond -- you knew that, right?
Yep, and I still think it's a sad thing. Not that I use
On Nov 2, 2011, at 10:52 AM, David Flanagan wrote:
On 11/1/11 11:53 PM, Brendan Eich wrote:
On Nov 1, 2011, at 10:27 PM, David Flanagan wrote:
1) Class bodies are new syntax, so you can introduce new keywords, right?
So 'prop' or 'proto'? 'static' puts a property on the class. 'private'
Le 02/11/2011 19:00, Brendan Eich a écrit :
On Nov 2, 2011, at 10:35 AM, David Bruant wrote:
Le 02/11/2011 18:09, Brendan Eich a écrit :
On Nov 2, 2011, at 4:10 AM, David Bruant wrote:
Another topic:
-
class Monster {
private name, health;
sameName(other) {
return @name ===
On Nov 2, 2011, at 10:52 AM, Quildreen Motta wrote:
On 02/11/11 15:42, Erik Corry wrote:
2011/11/2 Quildreen Mottaquildr...@gmail.com:
I don't think hard coding the name of the super-constructor is a
problem.
It is when you take into account that functions in JavaScript are not bound
to an
On Nov 2, 2011, at 11:17 AM, David Bruant wrote:
See my reply to Kam. We're not sugaring instance-private ivars. I am
proposing something we agreed to in Nov. 2008: sugaring class-private ivars.
Ok, that's what I was missing. What were the rationale? use cases?
The rationale is that most
On 02/11/11 16:21, Brendan Eich wrote:
On Nov 2, 2011, at 10:52 AM, Quildreen Motta wrote:
On 02/11/11 15:42, Erik Corry wrote:
2011/11/2 Quildreen Mottaquildr...@gmail.com:
I don't think hard coding the name of the super-constructor is a
problem.
It is when you take into account that
On Wed, Nov 2, 2011 at 10:51 AM, Quildreen Motta quildr...@gmail.com wrote:
Imho, no users *SHOULD* use Object.create directly. That's why abstractions
exist —
Of course I agree with you!
and first class functions make it easy enough to make them.
But if we had Crockford's Object.create()
On Nov 2, 2011, at 12:00 PM, John J Barton wrote:
On Wed, Nov 2, 2011 at 10:51 AM, Quildreen Motta quildr...@gmail.com wrote:
Imho, no users *SHOULD* use Object.create directly. That's why abstractions
exist —
Of course I agree with you!
and first class functions make it easy enough to
Accidentally sent this only to Brendan, meant to send to list, resending:
On Wed, Nov 2, 2011 at 10:39 AM, Brendan Eich bren...@mozilla.com wrote:
2. Web developers both depend on and wish to minimize the size (to zero
bytes) of libraries.
3. Programming in the large, even ignoring security,
HAHA!
You'll pry JavaScript from my cold dead hands!
-Mikeal
On Nov 2, 2011, at November 2, 201110:49 AM, Brendan Eich wrote:
On Nov 2, 2011, at 9:46 AM, Mikeal Rogers wrote:
I agree with every sentence in this post.
+1K :)
Switching to CoffeeScript? :-P
/be
-Mikeal
On Nov
On Nov 2, 2011, at 1:17 PM, Kam Kasravi wrote:
On Nov 2, 2011, at 11:29 AM, Brendan Eich bren...@mozilla.com wrote:
On Nov 2, 2011, at 11:17 AM, David Bruant wrote:
See my reply to Kam. We're not sugaring instance-private ivars. I am
proposing something we agreed to in Nov. 2008:
On Nov 2, 2011, at November 2, 201110:57 AM, Brendan Eich wrote:
On Nov 2, 2011, at 9:51 AM, Mikeal Rogers wrote:
On Nov 2, 2011, at November 2, 20119:30 AM, Quildreen Motta wrote:
freeze does not add anything new to an object. If you don't want to
change the shape of an object ...
To bring the comments back around a little bit to this original proposal.
One thing I can't get over with this proposal is how obvious the syntax makes
the semantics. I didn't actually have to read any of the descriptions to figure
out how all of this works, my mind made a set of assumptions
On Nov 2, 2011, at 1:20 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 2, 2011, at 1:17 PM, Kam Kasravi wrote:
On Nov 2, 2011, at 11:29 AM, Brendan Eich bren...@mozilla.com wrote:
On Nov 2, 2011, at 11:17 AM, David Bruant wrote:
See my reply to Kam. We're not sugaring
On Wed, Nov 2, 2011 at 13:39, Mikeal Rogers mikeal.rog...@gmail.com wrote:
var generateModelClass = function(columns) {
var definition = {};
columns.forEach(function(col) {
definition['get' + col] = function() {
return this[col];
};
definition['set' + col] =
The draft has the following:
*6 The Globalization Object*
The Globalization object is a single object that has some named properties,
all of which are constructors.
The value of the [[Prototype]] internal property of the Globalization
object is the built-in Object prototype object specified by
On Nov 2, 2011, at 1:27 PM, Mikeal Rogers mikeal.rog...@gmail.com wrote:
On Nov 2, 2011, at November 2, 201110:57 AM, Brendan Eich wrote:
On Nov 2, 2011, at 9:51 AM, Mikeal Rogers wrote:
On Nov 2, 2011, at November 2, 20119:30 AM, Quildreen Motta wrote:
freeze does not add anything
Le 02/11/2011 21:27, Mikeal Rogers a écrit :
On Nov 2, 2011, at November 2, 201110:57 AM, Brendan Eich wrote:
This is fine with me and worth the price, but it clearly is not for
everyone.
I don't think I've ever heard an active JavaScript developer, who has
been programming in JavaScript
This is a contrived case, but in general, because JS objects are mutable,
and when they're used as prototypes they stand in for class vtables,
something has to pay a price. Either you worry about checking on every
d.m(i) call that the cached target method in b is still the one to call, or
I don't think I've ever heard an active JavaScript developer, who has
been programming in JavaScript longer than 6 months, ask for private class
or instance variables.
Your own code:
https://github.com/mikeal/npmjs.org/commit/c0d9cc77e79504b9a7c23b4fac735dde97444054#L3R10
Line 35, you
We were told (I think by Allen) that setting [[Extensible]] to true would
conflict in some way with ES6 modules. I do agree it's a big restriction to
set it to false given how JavaScript works today.
So the question is - are we going to have problems with ES6 Modules is we
set this property to
On 11/2/11 11:16 AM, Brendan Eich wrote:
On Nov 2, 2011, at 10:52 AM, David Flanagan wrote:
Could they have initializers that were automatically included in
the constructor?
I answered that in a gist comment. Yes, I like the CoffeeScript
constructor(@x, @y){} shorthand. Dart picked up on
Declaring vars in a function, private vars in a class or not using export in a
module often have similar objectives and ultimately is the decision of the
author. For serializable data structures that are reified in various places,
private is overkill and would complicate JSON.{stringify,parse}.
Le 02/11/2011 22:56, Jake Verbaten a écrit :
I don't think I've ever heard an active JavaScript developer, who
has been programming in JavaScript longer than 6 months, ask for
private class or instance variables.
Your own code:
On Nov 2, 2011, at 3:08 PM, David Flanagan wrote:
On 11/2/11 11:16 AM, Brendan Eich wrote:
On Nov 2, 2011, at 10:52 AM, David Flanagan wrote:
Could they have initializers that were automatically included in the
constructor?
I answered that in a gist comment. Yes, I like the
On Nov 2, 2011, at 3:00 PM, Nebojša Ćirić wrote:
We were told (I think by Allen) that setting [[Extensible]] to true would
conflict in some way with ES6 modules. I do agree it's a big restriction to
set it to false given how JavaScript works today.
So the question is - are we going to
On Nov 2, 2011, at 3:00 PM, Nebojša Ćirić wrote:
We were told (I think by Allen) that setting [[Extensible]] to true would
conflict in some way with ES6 modules. I do agree it's a big restriction to
set it to false given how JavaScript works today.
So the question is - are we going to
On Nov 2, 2011, at 4:09 PM, Allen Wirfs-Brock wrote:
Ideally, the globalization support would manifest as a global (or properties
on an existing global) in ES5 implementations and as a module in ES.next. Do
we know how to actually make that work?
What we did talk about was exposing the
My main concern at the moment is ES5. It seems that best practice is to
declare [[Extensible]]:true, which would in turn avoid conflicts with
pre-existing globals and let developers append new functionality to
Globalization. We can deal with modules in the future revisions if
necessary.
02.
On Nov 2, 2011, at 4:51 PM, Nebojša Ćirić wrote:
My main concern at the moment is ES5. It seems that best practice is to
declare [[Extensible]]:true, which would in turn avoid conflicts with
pre-existing globals and let developers append new functionality to
Globalization. We can deal with
I think we probably have an interesting question for Dave and Sam about how
to support version evolution of modules. Is there a module equivalent of
monkey patching. What if we have an implementation that exposes a V1 module
(particularly a built-in module) and code that depends upon upon
Updated: https://gist.github.com/1332193
$ git commit -a -mUpdates per conversations with @dflanagan and @allenwb.
git diff output below. Exec. summary: prefix groups via { ... } and public
@-namespace population to avoid this. sad-making verbosity.
/be
diff --git a/minimalist-classes.js
On Nov 2, 2011, at 7:00 PM, Brendan Eich wrote:
Updated: https://gist.github.com/1332193
$ git commit -a -mUpdates per conversations with @dflanagan and @allenwb.
git diff output below. Exec. summary: prefix groups via { ... } and public
@-namespace population to avoid this. sad-making
Last followup for tonight:
$ git diff
diff --git a/minimalist-classes.js b/minimalist-classes.js
index 7d8195e..d6bdab2 100644
--- a/minimalist-classes.js
+++ b/minimalist-classes.js
@@ -212,9 +212,9 @@ class Monster {
public flair, // you should have 37 pieces of public flair
I'm totally in agreement with Jeremy's class id objectLiteral proposal, but
for one thing: don't give up on your function definition syntax yet!
I really don't see any reason for adding a new way to define function
(methods). This:
class Runner {
run(a) {
}
}
is just as
On Nov 2, 2011, at 10:38 PM, Matthew Tretter wrote:
Introducing yet another syntax for creating a function feels like bloat to
me.
It's not just for creating a function. Method definition syntax was proposed a
while ago and it makes the method non-enumerable and binds super correctly.
70 matches
Mail list logo
