> 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
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. I
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
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 don
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 pr
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 e
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 subt
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 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 around a DOM node
>
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 ot
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
Pro
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
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
>>
On Jul 12, 2011, at 2:54 AM, Andreas Rossberg wrote:
> On 9 July 2011 17:48, Brendan Eich 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 WeakMaps are
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 stri
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 impleme
On Jul 12, 2011, at 2:54 AM, Andreas Rossberg wrote:
> On 9 July 2011 17:48, Brendan Eich 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
On 9 July 2011 17:48, Brendan Eich 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 complexity
from on
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 co
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 prope
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 characte
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 ord
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
> 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) th
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.
>
>
>> H
>> 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
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
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 si
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 th
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 Fun
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
(http://www.w
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
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 prop
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
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,
On 9 July 2011 14:42, Sam Tobin-Hochstadt 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 post in the middl
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
> 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 w
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 m
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 4:32 PM, Allen Wirfs-Brock wrote:
> On Jul 9, 2011, at 1:43 PM, Brendan Eich wrote:
>
>> Do we want users extending Array or Function? Same problem as applies to
>> object. In Edition N+1 we then collide. I don't see a difference in kind
>> here.
>
> No, but the example we a
On Jul 9, 2011, at 1:43 PM, Brendan Eich wrote:
> 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 function
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
> perspec
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 P
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 Proxy.isProxy or Object.isProxy.
This is a fine point, but we
On Jul 9, 2011, at 12:48 AM, Andreas Rossberg wrote:
> On 9 July 2011 00:24, Brendan Eich 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
>>>
On Sat, Jul 9, 2011 at 3:48 AM, Andreas Rossberg wrote:
>
>> We went back and forth on this. I believe the rationale is in the wiki (but
>> perhaps in one of the strawman:*name* pages). There are a couple of reasons:
>> 1. We want private name objects to be usable as keys in WeakMaps. Clearly we
>
On 9 July 2011 00:24, Brendan Eich 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, where its
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 i
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 bi
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
On Jul 8, 2011, at 3:24 PM, Brendan Eich wrote:
> In other words, we don't gain any distinctiveness, or make any particular
> claims about private name objects that could not be made about other
> (deeply-frozen, generated-only, say by Object.create or Proxy.create in a
> distinguished factory
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),
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, private(fo
On 8 July 2011 21:16, Allen Wirfs-Brock 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 private names prop
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 is
55 matches
Mail list logo
