Le 17/10/2011 03:29, Andreas Gal a écrit :
(...)
Fixing this just for proxies by stratifying toString, valueOf seems
undesirable. We would grant extra powers to proxies, and suddenly this
following two ways to invoke toString would produce different results
(potentially):
Le 17/10/2011 07:19, David Herman a écrit :
I agree with Andreas. The implicitly-called base level methods are not meta-methods or
(spec language) internal methods. They do not need their own traps. They are
base-level property accesses.
Well, certainly that's the way the language currently
I think we should just forget about new keyword, prototype property all
togather and move towards something more simple:
var proto = {
method: function() { },
new: function() {
var self = Object.create(this);
this.initialize.apply(self, arguments);
return self;
},
I do the same with
Object.prototype.new = function () {
var o = Object.create(this);
o.constructor o.constructor.apply(o, arguments);
return o;
}
However rather then calling proto.new(); I would like var o = new proto();
and o instanceof proto to work
On Oct 17, 2011 9:17 AM, Irakli
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)
On Monday, 2011-10-17 at 11:16 , Jake Verbaten wrote:
I do the same with
Object.prototype.new = function () {
var o = Object.create(this);
[cc-ing es-discuss]
On Oct 17, 2011, at 11:31 , Jake Verbaten wrote:
If we could find a way to mark methods as constructors (e.g. by prefixing an
@, but we are heading into Grawlix territory then), we could do the following:
var Point = {
@constructor(x, y) {
On Mon, Oct 17, 2011 at 11:19 AM, Axel Rauschmayer a...@rauschma.de wrote:
[cc-ing es-discuss]
On Oct 17, 2011, at 11:31 , Jake Verbaten wrote:
If we could find a way to mark methods as constructors (e.g. by prefixing
an @, but we are heading into Grawlix territory then), we could do the
Hi David,
So basically the argument for removing the receiver argument is simply that
according to ES5 semantics, the getPropertyDescriptor trap, not get /
set, should be called when proxies are encountered via prototype climbing
due to a [[Get]] or [[Put]]. If the pd returned by
Le 17/10/2011 15:21, Sean Eagan a écrit :
Hi David,
So basically the argument for removing the receiver argument is simply
that according to ES5 semantics, the getPropertyDescriptor trap, not
get / set, should be called when proxies are encountered via
prototype climbing due to a [[Get]] or
On Mon, Oct 17, 2011 at 1:19 AM, David Herman dher...@mozilla.com wrote:
I agree with Andreas. The implicitly-called base level methods are not
meta-methods or (spec language) internal methods. They do not need their
own traps. They are base-level property accesses.
Well, certainly that's
On Oct 16, 2011, at 4:05 PM, Axel Rauschmayer wrote:
From: Allen Wirfs-Brock al...@wirfs-brock.com
Not surprisingly, I like oExemplars. They almost look like class literals,
too.
I’m a bit skeptical about having two competing exemplars (more than one way
of achieving something leads
True.
Yes, but an important point I was trying to make is that we already have two
competing forms of exemplars (three, if you include forms using
Object.create). Class literals add yet another exemplar form.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home:
On Oct 17, 2011, at 12:43 AM, David Bruant wrote:
Le 17/10/2011 07:19, David Herman a écrit :
I agree with Andreas. The implicitly-called base level methods are not
meta-methods or (spec language) internal methods. They do not need their
own traps. They are base-level property accesses.
Le 17/10/2011 17:31, Brendan Eich a écrit :
On Oct 17, 2011, at 12:43 AM, David Bruant wrote:
Le 17/10/2011 07:19, David Herman a écrit :
I agree with Andreas. The implicitly-called base level methods are not meta-methods or
(spec language) internal methods. They do not need their own traps.
On Oct 16, 2011, at 12:51 PM, Axel Rauschmayer wrote:
From: Allen Wirfs-Brock al...@wirfs-brock.com
Subject: Re: new Object
Date: October 11, 2011 23:50:14 GMT+02:00
To: Jake Verbaten rayn...@gmail.com
Cc: es-discuss es-discuss@mozilla.org
It's still on my radar. Most recently see
On Oct 17, 2011, at 8:45 AM, David Bruant wrote:
Le 17/10/2011 17:31, Brendan Eich a écrit :
On Oct 17, 2011, at 12:43 AM, David Bruant wrote:
Le 17/10/2011 07:19, David Herman a écrit :
I agree with Andreas. The implicitly-called base level methods are not
meta-methods or (spec language)
On Oct 16, 2011, at 10:19 PM, David Herman wrote:
I agree with Andreas. The implicitly-called base level methods are not
meta-methods or (spec language) internal methods. They do not need their
own traps. They are base-level property accesses.
Well, certainly that's the way the language
On Oct 17, 2011, at 9:20 AM, Brendan Eich wrote:
Back to a Proxy defaultValue trap. It should be derived as you say. It
imposes no overhead on base-level objects. It seems unproblematic, but I
can't for the life of me recall why it was left out. Mark or Tom would know.
The only polymorphic
On Mon, Oct 17, 2011 at 12:54 AM, Axel Rauschmayer a...@rauschma.de wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:dicts
I do not yet fully understand the rationale behind dicts. I have two
questions:
- Why does it need to use the same mechanism for looking up keys as
objects?
2011/10/17 Brendan Eich bren...@mozilla.com
Back to a Proxy defaultValue trap. It should be derived as you say. It
imposes no overhead on base-level objects. It seems unproblematic, but I
can't for the life of me recall why it was left out. Mark or Tom would know.
My guess is we left out
Hi,
A couple of weeks ago, Mark and I sat together to work on a number of open
issues with proxies, in particular, how to make proxies work better with
non-configurable properties and non-extensible objects. The result is what
we call direct proxies: in our new proposal, a proxy is always a
Tom -
Been following the proxy work for quite a while and, as the original requestor
for __noSuchMethod__ to be added to Spidermonkey, I have been keen to see the
functionality as I describe here:
https://bugzilla.mozilla.org/show_bug.cgi?id=683218#c8
I'm not sure as to whether direct proxies
ES objects and their properties have always had a dual nature. They can be
used as both (semi-) fixed-shape object abstraction where the properties are
the member names and they can be used as open ended data collections where
property names are used as key values for accessing data in the
Maybe we can hold the line at private-named iterate and defaultValue
unstratified traps. I'm looking for two things:
1. Feedback from implementors on not trapping non-proxy objects based on
private names being mapped.
2. A principled approach to holding the line.
/be
On Oct 17, 2011, at
On Mon, Oct 17, 2011 at 4:30 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
ES objects and their properties have always had a dual nature. They can be
used as both (semi-) fixed-shape object abstraction where the properties are
the member names and they can be used as open ended data
Le 17/10/2011 21:43, William Edney a écrit :
Tom -
Been following the proxy work for quite a while and, as the original
requestor for __noSuchMethod__ to be added to Spidermonkey, I have
been keen to see the functionality as I describe here:
David -
You did give an answer on that bug, and I do appreciate it :-). I wanted to
raise the issue here for folks that are not subscribed to that bug, since it
seems (thankfully) that the proposed functionality hasn't been frozen yet.
I guess what would be missing for me is that, unless I
Le 17/10/2011 23:52, William Edney a écrit :
(...)
'Proxy.startTrapping()' sounds very interesting... a quick search
didn't turn up anything. Do you have any pointers to discussions,
strawmen, etc.?
Sorry, I forgot the link. It's on the direct proxy proposal:
I find this proposal a lot cleaner than the original and the usage is
a lot simpler than Proxy.create and Proxy.createFunction. Great job as
always.
My main interest lies in Proxy.startTrapping/Proxy.attach. This is a
high priority to enable data binding. However, I feel like that
section on the
Hi Tom, this looks very promising. Some comments below; quoting the wiki page
inline.
* target is the object which the direct proxy wraps
Just checking: presumably this proposal doesn't allow for target to be a
primitive, right? (Other than the special case of null you mention later.)
I.e.,
YES! This is the most exciting proposals I've seen in years. I'm so excited!
With this we would be able to implement Array and all those pesky DOM
collections without a hitch [*]. I think it might even allow sub
classing Array if Array was reimlemented using this mechanism.
[*] What of
Dot access has always been nothing more than sugar -- a strict subset of the
domain of legal property names. This subset excludes private names just as it
excludes a whole range of strings, and for the same reason (insufficient
syntax support). Arguing for syntax support is one thing -- and
(Dave Herman has another way to say this: [ ] and . can be viewed as
operating on two separate property name spaces, but for legacy/normal ES
objects those namespaces are collapsed into a single shared namespace.)
Lest the above be construed as a tacit approval on my part... ;)
IMHO the
- Pro: This conflation makes JavaScript very flexible.
- Con: We only get poor man’s maps via objects. Most other dynamic languages
(Python, Ruby, Groovy) allow any value as a key.
- Con: Name collisions between map entries and properties is a constant
source of trouble. For example, I
David -
So I assume this would allow something like:
arrayProtoProxy = Proxy.for(Array.prototype, {...blah...}); // Or even
Object.prototype...
Proxy.startTrapping(arrayProtoProxy);
Then I could do:
myArr = [];
myArr.methodArraysDontUnderstand();
And that would be trapped by the
I do not yet fully understand the rationale behind dicts.
Nothing fancy, really. Just an idiomatic way to create a non-polluted
string-to-value map. In ES5 you can use Object.create(null), which is not bad
but still kind of a hack. Wouldn't it be nice to have sweet literal syntax for
a
On Oct 17, 2011, at 2:38 PM, Dean Landolt wrote:
On Mon, Oct 17, 2011 at 4:30 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
ES objects and their properties have always had a dual nature. They can be
used as both (semi-) fixed-shape object abstraction where the properties are
On Mon, Oct 17, 2011 at 15:45, William Edney
bed...@technicalpursuit.com wrote:
So I assume this would allow something like:
arrayProtoProxy = Proxy.for(Array.prototype, {...blah...});
This probably has to be:
arrayProtoProxy = Proxy.for([], {...blah...});
since the magic collection setter
On Oct 17, 2011, at 3:34 PM, David Herman wrote:
IMHO the single property name space of es-current is a feature, not a bug.
I tend to agree. There are expressibility problems, too. For example, if you
have an object that uses . for its API and [] for some other data, then what
do you
This would seem to be a fundamental conflict between using [ ] to access
private properties and using [ ] as a special collection element accessor
syntax. You might take this as problem with using [ ] as a collection
accessor or as a discovering that using [ ] as a private property access
I agree 100% percent with the observations, but not with the solution.
Shouldn’t this be done the other way around, by introducing a new way of
accessing map elements? For example:
map@[key]
map.[key]
Then we can continue to use . and [] to access properties and use @[] to
On 12/10/11 01:32, Allen Wirfs-Brock wrote:
Which style do you think I should use in the specification?
On the whole, I don't think it matters. I don't think it's really the
right way to solve the problem (finding cross-referenced functions).
What would be (far) better, IMO, is to link
On Oct 17, 2011, at 3:32 PM, Erik Arvidsson wrote:
YES! This is the most exciting proposals I've seen in years. I'm so excited!
Thanks...
What started me thinking along this line was noticing how Dart handles [ ] as a
dynamically dispatched method. It isn't the first language to do so and C#
On Oct 17, 2011, at 4:16 PM, Axel Rauschmayer wrote:
I agree 100% percent with the observations, but not with the solution.
Shouldn’t this be done the other way around, by introducing a new way of
accessing map elements? For example:
map@[key]
map.[key]
Then we can continue
I suspect it's not nearly so rare as you think. For example, it just showed up
in Tom and Mark's new proxy proposal:
The protect trap is called on Object.{freeze,seal,preventExtensions}(aProxy).
The operation argument is a string identifying the corresponding operation
(“freeze”, “seal”,
On Oct 17, 2011, at 5:18 PM, David Herman wrote:
I suspect it's not nearly so rare as you think. For example, it just showed
up in Tom and Mark's new proxy proposal:
The protect trap is called on
Object.{freeze,seal,preventExtensions}(aProxy). The operation argument is a
string
On Oct 17, 2011, at 5:24 PM, Brendan Eich wrote:
On Oct 17, 2011, at 5:18 PM, David Herman wrote:
I suspect it's not nearly so rare as you think. For example, it just showed
up in Tom and Mark's new proxy proposal:
The protect trap is called on
47 matches
Mail list logo
