: Mark S. Miller erig...@google.com
To: Dave Herman dher...@mozilla.com
Cc: David-Sarah Hopwood david-sa...@jacaranda.org, es-discuss@mozilla.org
Sent: Wed, 22 Dec 2010 23:56:46 -0800 (PST)
Subject: Re: New private names proposal
On Wed, Dec 22, 2010 at 11:30 PM, Dave Herman dher...@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.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 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
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 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 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
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 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
,
Dave
- Original Message -
From: Mark S. Miller erig...@google.com
To: David Herman dher...@mozilla.com
Cc: Brendan Eich bren...@mozilla.com, es-discuss@mozilla.org
Sent: Thu, 23 Dec 2010 17:20:21 -0800 (PST)
Subject: Re: New private names proposal
On Thu, Dec 23, 2010 at 1:06 PM, David
On 12/21/2010 11:58 PM, Brendan Eich wrote:
I'm not keen on adding # as a sigil for private names, but this is mostly because such
things are ugly, Perlish line noise. Under the explicit is better than
implicit philosophy, and in particular the desire to eliminate even a static
(compile-time
On Dec 21, 2010, at 10:41 PM, David-Sarah Hopwood wrote:
Again you seem to be confusing the inherited soft fields proposal with
the *separate* proposal on desugaring the private name syntax to inherited
soft fields.
I think I may have been misunderstanding what Mark was actually
On 12/22/2010 01:02 AM, David Herman wrote:
In order for this to work you have to abandon the idea of scoped private
identifiers. I say: make all private identifiers scoped to the compilation
unit.
This is the part of your suggestion that I don't like: it makes private identifiers too blunt
On Dec 22, 2010, at 2:00 AM, David Flanagan wrote:
On 12/22/2010 01:02 AM, David Herman wrote:
function Point(x, y) {
private #x, #y;
this.#x = x;
this.#y = y;
}
I keep seeing this basic constructor example. But isn't this the case that
Oliver raised
What about adding an attribute to properties that somehow
identify which classes (in the prototype chain for protected)
have access to the object? I'll leave the somehow up in the
air, but you could introduce a [[Private]] attribute which, if not
undefined, says which context must be set (and for
From my perspective as a JS programmer, overloading the dot seems confusing.
The gains in elegance don't appear to me to be worth it. However,
overloading [] might be more acceptable:
let x = new PrivateName();
// or perhaps:
private x;
function Point()
{
this[x] = 100;
}
function
On Dec 22, 2010, at 6:26 AM, David Herman wrote:
On Dec 22, 2010, at 2:00 AM, David Flanagan wrote:
On 12/22/2010 01:02 AM, David Herman wrote:
function Point(x, y) {
private #x, #y;
this.#x = x;
this.#y = y;
}
I keep seeing this basic constructor
I think there are some interesting ideas to explore in both D. Flanagan's
proposal and D. Herman's variations upon it. However, they both seem to be
ignoring the second primary use case that I identified: conflict-free
extensions of build-in or third party objects. While naming conventions or
On Dec 22, 2010, at 9:47 AM, Brendan Eich wrote:
I'm still sympathetic to Oliver's objection that declaration-style private
#x, #y does not look generative enough. Agree that the sigil addresses
Mark's concern about confusing literal identifiers with lexically bound
names, at a Perlish
On Dec 22, 2010, at 10:07 AM, Allen Wirfs-Brock wrote:
I don't see why
private foo;
is any more or less generative than:
var captured;
or
function inner() {};
They are all are declarative forms and all implicitly generate new runtime
entities each time they are evaluated.
The
On Dec 21, 2010, at 11:58 PM, Brendan Eich wrote:
... which is strictly weaker, more complex, and less explanatory.
So is a transposed get from an inherited soft field. Soft fields change the
way square brackets work in JS, for Pete's sake!
They do not.
Ok, then I'm arguing with
On Dec 22, 2010, at 8:50 AM, Kevin Smith wrote:
From my perspective as a JS programmer, overloading the dot seems confusing.
The gains in elegance don't appear to me to be worth it. However,
overloading [] might be more acceptable:
[] gets no respect, I tell ya! ;-)
let x = new
On 12/22/2010 09:57 AM, Allen Wirfs-Brock wrote:
I think there are some interesting ideas to explore in both D.
Flanagan's proposal and D. Herman's variations upon it. However, they
both seem to be ignoring the second primary use case that I identified:
conflict-free extensions of build-in or
I think there are some interesting ideas to explore in both D. Flanagan's
proposal and D. Herman's variations upon it. However, they both seem to be
ignoring the second primary use case that I identified: conflict-free
extensions of build-in or third party objects. While naming
More musings: the current proposal allows this form where the generation
of the private name is explicit:
private x = new Name();
What if the silently generative form were not allowed? That would make
the mapping of identifiers more explicit.
And if so, could we replace = with a
On Tue, Dec 21, 2010 at 2:44 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Please don't totally disengage from the syntax discussion. Most
programmers understanding of the language starts with the concrete (syntax)
and then proceeds to the abstract (semantics). Syntax design can have
Hi David,
First of all, I think you may not be reading the current private names
proposal. Allen wanted to change the name so he created a new page:
http://wiki.ecmascript.org/doku.php?id=strawman:private_names
Part of what you're reacting against is in fact what he changed (more below).
On Dec 22, 2010, at 7:10 AM, Peter van der Zee wrote:
What about adding an attribute to properties that somehow identify which
classes (in the prototype chain for protected) have access to the object?
I'll leave the somehow up in the air, but you could introduce a [[Private]]
attribute
On Wed, Dec 22, 2010 at 11:56 AM, Mark S. Miller erig...@google.com wrote:
On Tue, Dec 21, 2010 at 2:44 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Please don't totally disengage from the syntax discussion. Most
programmers understanding of the language starts with the concrete
On Dec 22, 2010, at 7:10 AM, Peter van der Zee wrote:
What about adding an attribute to properties that somehow
identify which classes (in the prototype chain for protected)
have access to the object? I'll leave the somehow up in the
air, but you could introduce a [[Private]] attribute
On Dec 22, 2010, at 11:12 AM, David Flanagan wrote:
've now realized that I don't actually object so much to the generative
nature of private. What bugs me is that it essentially declares a
meta-identifier that is then used as if it were a regular identifier. It is
the meta-mismatch that
On Dec 22, 2010, at 12:45 PM, Peter van der Zee wrote:
IMO, this is too class-oriented for JS. We should allow the
creation of private members of arbitrary objects, not just those
that inherit from new constructors. I think it also doesn't address
the use case of adding new operations to
On 2010-12-22 07:57, Brendan Eich wrote:
On Dec 21, 2010, at 10:22 PM, David-Sarah Hopwood wrote:
On 2010-12-21 22:12, Brendan Eich wrote:
It's tiresome to argue by special pleading that one extension or
transformation (including generated symbols) is more complex, and
less explanatory,
On 2010-12-22 18:59, Brendan Eich wrote:
On Dec 21, 2010, at 11:58 PM, Brendan Eich wrote:
... which is strictly weaker, more complex, and less explanatory.
So is a transposed get from an inherited soft field. Soft fields
change the way square brackets work in JS, for Pete's sake!
They
On Dec 22, 2010, at 2:56 PM, David-Sarah Hopwood wrote:
What I said, paraphrasing, is that weak encapsulation favours code that
doesn't work reliably in cases where the encapsulation is bypassed. Also,
that if the encapsulation is never bypassed then it didn't need to be weak.
What's wrong
On Dec 22, 2010, at 3:49 PM, David-Sarah Hopwood wrote:
In arguing about this, I have this bait-and-switch sense that I'm being
told A+B, then when I argue in reply against B, I'm told no, no! only A!.
(Cheat sheet: A is soft fields, B is transposed square bracket syntax for
them.)
This
On 2010-12-23 00:40, Brendan Eich wrote:
On Dec 22, 2010, at 2:56 PM, David-Sarah Hopwood wrote:
What I said, paraphrasing, is that weak encapsulation favours code that
doesn't work reliably in cases where the encapsulation is bypassed.
Also, that if the encapsulation is never bypassed then
On Dec 22, 2010, at 6:39 PM, David-Sarah Hopwood wrote:
Inspectors can bypass encapsulation regardless of the language spec.
The Inspector is written in ES5. How does it bypass soft field strong
encapsulation?
As for the ability to manipulate all properties of objects at a meta
level using
On 2010-12-23 01:11, Brendan Eich wrote:
On Dec 22, 2010, at 3:49 PM, David-Sarah Hopwood wrote:
In arguing about this, I have this bait-and-switch sense that I'm
being told A+B, then when I argue in reply against B, I'm told no, no!
only A!. (Cheat sheet: A is soft fields, B is transposed
On 2010-12-23 02:48, Brendan Eich wrote:
On Dec 22, 2010, at 6:39 PM, David-Sarah Hopwood wrote:
Inspectors can bypass encapsulation regardless of the language spec.
The Inspector is written in ES5. How does it bypass soft field strong
encapsulation?
I meant, obviously, that inspectors
On Dec 22, 2010, at 7:34 PM, David-Sarah Hopwood wrote:
As far as I can see, MarkM has not (at least, not on the wiki) proposed
any new syntax in this discussion that had not already been proposed in
one of Allen's proposals.
Wrong again. Allen did not write the original strawman:names
On Dec 22, 2010, at 7:49 PM, David-Sarah Hopwood wrote:
On 2010-12-23 02:48, Brendan Eich wrote:
On Dec 22, 2010, at 6:39 PM, David-Sarah Hopwood wrote:
Inspectors can bypass encapsulation regardless of the language spec.
The Inspector is written in ES5. How does it bypass soft field
On 2010-12-23 05:14, Brendan Eich wrote:
On Dec 22, 2010, at 7:49 PM, David-Sarah Hopwood wrote:
The constraint that the inspector be written in ES5 seems to be a purely
artificial one. All of the commonly used browsers have debugger extensions.
Nope, our little startup (mine, MonkeyBob's,
On Dec 22, 2010, at 9:31 PM, David-Sarah Hopwood wrote:
On 2010-12-23 05:14, Brendan Eich wrote:
On Dec 22, 2010, at 7:49 PM, David-Sarah Hopwood wrote:
The constraint that the inspector be written in ES5 seems to be a purely
artificial one. All of the commonly used browsers have debugger
On 2010-12-23 05:08, Brendan Eich wrote:
On Dec 22, 2010, at 7:34 PM, David-Sarah Hopwood wrote:
As far as I can see, MarkM has not (at least, not on the wiki) proposed
any new syntax in this discussion that had not already been proposed in
one of Allen's proposals.
Wrong again. Allen did
see my message
about this earlier in the thread?
Dave
- Original Message -
From: David-Sarah Hopwood david-sa...@jacaranda.org
To: es-discuss@mozilla.org
Sent: Wed, 22 Dec 2010 22:01:39 -0800 (PST)
Subject: Re: New private names proposal
On 2010-12-23 05:08, Brendan Eich wrote:
On Dec 22
I would like to encourage everyone to stop arguing about whether my old
syntax at
http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names
was or was not a faithful adaptation of the old names syntax at
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 as alternatives. Do you really think
we should provide syntactic support for both?
The discussion here, including Dave's point
On Wed, Dec 22, 2010 at 11:30 PM, Dave Herman dher...@mozilla.com wrote:
MarkM's desugaring doesn't look correct to me at all. Given that names can
always be looked up in objects, regardless of whether they are bound with
'private', it is not amenable to simulation via local desugaring. You'd
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 as alternatives. Do you really think
we should provide
On Thu, 16 Dec 2010 23:19:12 +0100, Mark S. Miller erig...@google.com
wrote:
On Thu, Dec 16, 2010 at 1:58 PM, Kris Kowal kris.ko...@cixar.com wrote:
On Thu, Dec 16, 2010 at 1:53 PM, David Herman dher...@mozilla.com
wrote:
function Point(x, y) {
private x, y;
this.x =
On 2010-12-21 08:49, Lasse Reichstein wrote:
On Thu, 16 Dec 2010 23:19:12 +0100, Mark S. Miller erig...@google.com wrote:
On Thu, Dec 16, 2010 at 1:58 PM, Kris Kowal kris.ko...@cixar.com wrote:
On Thu, Dec 16, 2010 at 1:53 PM, David Herman dher...@mozilla.com wrote:
[...]
than
On Dec 20, 2010, at 11:05 PM, David-Sarah Hopwood wrote:
The new equivalence under private names would be x[#.id] === x.id.
... which is strictly weaker, more complex, and less explanatory.
So is a transposed get from an inherited soft field. Soft fields change the way
square brackets work
Just giving my feedback to this (so it's recorded somewhere other than my head).
I find the apparent necessity of conflating syntax and semantics irksome, i'd
much rather that there be two distinct discussions one of syntax and the other
for semantics of soft-fields, private names, gremlins,
On Dec 21, 2010, at 4:01 PM, Oliver Hunt wrote:
Just giving my feedback to this (so it's recorded somewhere other than my
head).
I find the apparent necessity of conflating syntax and semantics irksome, i'd
much rather that there be two distinct discussions one of syntax and the
other
On Dec 21, 2010, at 4:25 PM, Brendan Eich wrote:
On Dec 21, 2010, at 4:01 PM, Oliver Hunt wrote:
Just giving my feedback to this (so it's recorded somewhere other than my
head).
I find the apparent necessity of conflating syntax and semantics irksome,
i'd much rather that there be two
On Dec 21, 2010, at 4:51 PM, Oliver Hunt wrote:
But what is an array index, then? uint32 is not a type in the language.
Would proxy[3.14] really pass a double through?
Yes, I would expect no coercion of any non-object. The reason for
disallowing objects is safety afaik, those arguments
On Dec 21, 2010, at 5:00 PM, Brendan Eich wrote:
On Dec 21, 2010, at 4:51 PM, Oliver Hunt wrote:
But what is an array index, then? uint32 is not a type in the language.
Would proxy[3.14] really pass a double through?
Yes, I would expect no coercion of any non-object. The reason for
On 12/21/2010 04:25 PM, Brendan Eich wrote:
Why does your expectation differ here compared to the following:
MyAwesomeThing.prototype.myCoolFunction = function() {
var cachedHotness = gensym();
if (!this[cachedHotness])
this[cachedHotness] = doExpensiveThing(this)
return this[cachedHotness];
}
On Dec 21, 2010, at 5:09 PM, Oliver Hunt wrote:
On Dec 21, 2010, at 5:00 PM, Brendan Eich wrote:
On Dec 21, 2010, at 4:51 PM, Oliver Hunt wrote:
But what is an array index, then? uint32 is not a type in the language.
Would proxy[3.14] really pass a double through?
Yes, I would expect no
On Dec 21, 2010, at 5:13 PM, David Flanagan wrote:
On 12/21/2010 04:25 PM, Brendan Eich wrote:
Why does your expectation differ here compared to the following:
MyAwesomeThing.prototype.myCoolFunction = function() {
var cachedHotness = gensym();
if (!this[cachedHotness])
On Dec 21, 2010, at 5:57 PM, Brendan Eich wrote:
A use directive feels vaguely more comfortable here to me. It makes it
clearer to the programmer that some kind of magic is going on.
But I confess that I haven't actually read Allen's proposal, so take this
with a grain of salt.
On Dec 21, 2010, at 4:01 PM, Oliver Hunt wrote:
function MyAwesomeThing() {
}
MyAwesomeThing.prototype.myCoolFunction = function() {
if (!this._myCachedHotness)
this._myCachedHotness = doExpensiveThing(this)
return this._myCachedHotness;
}
I see this nifty
On Dec 21, 2010, at 2:12 PM, Brendan Eich wrote:
I also see the ocap purity of soft fields, and I like Mark's
AST-decorated-sparsely soft fields use-case. But we already have weak maps in
harmony:proposals, so one can write such code now, just at some loss of
convenience: without square
On Dec 21, 2010, at 8:17 PM, Allen Wirfs-Brock wrote:
However, why would you bother freezing your AST nodes in the first place.
JavaScript has a great mechanism for soft fields -- it's called properties.
You can even make your base properties non-configurable if you want to. But
why
On Dec 21, 2010, at 9:38 PM, Brendan Eich wrote:
On Dec 21, 2010, at 8:17 PM, Allen Wirfs-Brock wrote:
However, why would you bother freezing your AST nodes in the first place.
JavaScript has a great mechanism for soft fields -- it's called
properties. You can even make your base
On Dec 21, 2010, at 10:14 PM, Brendan Eich wrote:
On Dec 21, 2010, at 10:03 PM, Alex Russell wrote:
This is not a relevant fear in my view. It's also kind of silly given all
the open source JS libraries. If someone did over-freeze, you could stop
using their library, or fork and fix it.
On Dec 21, 2010, at 10:17 PM, Alex Russell wrote:
On Dec 21, 2010, at 10:14 PM, Brendan Eich wrote:
I fear APIs that freeze, only take frozen objects or only have versions that
do, or are so mutability-hostile that they warp our use of the language
toward frozen-by-default constructs.
On 2010-12-21 22:12, Brendan Eich wrote:
On Dec 20, 2010, at 11:05 PM, David-Sarah Hopwood wrote:
Please retain all relevant attribution lines.
Brendan Eich wrote:
The new equivalence under private names would be x[#.id] === x.id.
You said under private names here, but it should actually be
[Resending as you did to the right group, although I filter both to the same
folder and prune dups. Whee! /be]
On Dec 21, 2010, at 10:22 PM, David-Sarah Hopwood wrote:
On 2010-12-21 22:12, Brendan Eich wrote:
On Dec 20, 2010, at 11:05 PM, David-Sarah Hopwood wrote:
Please retain all
On 2010-12-17 06:44, Brendan Eich wrote:
On Dec 16, 2010, at 9:11 PM, David-Sarah Hopwood wrote:
On 2010-12-17 01:24, David Herman wrote:
Mark Miller wrote:
Ok, I open it for discussion. Given soft fields, why do we need private
names?
I believe that the syntax is a big part of the private
Let me make a gentle plea for not creating unnecessary controversy. Take a step
back: we all seem to agree we would like to provide a more convenient and
performant way to create private fields in objects. In terms of observable
behavior in the runtime model, there aren't that many differences
On Fri, Dec 17, 2010 at 10:06 AM, David Herman dher...@mozilla.com wrote:
Let me make a gentle plea for not creating unnecessary controversy. Take a
step back: we all seem to agree we would like to provide a more convenient
and performant way to create private fields in objects.
Yes. We
On Dec 16, 2010, at 9:11 PM, David-Sarah Hopwood wrote:
I don't like the private names syntax. I think it obscures more than it
helps usability, and losing the x[id] === x.id equivalence is a significant
loss.
Again, this equivalence has never held in JS for all possible characters in a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This sounds great, but doesn't this kind of violate referential
transparency? The following function has always worked as expected:
function foo(){
var obj = {bar:hello}; // assuming quoting names are strings
alert(obj.bar);
}
foo();
until is
This sounds great, but doesn't this kind of violate referential
transparency?
That's a loaded criticism. JS doesn't have referential transparency in any
meaningful sense. But it does generalize the meaning of the dot-operator to be
sensitive to scoping operators, that's true.
Couldn't the
On Thu, Dec 16, 2010 at 1:53 PM, David Herman dher...@mozilla.com wrote:
function Point(x, y) {
private x, y;
this.x = x;
this.y = y;
...
}
than
function Point(x, y) {
var _x = gensym(), _y = gensym();
this[_x] = x;
this[_y] =
On Thu, Dec 16, 2010 at 1:58 PM, Kris Kowal kris.ko...@cixar.com wrote:
On Thu, Dec 16, 2010 at 1:53 PM, David Herman dher...@mozilla.com wrote:
function Point(x, y) {
private x, y;
this.x = x;
this.y = y;
...
}
than
function Point(x, y)
Subject: Re: New private names proposal
On Thu, Dec 16, 2010 at 1:58 PM, Kris Kowal
kris.ko...@cixar.commailto:kris.ko...@cixar.com wrote:
On Thu, Dec 16, 2010 at 1:53 PM, David Herman
dher...@mozilla.commailto:dher...@mozilla.com wrote:
function Point(x, y) {
private x, y
On Dec 16, 2010, at 2:19 PM, Mark S. Miller wrote:
Currently is JS, x['foo'] and x.foo are precisely identical in all contexts.
This regularity helps understandability. The terseness difference above is
not an adequate reason to sacrifice it.
Aren't you proposing the same syntax x[i] where
On Thu, Dec 16, 2010 at 3:23 PM, Brendan Eich bren...@mozilla.com wrote:
On Dec 16, 2010, at 2:19 PM, Mark S. Miller wrote:
Currently is JS, x['foo'] and x.foo are precisely identical in all
contexts. This regularity helps understandability. The terseness difference
above is not an adequate
Without new syntax, isn't soft fields just a library on top of weak maps?
Dave
On Dec 16, 2010, at 3:47 PM, Mark S. Miller wrote:
On Thu, Dec 16, 2010 at 3:23 PM, Brendan Eich bren...@mozilla.com wrote:
On Dec 16, 2010, at 2:19 PM, Mark S. Miller wrote:
Currently is JS, x['foo'] and
On Thu, Dec 16, 2010 at 3:51 PM, David Herman dher...@mozilla.com wrote:
Without new syntax, isn't soft fields just a library on top of weak maps?
Semantically, yes. However, as a library, they cannot benefit from the
extraordinary efforts of all JavaScript engines to optimize inherited
1 - 100 of 113 matches
Mail list logo
