As a followup, Refinements are derivative of ClassBoxes which for several
year's was an area of focus within Oscar Nierstrasz's research group at the
University of Bern. http://scg.unibe.ch/research/classboxes/ They started with
Smalltalk and then went on to Java and C# implementations. They
From: Brendan Eich
Sent: 21 March 2011
On Mar 21, 2011, at 1:13 PM, Erik Arvidsson wrote:
The above use case cannot be solved using private names because
private names conflict with public names.
I don't see this, though. Don't oversell!
I think it's true: you can't do this with private
On Mar 21, 2011, at 11:50 PM, François REMY wrote:
From: Brendan Eich
Sent: 21 March 2011
On Mar 21, 2011, at 1:13 PM, Erik Arvidsson wrote:
The above use case cannot be solved using private names because
private names conflict with public names.
I don't see this, though. Don't
Sure, but the problem (as people keep pointing out) has two solutions:
close the scope in which filfter binds to a private name, or use a
renaming private declaration.
It's not perfect but there's no absolute inability to call public filter
and private filter.
Adding filter to the Object
On Mar 21, 2011, at 9:40 PM, Brendan Eich bren...@mozilla.com wrote:
On Mar 21, 2011, at 6:17 PM, Allen Wirfs-Brock wrote:
On Mar 21, 2011, at 5:55 PM, Waldemar Horwat wrote:
You'd still run into all of the issues caused by private filter behaving
like a C++ #define.
#define
On Mar 22, 2011, at 1:28 AM, Kam Kasravi wrote:
Does this matter? In Java it matters much less because of types. In JS, it
matters more but an IDE could still help (as in Java, but without types --
just lexical use-to-def connection-making by the IDE).
There would be several private names
I think a more precise statement is you can't do this with private names alone.
As the classbox work explains, you also have to have a modified property lookup
algorithm that takes into account that a [[Get]] may be satisfied based upon
either the global or local key value associated with the
On Tue, Mar 22, 2011 at 00:21, David Herman dher...@mozilla.com wrote:
I wish you would make your proposal more precise; right now we have to infer
it from your single example. In my conversations with several others on the
committee, I'm already seeing lots of confusion about the semantics
On Tue, Mar 22, 2011 at 08:27, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I think a more precise statement is you can't do this with private names
alone.
As the classbox work explains, you also have to have a modified property
lookup algorithm that takes into account that a [[Get]] may
On Mar 21, 2011, at 12:50 AM, Allen Wirfs-Brock wrote:
On Mar 20, 2011, at 9:58 PM, Andrew Dupont wrote:
The revision would address all my concerns — thanks. I'm all for
distinguishing the static case from the dynamic case, as long as we can
maintain the separation between public names
On Mar 20, 2011, at 11:30 PM, Andrew Dupont wrote:
Java doesn't formalize this, you're right — but if I'm looking at
`this.doSomething()` and wondering about its visibility, I can look in the
class definition itself (to see if it's private) or in one of its
superclasses (to see if it's
right now, bracket notation is a superset of dot notation, but it would no
longer be under the proposed syntax.
I'm afraid I can't figure out what this means, but it doesn't sound true to
me.
Right now, everything that can be expressed via dot notation has an analog in
bracket
Brendan and Irakli both beat me to the punch here -- I would really like to see
stronger evidence that an entire lexical scope is really so onerous.
Everything you say about how Java mitigates the problem is just as applicable
to Harmony.
Java doesn't formalize this, you're right — but if I'm
On Mar 21, 2011, at 11:14 AM, Brendan Eich wrote:
Hi Andrew, thanks for the good thinking on this thread. I'm not
cherry-picking here, but I wanted to reply to the specific sentence ending
entire lexical scope.
The Harmony top-level scope (no global object!) will be big and it may even
On Mar 21, 2011, at 11:29 AM, Andrew Dupont wrote:
On Mar 21, 2011, at 11:14 AM, Brendan Eich wrote:
Hi Andrew, thanks for the good thinking on this thread. I'm not
cherry-picking here, but I wanted to reply to the specific sentence ending
entire lexical scope.
The Harmony top-level
The thread about using private names is getting a bit unwieldy but I'd
like to focus on the use case that I have been thinking of as
Lexically scoped monkey patching or Lexically scoped object
extensions instead of focusing on how to use private names to fit
this scenario.
Extending built ins
On Mon, Mar 21, 2011 at 19:29, Andrew Dupont mozi...@andrewdupont.netwrote:
On Mar 21, 2011, at 11:14 AM, Brendan Eich wrote:
Hi Andrew, thanks for the good thinking on this thread. I'm not
cherry-picking here, but I wanted to reply to the specific sentence ending
entire lexical scope.
Erik,
Yes, this is exactly what a framework like Prototype would need. Your code is
highly reminiscent of Ruby's proposed refinements feature [1], one which is
being debated for inclusion in Ruby 2.0. If this could be implemented in a way
that avoids the dreaded namespace dragons, then I would
On 03/21/11 13:13, Erik Arvidsson wrote:
The thread about using private names is getting a bit unwieldy but I'd
like to focus on the use case that I have been thinking of as
Lexically scoped monkey patching or Lexically scoped object
extensions instead of focusing on how to use private names to
On Mon, Mar 21, 2011 at 16:45, Waldemar Horwat walde...@google.com wrote:
On 03/21/11 13:13, Erik Arvidsson wrote:
The thread about using private names is getting a bit unwieldy but I'd
like to focus on the use case that I have been thinking of as
Lexically scoped monkey patching or
On Mar 21, 2011, at 1:13 PM, Erik Arvidsson wrote:
The above use case cannot be solved using private names because
private names conflict with public names.
Erik, I'm not sure that my understanding of the intended semantics of your
extension statement is totally correct. But given what I
On 03/21/11 17:42, Allen Wirfs-Brock wrote:
On Mar 21, 2011, at 1:13 PM, Erik Arvidsson wrote:
The above use case cannot be solved using private names because
private names conflict with public names.
Erik, I'm not sure that my understanding of the intended semantics of your
extension
On Mar 21, 2011, at 5:55 PM, Waldemar Horwat wrote:
You'd still run into all of the issues caused by private filter behaving
like a C++ #define. For example:
var foo = {filter: 34};
then pass foo to an outside client.
Trying to interpret your comment. Are you saying that the above
Hey Allen,
The use case runs something like this:
Suppose you use a collection library which has 'filter' implemented on all
of their collections. So we have Set.prototype.filter, Map.prototype.filter,
Tree.prototype.filter, etc. But the library doesn't add Array.filter because
monkey patching
On Mar 21, 2011, at 6:17 PM, Allen Wirfs-Brock wrote:
On Mar 21, 2011, at 5:55 PM, Waldemar Horwat wrote:
You'd still run into all of the issues caused by private filter behaving
like a C++ #define.
#define exagerrates.
For example:
var foo = {filter: 34};
then pass foo to an
On Mar 21, 2011, at 1:13 PM, Erik Arvidsson wrote:
{
extend Object.prototype with {
filter: function(fun) {
var retval = {};
for (var key in this) {
if (fun(this[key])
retval[key] = this[key];
}
return retval;
}
};
function largerThanN(obj, n) {
return
Tobin-Hochstadt wrote:
You're correct -- this won't do what you probably intended. But the
great thing about private names is that this is a problem you can
*locally* fix. For example:
private myClone = installCloneLibrary();
var twin = [{a:0}, {b:1}].myClone();
var thing = MyObj.clone
[snip]
Anyway, now that I've confirmed my suspicions, I'm hesitant about the
private names proposal as described. The fact that declaring a certain name
as private affects _all_ property name lookups in that scope (all lookups
that use the dot operator or object literal syntax, at
Oops mind fart:
Make that obj.foo===obj[0]
The point is that what follows the dot ia already evaluated differently than
what comes between brackets
Dean Landolt d...@deanlandolt.com wrote:
[snip]
Anyway, now that I've confirmed my suspicions, I'm hesitant about the
private names
On Mar 20, 2011, at 12:22 PM, Allen Wirfs-Brock wrote:
Oops mind fart:
Make that obj.foo===obj[0]
The point is that what follows the dot ia already evaluated differently than
what comes between brackets
Right; I think Dean and I are saying that this would be the first time obj.foo
On Mar 20, 2011, at 10:55 AM, Andrew Dupont wrote:
Right; I think Dean and I are saying that this would be the first time
obj.foo meant something different from obj['foo']. And to ascertain that
those two meant different things, I'd have to go searching through the code
for a `private foo`
OK, you lost me.
On Mar 20, 2011, at 2:36 PM, Allen Wirfs-Brock wrote:
On Mar 20, 2011, at 10:55 AM, Andrew Dupont wrote:
Right; I think Dean and I are saying that this would be the first time
obj.foo meant something different from obj['foo']. And to ascertain that
those two meant
On Sun, Mar 20, 2011 at 3:36 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Mar 20, 2011, at 10:55 AM, Andrew Dupont wrote:
Right; I think Dean and I are saying that this would be the first time
obj.foo meant something different from obj['foo']. And to ascertain that
those two meant
On Sun, Mar 20, 2011 at 3:49 PM, Andrew Dupont mozi...@andrewdupont.net wrote:
BTW, if you know that a property name is foo, why would you ever code
obj[foo] instead of obj.foo?
The proposal strongly implies that the `private` declaration affects only a
property name on the right of . or
to be known at
compilation time).
Any thought on this ?
Regards,
François
From: Andrew Dupont
Sent: Sunday, March 20, 2011 6:54 AM
To: Sam Tobin-Hochstadt
Cc: es-discuss@mozilla.org
Subject: Re: About private names
On Mar 19, 2011, at 7:02 PM, Sam Tobin-Hochstadt wrote:
You're correct
On Mar 20, 2011, at 12:49 PM, Andrew Dupont wrote:
OK, you lost me.
On Mar 20, 2011, at 2:36 PM, Allen Wirfs-Brock wrote:
On Mar 20, 2011, at 10:55 AM, Andrew Dupont wrote:
Right; I think Dean and I are saying that this would be the first time
obj.foo meant something different from
BTW, if you know that a property name is foo, why would you ever code
obj[foo] instead of obj.foo?
The most obvious reason is if the name of the property contains a character
which cannot be an identifier character in the property name... like a
unicode character, for instance.
Without
On Sun, Mar 20, 2011 at 6:21 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Mar 20, 2011, at 12:49 PM, Andrew Dupont wrote:
OK, you lost me.
On Mar 20, 2011, at 2:36 PM, Allen Wirfs-Brock wrote:
On Mar 20, 2011, at 10:55 AM, Andrew Dupont wrote:
Right; I think Dean and I are
On Mar 20, 2011 3:34 PM, Kyle Simpson get...@gmail.com wrote:
BTW, if you know that a property name is foo, why would you ever code
obj[foo] instead of obj.foo?
The most obvious reason is if the name of the property contains a
character which cannot be an identifier character in the property
On Mar 20, 2011, at 4:20 PM, Dean Landolt wrote:
[big top-cite snipped -- folks, please try to cut if you can.]
I think you're missing the distinction. The obj[foo] example is just a
stand-in for `var foo=foo; obj[foo]` -- we would all expect the string key
lookup to be the same as obj.foo,
On Mar 20, 2011, at 4:20 PM, Dean Landolt wrote:
I think you're missing the distinction. The obj[foo] example is just a
stand-in for `var foo=foo; obj[foo]` -- we would all expect the string key
lookup to be the same as obj.foo, and anything less would be a bit
surprising. This is what
First of all, let me be clear: my objections are only as deep as the syntax
layer. I'm not arguing against the usefulness of private names as a concept.
On Mar 20, 2011, at 6:51 PM, Brendan Eich wrote:
I encourage folks to read the private names thread from late last year, since
we are
right now, bracket notation is a superset of dot notation, but it would no
longer be under the proposed syntax.
I'm afraid I can't figure out what this means, but it doesn't sound true to me.
This gets at my other objection. Code is far harder to debug when every
single property lookup
On Mar 20, 2011, at 11:05 PM, David Herman wrote:
right now, bracket notation is a superset of dot notation, but it would no
longer be under the proposed syntax.
I'm afraid I can't figure out what this means, but it doesn't sound true to
me.
I noticed (in both this thread and the
On Mar 20, 2011, at 9:58 PM, Andrew Dupont wrote:
The revision would address all my concerns — thanks. I'm all for
distinguishing the static case from the dynamic case, as long as we can
maintain the separation between public names and private names, and know
which is which without
The recent mention of the private names strawman [1] in the Standardizing
__proto__ thread led me to re-read the proposal. After staring at it for far
too long, I had the aha! moment, but it left me with a question.
The Conflict-Free Object Extension Using Private Names section includes a
code
, it won't.)
You're correct -- this won't do what you probably intended. But the
great thing about private names is that this is a problem you can
*locally* fix. For example:
private myClone = installCloneLibrary();
var twin = [{a:0}, {b:1}].myClone();
var thing = MyObj.clone();
or
var
On Mar 19, 2011, at 7:02 PM, Sam Tobin-Hochstadt wrote:
You're correct -- this won't do what you probably intended. But the
great thing about private names is that this is a problem you can
*locally* fix. For example:
private myClone = installCloneLibrary();
var twin = [{a:0}, {b:1
48 matches
Mail list logo
