Brendan Eich wrote:
> On Dec 10, 2009, at 10:17 PM, Mark S. Miller wrote:
>
>> I think I'd be willing to weaken this from "eventual notification" to
>> "optional eventual notification." But I do not yet understand this
>> issue. How does a guarantee of eventual notification lead to any more
>> vul
On Dec 10, 2009, at 10:17 PM, Mark S. Miller wrote:
"In order to postpone the issue, the spec implied by the above code
should be taken literally: If there is no global binding for
setTimeout or if it bound to a non-callable value (as the time
WeakPtr is called), then no notifications hap
On Thu, Dec 10, 2009 at 11:38 AM, Brendan Eich wrote:
> On Dec 10, 2009, at 11:27 AM, Mark S. Miller wrote:
>
> By all means, let's continue hashing it out. I posted this proposal to
> es-discuss and presented it to the committee some time ago. I do not recall
> any serious objections, and I do r
On Thu, Dec 10, 2009 at 9:58 PM, Maciej Stachowiak wrote:
>
>> Object.prototype.hasOwnProperty.call(d, name)
>>
>
> I'm a little less confident of the latter than the former. However, Google
> Code Search finds a number of hits for Object.prototype.hasOwnProperty.call
> that appear to be operat
On Dec 10, 2009, at 9:19 PM, Mark Miller wrote:
On Thu, Dec 10, 2009 at 9:05 PM, Maciej Stachowiak
wrote:
It looks like I plied too many clauses and prepositional phrases
into once
sentence. Let me try to rephrase:
If you want to emulate a DOM object that has catchall properties,
then it
On Thu, Dec 10, 2009 at 9:05 PM, Maciej Stachowiak wrote:
> It looks like I plied too many clauses and prepositional phrases into once
> sentence. Let me try to rephrase:
> If you want to emulate a DOM object that has catchall properties, then it
> needs to return true for hasOwnProperty() for the
On Thu, Dec 10, 2009 at 7:02 PM, Garrett Smith wrote:
> On Mon, Dec 7, 2009 at 12:42 PM, Allen Wirfs-Brock
> wrote:
>> The "static generic" versions of these functions were discussed during the
>> development of ES5 but nobody advocated strongly for their inclusions.
>>
[snip]
>
> Static arrra
On Dec 10, 2009, at 8:30 PM, Mark S. Miller wrote:
On Thu, Dec 10, 2009 at 6:42 PM, Maciej Stachowiak
wrote:
On Dec 10, 2009, at 5:09 PM, Mike Samuel wrote:
2009/12/10 Mark S. Miller :
By the current taxonomy, Object.prototype.hasOwnProperty(myProxy) is
meta-level and always returns false
2009/12/10 David-Sarah Hopwood :
> Mike Samuel wrote:
>> Proxy based iterators work well with existing loop constructs though
>> while ('next' in iterator) doSomething(iterator.next);
>
> I don't understand what advantage this has over
> while (iterator.hasNext()) doSomething(iterator.next
On Thu, Dec 10, 2009 at 6:42 PM, Maciej Stachowiak wrote:
>
> On Dec 10, 2009, at 5:09 PM, Mike Samuel wrote:
>
> 2009/12/10 Mark S. Miller :
>
> By the current taxonomy, Object.prototype.hasOwnProperty(myProxy) is
>
> meta-level and always returns false on a trapping proxy, revealing that it
>
>
On Thu, Dec 10, 2009 at 7:02 PM, Garrett Smith wrote:
> On Mon, Dec 7, 2009 at 12:42 PM, Allen Wirfs-Brock
> wrote:
>> The "static generic" versions of these functions were discussed during the
>> development of ES5 but nobody advocated strongly for their inclusions.
[sni[p
> To be more specif
On Mon, Dec 7, 2009 at 12:42 PM, Allen Wirfs-Brock
wrote:
> The "static generic" versions of these functions were discussed during the
> development of ES5 but nobody advocated strongly for their inclusions.
>
> My personal opinion is that having what appears to be duplicate functions on
> both
On Dec 10, 2009, at 5:09 PM, Mike Samuel wrote:
2009/12/10 Mark S. Miller :
hasOwnProperty - cannot for non host objects
Incidentally, is Object.prototype.hasOwnProperty(myProxy)
O(myProxyHandler.keys().length) for proxies? This seems bad since a
for (in) loop that filters out non-own prop
Mike Samuel wrote:
> Proxy based iterators work well with existing loop constructs though
> while ('next' in iterator) doSomething(iterator.next);
I don't understand what advantage this has over
while (iterator.hasNext()) doSomething(iterator.next());
If next() has side-effects (moving
Tom Van Cutsem wrote:
> Hi,
>
> I think what you are looking for is this:
> http://wiki.ecmascript.org/doku.php?id=strawman:weak_references
>
> On Thu, Dec 10, 2009 at 9:44 AM, Charles Jolley wrote:
[...]
>> If we had a way to keep weak references for caches, the GC could reclaim a
>> lot more of
2009/12/10 Mark S. Miller :
> On Wed, Dec 9, 2009 at 11:26 PM, Mike Samuel wrote:
>>
>> On the climbing the meta, I'd like to understand how this might
>> interact with other proposals.
>>
>> get - already can execute arbitrary code due to getters
>> set - already can execute arbitrary code due to
On Thu, Dec 10, 2009 at 4:42 PM, Mark S. Miller wrote:
> On Wed, Dec 9, 2009 at 11:26 PM, Mike Samuel wrote:
>
>> On the climbing the meta, I'd like to understand how this might
>> interact with other proposals.
>>
>> get - already can execute arbitrary code due to getters
>> set - already can e
On Wed, Dec 9, 2009 at 11:26 PM, Mike Samuel wrote:
> On the climbing the meta, I'd like to understand how this might
> interact with other proposals.
>
> get - already can execute arbitrary code due to getters
> set - already can execute arbitrary code due to setters
> in - cannot for non host o
On Thu, Dec 10, 2009 at 1:21 PM, Brendan Eich wrote:
>
> To avoid some "climbing meta ladder" issues, we purposely distinguish
>> between what we consider base-level operations, such as x.foo, and
>> meta-level operations, such as Object.getOwnProperty(x, 'foo'). We attempt
>> to be as fully tran
On Thu, Dec 10, 2009 at 12:51 PM, Mike Wilson wrote:
>
> Why does the handler use "put" for the setter trap instead of "set" like in
> previous catchall proposals? (It seems get/set would also provide more
> symmetry with syntax in Object.defineProperty.)
>
Yes, "set" is indeed more consistent.
On Dec 10, 2009, at 12:56 PM, Mike Samuel wrote:
Generators compose in some ways though the syntax can be awkward:
def zip(a, b):
for a_el in a:
yield (a_el, b.next())
try:
b.next()
except StopIteration:
pass
except:
raise AssertionError('%r not exhausted', b)
Sorry, zip should
On Dec 10, 2009, at 12:51 PM, Mike Wilson wrote:
[really minor nit-pick:] The proposal text sometimes uses the
variable "p" for property names, sometimes for a proxy object. It
might aid new readers if these were renamed "prop" and "proxy",
respectively. A similar issue exists in the handle
On Dec 9, 2009, at 9:48 PM, Mark S. Miller wrote:
In general, handler writers have to implement standard prototype-
based delegation if it is desired. This is probably the right thing,
but I wonder if you considered the alternative where prototype
delegation is handled "by the spec" or "by t
2009/12/10 Mike Samuel :
> 2009/12/10 Brendan Eich :
>> On Dec 10, 2009, at 11:31 AM, Mike Samuel wrote:
>>
>>> I was assuming iterators would work without clients explicitly
>>> trapping STOP_ITERATION, which is what proxies would provide. But I
>>> suppose if we're doing proxies, we can also do
2009/12/10 Brendan Eich :
> On Dec 10, 2009, at 11:31 AM, Mike Samuel wrote:
>
>> I was assuming iterators would work without clients explicitly
>> trapping STOP_ITERATION, which is what proxies would provide. But I
>> suppose if we're doing proxies, we can also do the syntactic sugar to
>> do aw
Thanks for the example! Reading up on your "transparent chains" example, it
seems this will also work fine for delegation in "class hierarchies" with
multiple proxy points (User inherits from Person and both classes are
proxied, etc).
Just a couple of minor comments on other parts:
Why does the
On Dec 10, 2009, at 11:31 AM, Mike Samuel wrote:
I was assuming iterators would work without clients explicitly
trapping STOP_ITERATION, which is what proxies would provide. But I
suppose if we're doing proxies, we can also do the syntactic sugar to
do away with that in new looping constructs.
On Dec 10, 2009, at 11:27 AM, Mark S. Miller wrote:
By all means, let's continue hashing it out. I posted this proposal
to es-discuss and presented it to the committee some time ago. I do
not recall any serious objections, and I do recall several positive
responses. However, the committee h
2009/12/10 Brendan Eich :
> On Dec 10, 2009, at 11:10 AM, Mike Samuel wrote:
>
>> 2009/12/10 Brendan Eich :
>>>
>>> On Dec 10, 2009, at 9:57 AM, Mike Samuel wrote:
>>>
Actually, I think if iterators are desired, proxies may be a good way.
>>>
>>> We have implemented iterators and generators si
On Thu, Dec 10, 2009 at 11:10 AM, Brendan Eich wrote:
> On Dec 10, 2009, at 10:11 AM, Charles Jolley wrote:
>
> That looks pretty much right on. Thanks Tom! Can anyone give any insight
> as to how likely it is this might actually happen?
>
>
> You want me to lay odds? ;-)
>
> It might help to r
On Dec 10, 2009, at 11:10 AM, Mike Samuel wrote:
2009/12/10 Brendan Eich :
On Dec 10, 2009, at 9:57 AM, Mike Samuel wrote:
Actually, I think if iterators are desired, proxies may be a good
way.
We have implemented iterators and generators since 2006 in JS1.7
(Firefox
2), and they do not
On Dec 10, 2009, at 10:11 AM, Charles Jolley wrote:
That looks pretty much right on. Thanks Tom! Can anyone give any
insight as to how likely it is this might actually happen?
You want me to lay odds? ;-)
It might help to read these wiki pages, in this order:
http://wiki.ecmascript.org/do
2009/12/10 Brendan Eich :
> On Dec 10, 2009, at 9:57 AM, Mike Samuel wrote:
>
>> Actually, I think if iterators are desired, proxies may be a good way.
>
> We have implemented iterators and generators since 2006 in JS1.7 (Firefox
> 2), and they do not involve proxies or property mutation including
On Dec 10, 2009, at 9:57 AM, Mike Samuel wrote:
Actually, I think if iterators are desired, proxies may be a good way.
We have implemented iterators and generators since 2006 in JS1.7
(Firefox 2), and they do not involve proxies or property mutation
including deletion. Those are costly fea
That looks pretty much right on. Thanks Tom! Can anyone give any insight as
to how likely it is this might actually happen?
-C
On Dec 10, 2009, at 10:03 AM, Tom Van Cutsem wrote:
> Hi,
>
> I think what you are looking for is this:
> http://wiki.ecmascript.org/doku.php?id=strawman:weak_refe
Hi,
I think what you are looking for is this:
http://wiki.ecmascript.org/doku.php?id=strawman:weak_references
Cheers,
Tom
On Thu, Dec 10, 2009 at 9:44 AM, Charles Jolley wrote:
> Hi,
>
> I was wondering if any thought has gone into adding weak references and
> destructors to Harmony.
>
> We are
Actually, I think if iterators are desired, proxies may be a good way.
Code below shows a problem where having an object delete it's own
property means hard choices have to be made over when to throw an
exception. Proxies are fundamentally lazier and so dodge this issue:
var myIterator = iterato
Hi,
I was wondering if any thought has gone into adding weak references and
destructors to Harmony.
We are finding that as we build large, long running JS apps, it is very hard to
keep memory under control using the built-in GC since any reference - even for
caching - will prevent the memory
2009/12/9 Mike Samuel :
> On the climbing the meta, I'd like to understand how this might
> interact with other proposals.
>
> get - already can execute arbitrary code due to getters
> set - already can execute arbitrary code due to setters
> in - cannot for non host objects
> delete - cannot for n
39 matches
Mail list logo
