Perhaps Proxy.isProxy was used merely as an example, but wasn't the
consensus that Proxy.isProxy is not needed? Dave pointed out that it breaks
transparent virtualization. Also, there is Object.isExtensible which always
returns |true| for (trapping) proxies. That means we already have half of
I really don't think IsProxy is a good idea. It can lead to subtle bugs
depending on whether an object is a DOM node, or a wrapper around a DOM node
(or whether the embedding uses a proxy to implement DOM nodes or not). In
Firefox we plan on making some DOM nodes proxies for example, but not
I fully agree that isProxy sounds like a bad idea. It just breaks the
proxy abstraction.
/Andreas
On 13 July 2011 10:26, Andreas Gal g...@mozilla.com wrote:
I really don't think IsProxy is a good idea. It can lead to subtle bugs
depending on whether an object is a DOM node, or a wrapper
And in general, the main use case for proxies is to emulate host
objects. If there is a language construct that helps separating the two
cases, we're going against this use case.
David
Le 13/07/2011 10:26, Andreas Gal a écrit :
I really don't think IsProxy is a good idea. It can lead to
isProxy is definitely a meta-layer operation and you don't want it polluting
the application layer. However, when you doing proxy level meta programming I
can imagine various situations where you might need to determine whether or not
an object is a proxy. I think it should exist, but should
Putting private properties on a proxy or storing it in a weak map are simple
protocols you can use to keep track of proxies that you know about. You can
hide or expose this information then without however many or few clients you
like. If you want to give people access to knowledge about your
If you created the proxy, you can use a weak map to keep track of the fact that
its a proxy (and even more precisely, its one of the proxies you created with
your handler).
Andreas
On Jul 13, 2011, at 8:31 AM, Allen Wirfs-Brock wrote:
isProxy is definitely a meta-layer operation and you
On Jul 13, 2011, at 1:23 AM, Tom Van Cutsem wrote:
Perhaps Proxy.isProxy was used merely as an example,
That's right, it was one of several in seeking for naming conventions, and
deeper distinctions among type-testing predicates. Not to worry -- I agree we
should remove it.
/be
but wasn't
On Jul 13, 2011, at 8:44 AM, David Herman wrote:
Putting private properties on a proxy or storing it in a weak map are simple
protocols you can use to keep track of proxies that you know about. You can
hide or expose this information then without however many or few clients you
like. If
There are various ways that implementation details can get exposed. For
example, by toString'ing a method property. I don't see why isProxy is any
more of an abstraction leak than toString. It is actually less, if we
clearly position it as one of the meta-programming functions that are
On 9 July 2011 17:48, Brendan Eich bren...@mozilla.com wrote:
Adding names as a distinct reference and typeof type, extending
WeakMap to have as its key type (object | name), adds complexity
compared to subsuming name under object.
It seems to me that you are merely shifting the additional
On Jul 12, 2011, at 2:54 AM, Andreas Rossberg wrote:
On 9 July 2011 17:48, Brendan Eich bren...@mozilla.com wrote:
Adding names as a distinct reference and typeof type, extending
WeakMap to have as its key type (object | name), adds complexity
compared to subsuming name under object.
It
I think there is a (usually unstated) desire to also test for
ES.next features that may also start to show up as extensions
to ES5 level implementations. For example, generators in
Firefox. You can't depend upon modules in such situations.
For me, the issue is that ES engines tend to
On Jul 12, 2011, at 7:43 AM, Brendan Eich wrote:
On the other hand, there's no free lunch for private names having a new
typeof type: name. They cannot be strings, so the VM's property lookup and
identifier-handling code paths all need a wider type. True, they *could* be
UUIDs in strings
On Jul 12, 2011, at 2:54 AM, Andreas Rossberg wrote:
On 9 July 2011 17:48, Brendan Eich bren...@mozilla.com wrote:
Moreover, the distinction between names and proper
objects will have to be deeply engrained in the spec, because it
changes a fundamental mechanism of the language. Whereas
Allen, thanks for replying -- I ran out of time this morning. A few comments on
top of yours.
On Jul 12, 2011, at 10:18 AM, Allen Wirfs-Brock wrote:
I think an efficient implementation of names in something like V8 will
probably want to assign different internal type tags to them either
way.
On Jul 12, 2011, at 11:08 AM, Brendan Eich wrote:
5. What are the conventions by which the library distinguishes between
regular object properties and operations, and meta (reflective)
ones? It seems to me that part of the confusion(?) in the discussion
is that the current design makes no
On 9 July 2011 14:42, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
Unlike Names, strings and numbers are forgeable, so if they were
allowed as keys in WeakMaps, the associated value could never be
safely collected. Names, by contrast, have identity.
Of course you are right, and I shouldn't
On Jul 10, 2011, at 6:58 PM, Brendan Eich wrote:
On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:
Why not a non-writable,non-enumerable non-configurable data property on
Function.prototype.
We're talking about isGenerator, right? There is no Generator constructor, no
On Jul 11, 2011, at 9:25 AM, Allen Wirfs-Brock wrote:
On Jul 10, 2011, at 6:58 PM, Brendan Eich wrote:
On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:
Why not a non-writable,non-enumerable non-configurable data property on
Function.prototype.
We're talking about isGenerator,
On Jul 11, 2011, at 9:32 AM, Brendan Eich wrote:
On Jul 11, 2011, at 9:25 AM, Allen Wirfs-Brock wrote:
On Jul 10, 2011, at 6:58 PM, Brendan Eich wrote:
On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:
Why not a non-writable,non-enumerable non-configurable data property on
On Jul 11, 2011, at 10:25 AM, Allen Wirfs-Brock wrote:
I don't think we or anybody else has really explored the extensibility
implications of generator functions so it isn't surprising that there have
been no requests.
We certainly have explored generators (extensibility is not a good in
How about rest and spread, or de-structuring? We are
going to use non-eval detectability as a ECMAScript
extension design criteria then maybe we do need a less
ad-hoc scheme for feature detection. It wouldn't have
to be all that grand...
Even less grand ones such as the DOM's
On Jul 11, 2011, at 10:41 AM, Brendan Eich wrote:
On Jul 11, 2011, at 10:25 AM, Allen Wirfs-Brock wrote:
Certainly there is no need to add any new globals to support a distinct
prototype for generator functions. Strictly speaking there wouldn't even
have to be a property on Function to
On Jul 11, 2011, at 11:50 AM, Claus Reinke wrote:
How about rest and spread, or de-structuring? We are going to use non-eval
detectability as a ECMAScript extension design criteria then maybe we do
need a less ad-hoc scheme for feature detection. It wouldn't have to be
all that grand...
On Jul 11, 2011, at 12:46 PM, Allen Wirfs-Brock wrote:
I think there is a (usually unstated) desire to also test for ES.next
features that may also start to show up as extensions to ES5 level
implementations. For example, generators in Firefox. You can't depend upon
modules in such
On Jul 11, 2011, at 12:40 PM, Allen Wirfs-Brock wrote:
isGenerator is essentially a value test rather than class-like
categorization. Methods work well for this because a method can dynamically
inspect the value being tested in order to make the determination.
I'm not so sure about this
Adding a non-enumerable Array.prototype method seems doable to me, if the
name is clear and not commonly used.
We can probably still add Array.prototoype.isArray if that would help to
establish the pattern. Document as being preferred over Array.isArray
This doesn't make sense to me.
On Jul 11, 2011, at 4:18 PM, Brendan Eich wrote:
So I think we took the wrong door here. Function.isGenerator by analogy to
Array.isGenerator,
... by analogy to Array.isArray, of course.
/be
or an isGenerator export from @iter (equivalent semantically), is the best
way.
However,
I'm not so sure about this now. I was just reviewing with Dave how the design
evolved. We had Function.isGenerator, analogous to Array.isArray. For taskjs,
Dave had thought he had a use-case where the code has a function and wants to
know whether it's a generator. It turned out (IIUC) that
On Jul 11, 2011, at 4:19 PM, David Herman wrote:
Adding a non-enumerable Array.prototype method seems doable to me, if the
name is clear and not commonly used.
We can probably still add Array.prototoype.isArray if that would help to
establish the pattern. Document as being preferred
On Jul 11, 2011, at 4:18 PM, Brendan Eich wrote:
On Jul 11, 2011, at 12:40 PM, Allen Wirfs-Brock wrote:
isGenerator is essentially a value test rather than class-like
categorization. Methods work well for this because a method can dynamically
inspect the value being tested in order to
On Jul 11, 2011, at 5:29 PM, Allen Wirfs-Brock wrote:
I was almost sold on this argument, but I see a different issue. Global
predicate functions like this aren't extensible. Array.isArray and
Function.isGenerator work fine because they are testing deep implementation
level
On Jul 11, 2011, at 6:14 PM, Brendan Eich wrote:
On Jul 11, 2011, at 5:29 PM, Allen Wirfs-Brock wrote:
However, for pure JS classification you want them to be duck-type
extensible. It is easy to add a new implementation for some category if the
category test uses an instance property
On Jul 11, 2011, at 7:31 PM, Allen Wirfs-Brock wrote:
Agreed, these are both cases where the category isn't user extensible.
However, I think my statement holds for class-like categorization that are
extensible.
Do we have any examples of those in the spec., or contemplated for
On Jul 9, 2011, at 7:22 PM, Brendan Eich wrote:
On Jul 9, 2011, at 5:02 PM, Allen Wirfs-Brock wrote:
...
1) stratification - Proxy.isProxy is an example
2) It is impossible or inconvenient to add the classification interface to
the appropriate instance interface. I think that was the
On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:
However, arguably Array.isArray really should have been
Array.prototype.isArray. We treated as a case 2 from above. May we really
didn't need to, but that's water over dam. I don't think we should use it
as precedent for more
On 9 July 2011 00:24, Brendan Eich bren...@mozilla.com wrote:
On Jul 8, 2011, at 2:43 PM, Andreas Rossberg wrote:
One minor suggestion I'd have is to treat names as a proper new
primitive type, i.e. typeof key == name, not object. That way, it
can be defined much more cleanly what a name is,
On Jul 9, 2011, at 9:45 AM, Brendan Eich wrote:
On Jul 9, 2011, at 8:48 AM, Brendan Eich wrote:
See above, there is nothing novel or evil in isName or isArray (another
example) isGenerator.
Also the Proxy.isTrapping, which in recent threads has been proposed to be
renamed to
On Jul 9, 2011, at 11:19 AM, Allen Wirfs-Brock wrote:
A consideration here is that whatever conventions we follow sets a precedent
for user written code. I don't think we want to encourage the addition of
such classification functions to Object or Object.prototype. So from that
On Jul 9, 2011, at 5:02 PM, Brendan Eich wrote:
On Jul 9, 2011, at 4:32 PM, Allen Wirfs-Brock wrote:
On Jul 9, 2011, at 1:43 PM, Brendan Eich wrote:
... However, if that isn't your concern (and my perspective is that in most
cases it shouldn't be) you might as well use a public
On Jul 9, 2011, at 7:22 PM, Allen Wirfs-Brock wrote:
On Jul 9, 2011, at 5:02 PM, Brendan Eich wrote:
On Jul 9, 2011, at 4:32 PM, Allen Wirfs-Brock wrote:
On Jul 9, 2011, at 1:43 PM, Brendan Eich wrote:
... However, if that isn't your concern (and my perspective is that in most
cases
The current Harmony classes proposal
http://wiki.ecmascript.org/doku.php?id=harmony:classes includes the concept of
private instance members and syntax for defining them. While it presents a
syntax for accessing them (eg, private(foo).bar accesses the private 'bar'
member of the object that
On 8 July 2011 21:16, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The current versions of the private names proposal
http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects simply
exposes a constructor for creating unique values can be be used as property
keys:
Of the several
On Jul 8, 2011, at 12:16 PM, Allen Wirfs-Brock wrote:
The current Harmony classes proposal
http://wiki.ecmascript.org/doku.php?id=harmony:classes includes the concept
of private instance members and syntax for defining them. While it presents
a syntax for accessing them (eg,
On Jul 8, 2011, at 2:43 PM, Andreas Rossberg wrote:
One minor suggestion I'd have is to treat names as a proper new
primitive type, i.e. typeof key == name, not object. That way, it
can be defined much more cleanly what a name is, where its use is
legal (as opposed to proper objects), and
On Jul 8, 2011, at 3:24 PM, Brendan Eich wrote:
On Jul 8, 2011, at 2:43 PM, Andreas Rossberg wrote:
Point = {
//private members
[__x]: 0,
[ __y]: 0,
[__validate](x,y) { return typeof x == 'number' typeof y =
'number'},
//public members
new(x,y) {
On Jul 8, 2011, at 4:21 PM, Allen Wirfs-Brock wrote:
On Jul 8, 2011, at 3:24 PM, Brendan Eich wrote:
Then the shape of the object is not static. Perhaps this is worth the costs
to implementations and other analyzers (static program analysis, human
readers). We should discuss a bit more
On Jul 8, 2011, at 2:58 PM, Brendan Eich wrote:
On Jul 8, 2011, at 12:16 PM, Allen Wirfs-Brock wrote:
The current Harmony classes proposal
http://wiki.ecmascript.org/doku.php?id=harmony:classes includes the concept
of private instance members and syntax for defining them. While it
49 matches
Mail list logo
