[+es-discuss]
Hi LungZeno. The es4-discuss list is inactive (as is ES4 of course). Please
discuss this on the es-discuss list, cc'ed.
On Wed, Dec 22, 2010 at 11:13 PM, LungZeno
lungzenoopen+...@gmail.comlungzenoopen%2b...@gmail.com
wrote:
I have read
[having trouble with my phone. Trying again]
This doesn't have anything to do with new revisions of the names proposal.
Every version, including the original, extended [[Get]] and [[Set]] and hence
effectively overloaded the square bracket notation.
Dave
- Original Message -
From:
On Dec 22, 2010, at 11:58 PM, Mark S. Miller wrote:
On Wed, Dec 22, 2010 at 11:44 PM, Brendan Eich bren...@mozilla.com wrote:
On Dec 22, 2010, at 11:34 PM, Mark S. Miller wrote:
Brendan, I still do not understand why you think it is illegitimate to
consider private names and soft fields
If I might ask a side-question: what's the value in making an object
non-extensible in ES5? I understand the value of making properties
non-configurable or non-writable, but I don't yet see a reason to prevent
extensions.
Thanks!
Kevin
On Thu, Dec 23, 2010 at 3:18 AM, Brendan Eich
On Wed, Dec 22, 2010 at 11:13 PM, LungZeno lungzenoopen+...@gmail.com
wrote:
I have read http://wiki.ecmascript.org/doku.php?id=strawman:module_loaders
Which is src in evalScript(src : String) : any; url or source code?
Can programmer eval code through ModuleLoader like eval operator?
On Thu, Dec 23, 2010 at 5:53 AM, Kevin Smith khs4...@gmail.com wrote:
If I might ask a side-question: what's the value in making an object
non-extensible in ES5? I understand the value of making properties
non-configurable or non-writable, but I don't yet see a reason to prevent
extensions.
On Dec 23, 2010, at 5:53 AM, Kevin Smith wrote:
If I might ask a side-question: what's the value in making an object
non-extensible in ES5? I understand the value of making properties
non-configurable or non-writable, but I don't yet see a reason to prevent
extensions.
Mark's answer
The private names proposal has a lot of good ideas, but their use is
not obvious.
The reasons I see for that are:
The private a; declaration:
* changes meaning of all obj.a in scope
* looks like a scoped variable, not a private element of an object
* is not generative-looking
... which makes it
On 2010-12-23 06:01, David-Sarah Hopwood wrote:
On 2010-12-23 05:08, Brendan Eich wrote:
You seem to have problem owning up to mistakes.
*I* have a problem owning up to mistakes?
https://secure.wikimedia.org/wikipedia/en/wiki/Psychological_projection
I'm sorry, that was uncalled for. I
On Thu, Dec 23, 2010 at 12:18 AM, Brendan Eich bren...@mozilla.com wrote:
On Dec 22, 2010, at 11:58 PM, Mark S. Miller wrote:
On Wed, Dec 22, 2010 at 11:44 PM, Brendan Eich bren...@mozilla.comwrote:
On Dec 22, 2010, at 11:34 PM, Mark S. Miller wrote:
Brendan, I still do not understand why
On Dec 23, 2010, at 8:36 AM, thaddee yann tyl wrote:
I understand that the number sign gets really heavy and annoying after
some time. As a result, I suggest a simpler syntax, private
.secret;:
a = {};
k = {a: a};
a['k'] = k;
function aa(o) {
private .a;
k..a = o; // or: private
On 2010-12-23 13:53, Kevin Smith wrote:
If I might ask a side-question: what's the value in making an object
non-extensible in ES5? I understand the value of making properties
non-configurable or non-writable, but I don't yet see a reason to prevent
extensions.
Suppose that the object
On Dec 23, 2010, at 10:17 AM, Mark S. Miller wrote:
It seems you agree enough to be exploring @ instead of ., which could desugar
to transposed .get or .set. So perhaps more new syntax will help, rather than
less new syntax and too much overloading of old.
Rather than more or less, I was
On 23.12.2010 22:39, Brendan Eich wrote:
On Dec 23, 2010, at 8:36 AM, thaddee yann tyl wrote:
I understand that the number sign gets really heavy and annoying after
some time. As a result, I suggest a simpler syntax, private
.secret;:
a = {};
k = {a: a};
a['k'] = k;
function aa(o) {
private
On 2010-12-23 16:36, thaddee yann tyl wrote:
The private names proposal has a lot of good ideas, but their use is
not obvious.
The reasons I see for that are:
The private a; declaration:
* changes meaning of all obj.a in scope
* looks like a scoped variable, not a private element of an
On 23.12.2010 22:39, Brendan Eich wrote:
The .. is wanted by other extensions, and already used by ECMA-357 (E4X), FWIW.
JFTR: and also in ECMA-262:
1..toString()
Dmitry.
___
es-discuss mailing list
es-discuss@mozilla.org
On Thu, Dec 23, 2010 at 11:49 AM, Brendan Eich bren...@mozilla.com wrote:
On Dec 23, 2010, at 10:17 AM, Mark S. Miller wrote:
It seems you agree enough to be exploring @ instead of ., which could
desugar to transposed .get or .set. So perhaps more new syntax will help,
rather than less new
On Dec 23, 2010, at 11:59 AM, Dmitry A. Soshnikov wrote:
On 23.12.2010 22:39, Brendan Eich wrote:
The .. is wanted by other extensions, and already used by ECMA-357 (E4X),
FWIW.
JFTR: and also in ECMA-262:
1..toString()
Yes, although if we added any .. as in Ruby or CoffeeScript it
You've said this apples to oranges thing many times. I just don't get it.
My comparisons at
http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields show
that these two semantics address extremely overlapping use cases. For both to
be in the language, with one group (including
On 2010-12-23 20:44, Brendan Eich wrote:
On Dec 23, 2010, at 11:59 AM, Dmitry A. Soshnikov wrote:
On 23.12.2010 22:39, Brendan Eich wrote:
The .. is wanted by other extensions, and already used by ECMA-357
(E4X), FWIW.
JFTR: and also in ECMA-262:
1..toString()
Yes, although if we
On Dec 23, 2010, at 8:36 AM, thaddee yann tyl wrote:
The private names proposal has a lot of good ideas, but their use is
not obvious.
The reasons I see for that are:
The private a; declaration:
* changes meaning of all obj.a in scope
* looks like a scoped variable, not a private element
On 2010-12-23 21:02, Brendan Eich wrote:
On Dec 23, 2010, at 12:11 PM, Mark S. Miller wrote:
You've said this apples to oranges thing many times. I just don't get it.
You've read the recent messages where it became clear only [], not the .
operator,
was ever mooted for soft fields on the
On Dec 23, 2010, at 12:11 PM, Mark S. Miller wrote:
You've said this apples to oranges thing many times. I just don't get it.
My comparisons at
http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields show
that these two semantics address extremely overlapping use cases. For
On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote:
We don't know whether [] will be changed
at all. (In the proposal to add a @ or .# operator, it isn't.)
Hm, this looks like a pretty serious misunderstanding of the private names
proposal. In every variant of the proposal, the object
On 2010-12-23 23:51, Allen Wirfs-Brock wrote:
I believe that your camp wants to think of soft fields, stored in a
side-table, as extensions of an object. My camp thinks of such
side-tables as a means of recording information about an object without
actually extending the object.
These are
As a question how do soft fields/private names interact with an object that has
had preventExtensions called on it?
Are they entirely independent of normal property rules?
--Oliver
On Dec 23, 2010, at 3:57 PM, David-Sarah Hopwood wrote:
On 2010-12-23 23:51, Allen Wirfs-Brock wrote:
I
On 2010-12-23 23:55, David Herman wrote:
On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote:
We don't know whether [] will be changed
at all. (In the proposal to add a @ or .# operator, it isn't.)
Hm, this looks like a pretty serious misunderstanding of the private names
proposal.
I
On Dec 23, 2010, at 5:03 PM, David-Sarah Hopwood wrote:
On 2010-12-23 23:55, David Herman wrote:
On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote:
We don't know whether [] will be changed
at all. (In the proposal to add a @ or .# operator, it isn't.)
Hm, this looks like a pretty
I just spent significant time trying to clarify why it does matter, at least to
some of us. In addition, I started with a quote from MarkM concerning an
observable semantic difference.
Finally, I don't recall mentioning you in anyway nor directing that message to
you other than as a cc via
On 2010-12-24 00:02, Oliver Hunt wrote:
As a question how do soft fields/private names interact with an object
that has had preventExtensions called on it?
For soft fields: there is no interaction, a new soft field can be added
to an object on which preventExtensions has been called.
For
On Dec 23, 2010, at 3:27 PM, David-Sarah Hopwood wrote:
On 2010-12-23 21:02, Brendan Eich wrote:
On Dec 23, 2010, at 12:11 PM, Mark S. Miller wrote:
You've said this apples to oranges thing many times. I just don't get it.
You've read the recent messages where it became clear only [], not
On 2010-12-24 00:11, David Herman wrote:
On Dec 23, 2010, at 5:03 PM, David-Sarah Hopwood wrote:
On 2010-12-23 23:55, David Herman wrote:
On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote:
We don't know whether [] will be changed at all. (In the proposal to
add a @ or .# operator, it
On 2010-12-24 00:39, Brendan Eich wrote:
On Dec 23, 2010, at 3:27 PM, David-Sarah Hopwood wrote:
On 2010-12-23 21:02, Brendan Eich wrote:
On Dec 23, 2010, at 12:11 PM, Mark S. Miller wrote:
You've said this apples to oranges thing many times. I just don't
get it.
You've read the recent
On Thu, Dec 23, 2010 at 1:06 PM, David Herman dher...@mozilla.com wrote:
All we've asked is that we not assume prima facie that we must pick a
winner and stop all work on the other. That said, I don't think we should do
much design work on the list or in committee meetings. The champions
On Dec 23, 2010, at 5:17 PM, David-Sarah Hopwood wrote:
On 2010-12-24 00:39, Brendan Eich wrote:
Since the new page is a clone of Allen's private_names strawman, of course
it clones the private x examples and shows . and :-in-literal being
used.
It's not clear how this new page helps
On Dec 23, 2010, at 5:20 PM, Mark S. Miller wrote:
On Thu, Dec 23, 2010 at 1:06 PM, David Herman dher...@mozilla.com wrote:
All we've asked is that we not assume prima facie that we must pick a winner
and stop all work on the other. That said, I don't think we should do much
design work
Thanks Mark. This seems like a good place to leave this for now. I'm not going
to continue respobding on the thread with David-Sarah for now, because I really
need to get off the computer and join the family for the holidays over the next
few days, and I think it's past the point of diminishing
37 matches
Mail list logo
