(sorry, was in a small vacation, can't answer earlier)
Yes, I'm perfectly aware about what host objects may do (there is even
wide-spread phrase in JS community: "do not trust to host objects, they can
do almost anything").
>From this viewpoint, if to treat these proxies as host objects, then in
2011/12/21 Dmitry Soshnikov
> On 20.12.2011 17:00, Tom Van Cutsem wrote:
>
> You can (and probably should) advertise a virtual method as
> configurable:true.
>
>
> I can only `configurable: true', but as we said, to fix broken `delete'
> operator, we need to treat these virtual properties as non
Funny implementation :P You did it vice-versa: functional objects _do_
work, but simple calls do not :D
No, not good to depend on `this' value and non-Reference type.
Dmitry.
On 21.12.2011 16:05, Andrea Giammarchi wrote:
This is almost the exact behavior I was talking about ...
Object.withNo
On 20.12.2011 17:00, Tom Van Cutsem wrote:
- @Tom: Found bugs in DirectProxies.js
Thanks for reporting, but I don't think these are bugs:
1. Properties created via assignment gets `false' value for
descriptor attributes; should be true. E.g. foo.bar = 10, where
`foo' is dir
This is almost the exact behavior I was talking about ...
Object.withNoSuchMethod = function withNoSuchMethod(obj, __noSuchMethod__) {
var cachedInvokes = {};
return Proxy.create({
get: function (receiver, name) {
return name in obj ?
obj[name] :
cachedInvokes.hasOwnP
>
> - @Tom: Found bugs in DirectProxies.js
>
Thanks for reporting, but I don't think these are bugs:
>1. Properties created via assignment gets `false' value for descriptor
> attributes; should be true. E.g. foo.bar = 10, where `foo' is direct proxy,
> makes bar non-configurable
>
I can't r
On 18.12.2011 2:51, Brendan Eich wrote:
From: "Dmitry Soshnikov"
On 17.12.2011 17:21, Herby Vojčík wrote:
Hello,
from my point the scenario that:
delete lib.toRussianName;
then it still:
typeof lib.toRussianName; // "function", Trollface ;D
is much more acceptable (it happens e
From: "Dmitry Soshnikov"
> On 17.12.2011 17:21, Herby Vojčík wrote:
> > Hello,
> >
> > from my point the scenario that:
> >
> >delete lib.toRussianName;
> >
> >then it still:
> >
> >typeof lib.toRussianName; // "function", Trollface ;D
> >
> > is much more acceptable (it happens everyd
> That's why I proposed first-class phantoms in gist: beasts that typeof
> to "phantom", ToBoolean to false, ToNumber to 0, are wrapping a
> function, [[Call]] calls that function, [[Get]] and [[Prototype]]
> delegates to that function ([[Class]] is questionable) and rest does not
> work ([[Set]]
On 17.12.2011 18:08, Andrea Giammarchi wrote:
Dmitry, addressing a trap fallback is not a good idea plus the average
JS coder rarely does it ... said that, the moment you are using a
method you already know this exists so you already know the
documentation ( or part of it ) so I don't see much
On 17.12.2011 17:21, Herby Vojčík wrote:
Hello,
from my point the scenario that:
delete lib.toRussianName;
then it still:
typeof lib.toRussianName; // "function", Trollface ;D
is much more acceptable (it happens everyday - there are non-writable
properties everywhere),
Yes, good
and about last point, maybe objects that implements noSuchMethod should
return something like "unknown" via typeof ... just saying, and simply to
differentiate these objects from others where __noSuchMethod__ is not in
place.
On Sat, Dec 17, 2011 at 3:08 PM, Andrea Giammarchi <
andrea.giammar...@g
Dmitry, addressing a trap fallback is not a good idea plus the average JS
coder rarely does it ... said that, the moment you are using a method you
already know this exists so you already know the documentation ( or part of
it ) so I don't see much hurt there.
Moreover, the addressing problem is c
Hello,
from my point the scenario that:
delete lib.toRussianName;
then it still:
typeof lib.toRussianName; // "function", Trollface ;D
is much more acceptable (it happens everyday - there are non-writable
properties everywhere), than the scenario where I cannot transform
lib.to
uot; mailto:dmitry.soshni...@gmail.com>>
Cc: "Brendan Eich" mailto:bren...@mozilla.com>>, "es-discuss"
mailto:es-discuss@mozilla.org>>
Sent: Friday, December 16, 2011 8:30:47 AM
Subject: Re: noSuchMethod: "funargs" + "in
ight, it'll be trivial to standardize one of these libraries, or
> even make a private-named unstratified noSuchMethod trap.
>
> /be
>
> - Original Message -
> From: "Andrea Giammarchi"
> To: "Dmitry Soshnikov"
> Cc: "Brendan Eich" , "es-d
an be used
by a library (a standard one, even) to implement something like
__noSuchMethod__.
/be
----- Original Message -
From: "Dmitry Soshnikov" < dmitry.soshni...@gmail.com >
To: "es-discuss" < es-discuss@mozilla.org >
Sent: Thursday, December 15, 2011 5
of JS so do not feel any
>>> second-class pain.
>>>
>>> Other styles of JS would definitely feel pain. One size does not fit all.
>>>
>>> This is why rejecting an invoke trap is not a matter of black and white,
>>> IMHO -- it's simply a desire
lexity and see how the result
>> can be used by a library (a standard one, even) to implement something like
>> __noSuchMethod__.
>>
>> /be
>>
>> - Original Message -
>> From: "Dmitry Soshnikov"
>> To: "es-discuss"
>>
-
> From: "Dmitry Soshnikov"
> To: "es-discuss"
> Sent: Thursday, December 15, 2011 5:48:37 AM
> Subject: noSuchMethod: "funargs" + "invoke-only-phantoms"
>
>
> Hi,
>
> Here is the analysis of current "noSuchMethod" si
n) to implement something like
__noSuchMethod__.
/be
- Original Message -
From: "Dmitry Soshnikov"
To: "es-discuss"
Sent: Thursday, December 15, 2011 5:48:37 AM
Subject: noSuchMethod: "funargs" + "invoke-only-phantoms"
Hi,
Here is the analysis of
Hi,
Here is the analysis of current "noSuchMethod" situation implemented via
proxies.
I summarized that never-ending thread from 2010 (
https://mail.mozilla.org/pipermail/es-discuss/2010-October/011929.html),
since guys in JS community started to ask why proxies don't support
noSuchMethod.
It's
22 matches
Mail list logo
