I have a blog post about it called
Resurrecting The With Statement
and before I post the link, there the long story short:
putting `with(this){` before any build process/inlined library and `}` at
the end of all concatenated files nobody is strict anymore ^_^
http://webreflection.blogspot.com/2
I agree with you. I think I worded poorly what I was trying to express.
Proxies were the catalyst for the above refactorings, which I think were
beneficial in their own right in clarifying the spec. The complexity
existed as an implied functionality of the spec. GetP and SetP clarified it
by making
so we bind everything and problem solved ? I like that ... :-)
too bad bind creates really slow invokable objects :-/
thanks for the explanation, appreciated
On Tue, Jan 29, 2013 at 10:13 AM, Brandon Benvie
wrote:
> Sorry, I wish I had thought through to the logical conclusion and
> presented
Hi,
2013/1/29 Brandon Benvie
> Responding in this thread since it's a more appropriate place.
>
> 1.) It complicates the object model, in that it adds a new internal method
> to objects, but it also clarifies it. It falls under the same category as
> [[GetP]] and [[SetP]]: they complicate the ob
[snip]
It is basically the idea that OOP call is three-part:
[[Get]] (trappable)
[[ChooseThis]] (by default choosing the base of Ref; trappable)
[[Call]] (in this context (receiver being proxy) untrappable; if a
function itself is proxy, it's already someone else's problem)
.apply and .call woul
Mark S. Miller wrote:
On Tue, Jan 29, 2013 at 10:52 AM, Herby Vojčík mailto:he...@mailbox.sk>> wrote:
Brandon Benvie wrote:
Responding in this thread since it's a more appropriate place.
1.) It complicates the object model, in that it adds a new internal
method
On Tue, Jan 29, 2013 at 10:52 AM, Herby Vojčík wrote:
>
>
> Brandon Benvie wrote:
>
>> Responding in this thread since it's a more appropriate place.
>>
>> 1.) It complicates the object model, in that it adds a new internal
>> method to objects, but it also clarifies it. It falls under the same
>
Brandon Benvie wrote:
Responding in this thread since it's a more appropriate place.
1.) It complicates the object model, in that it adds a new internal
method to objects, but it also clarifies it. It falls under the same
category as [[GetP]] and [[SetP]]: they complicate the object model, but
Responding in this thread since it's a more appropriate place.
1.) It complicates the object model, in that it adds a new internal method
to objects, but it also clarifies it. It falls under the same category as
[[GetP]] and [[SetP]]: they complicate the object model, but they also
clarify it and
Sorry, I wish I had thought through to the logical conclusion and presented
this as one email instead of four. The difference is that [[Invoke]]
accepts a function object, which implies the [[Get]] has already happened.
The issue with __noSuchMethod__ is not the receiver, it's the combination
of [[
I am not sure I understand but ... if you can solve the receiver object,
what is exactly the difference/problem again with __noSuchMethod__ and the
`this` receiver ? 'cause __noSuchMethod__ has been always used (regardless
problems with getters and setters and stuff nobody used with
__noSuchMethod_
Brandon Benvie wrote:
To elaborate, I've realized that my main disagreement with your position
(really my care at all with the private discussion) is much better
solved by introducing [[CallProperty]]. That is: Proxies currently
... and complicates object model. My main problem with [[CallPro
To elaborate, I've realized that my main disagreement with your position
(really my care at all with the private discussion) is much better solved
by introducing [[CallProperty]]. That is: Proxies currently handle |this|
binding of method calls very poorly. I'm all for either removing private or
ma
Yes, apologies. I meant equivalent in delivering the "final product", or
the desired result of the operation as a whole from the the standpoint of
the original architect. They are not equivalent on all the other ways
discussed at length otherwise.
On Tuesday, January 29, 2013, Mark Miller wrote:
Err yes, sorry. I was assuming away the last "arguments" argument in al
three cases!
On Tuesday, January 29, 2013, Allen Wirfs-Brock wrote:
> or [[CallProperty]](receiver, property, arguments)
>
> I haven't had a chance to work through all the details yet, but this is
> something I want to explor
On Mon, Jan 28, 2013 at 11:27 PM, Brandon Benvie
wrote:
> I realized the discrepancy between my thinking and what you said. In the
> case of a membrane, you are correct. A membrane will always unwrap
> everything, so you will only ever end up with dry method/dry this. That
> makes all the differen
or [[CallProperty]](receiver, property, arguments)
I haven't had a chance to work through all the details yet, but this is
something I want to explore as a solution to the Proxy forwarded identify
issue. It does have to work with both normal property access calls and with
super calls. Also, i
A superior third alternative is [[CallProperty]](receiver, property) (and,
in retrospect, likely what awb intended) which would allow for both
__noSuchMethod__ and correctly trapping super. This fits with
[[CallProperty]] being the combination of [[Get]] with calling the method.
___
Another correction: the problem with __noSuchMethod__ is actually a
completely different problem. In order to implement __noSuchMethod__
currently, a Proxy needs to always return a function from "get" which has
captured the property name in a closure. This would continue being true if
[[Invoke]] wa
Correction: [[CallProperty]] would just be trapped as the single
"callProperty" (since forwarding would do the [[Get]] on the target).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
The issues with private state (either WeakMaps or private symbols) and
Proxies seems to largely boil down to the lack of the ability to bind
|this| in forwarding method invocations to the target. This is the same
limitation that prevents Proxies from being able to fully replace
__noSuchMethod__. In
I would then suggest, as awb has, the creation of CallProperty (or Invoke)
which fixes the problem in most circumstances. With the existence of
WeakMaps and private symbols, the dry method/wet this problem is going to
be an extremely common one.
On Tue, Jan 29, 2013 at 3:19 AM, Tom Van Cutsem wr
2013/1/29 Brandon Benvie
> I realized the discrepancy between my thinking and what you said. In the
> case of a membrane, you are correct. A membrane will always unwrap
> everything, so you will only ever end up with dry method/dry this. That
> makes all the different forms of private equivalent.
23 matches
Mail list logo
