Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

2011-12-17 Thread Brendan Eich
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

Re: Are Private name and Weak Map the same feature? and the Assoc API

2011-12-17 Thread David Bruant
Le 17/12/2011 22:37, David Herman a écrit : > On Dec 17, 2011, at 4:04 AM, David Bruant wrote: >> I propose to accept that "o[n]" may disclose 'n' if 'o' is a proxy. > This is just a non-starter. Then you can't use private names as private names. I have read a lot of code that I have written myself

Re: Are Private name and Weak Map the same feature? and the Assoc API

2011-12-17 Thread David Herman
On Dec 17, 2011, at 4:04 AM, David Bruant wrote: > I propose to accept that "o[n]" may disclose 'n' if 'o' is a proxy. This is just a non-starter. Then you can't use private names as private names. > (One good news is that mostly static analysis > can assist us in finding where we may disclose '

Re: One-time .public

2011-12-17 Thread David Bruant
Le 17/12/2011 19:03, Herby Vojčík a écrit : > Hello, > > I saw some concerns about security of name.public and possible leak of > correspondence between public and its name. Just to clarify, there is no security issue with '.public'. What I argued for is that it does not bring more security than be

Re: One-time .public

2011-12-17 Thread Herby Vojčík
Errata: I meant "withOUT re-generating it", so it can do the comparision. -Pôvodná správa- From: Herby Vojčík Sent: Saturday, December 17, 2011 7:03 PM To: es-discuss@mozilla.org Subject: One-time .public Hello, I saw some concerns about security of name.public and possible leak of co

One-time .public

2011-12-17 Thread Herby Vojčík
Hello, I saw some concerns about security of name.public and possible leak of correspondence between public and its name. Maybe it can be solved by simple trick (though it will have some implication of certain parts of code). That is, each time name.public is read, _new_ object will be created

Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

2011-12-17 Thread Herby Vojčík
> 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]]

Re: [Proxies] VirtualHandler fundamental traps: defaults

2011-12-17 Thread David Bruant
Le 12/12/2011 16:40, Tom Van Cutsem a écrit : > (...) > > So in short I would prefer sensible defaults over error-throwing > missing fundamental traps. > I'd be interested in hearing others' thoughts about this. In how they are defined and used, virtual handlers are very much like the previous prox

Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

2011-12-17 Thread Dmitry Soshnikov
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

Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

2011-12-17 Thread 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 everyday - there are non-writable properties everywhere), Yes, good

Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

2011-12-17 Thread Andrea Giammarchi
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

Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

2011-12-17 Thread Andrea Giammarchi
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

On "private per-object state"

2011-12-17 Thread Herby Vojčík
Hello, I see some discrepancies between dynamic slot-based ES versus concept of "private per-object state". The main problem seems to be that I can do this: (function() { return private(this).secret; }).call(obj); In that case, I can read (and also write) object's private property at will.

Alternative proposal to privateName.public

2011-12-17 Thread David Bruant
Hi, Here is a proposal related to the discussion we've had in the other thread. Gist: https://gist.github.com/1490167 # Introduction We've seen in [the thread "Are Private name and Weak Map the same feature? and the Assoc API"](https://mail.mozilla.org/pipermail/es-discuss/2011-December/018875.h

Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

2011-12-17 Thread Herby Vojčík
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

Re: Are Private name and Weak Map the same feature? and the Assoc API

2011-12-17 Thread David Bruant
Le 17/12/2011 00:24, Sam Tobin-Hochstadt a écrit : > On Fri, Dec 16, 2011 at 6:09 PM, David Bruant wrote: >>> Requiring you to care in order to avoid leaking private names is incredibly >>> error-prone. >> So is requiring you to care in order to avoid leaking the public -> >> private map. It's no

"Approx-equal" operator

2011-12-17 Thread Dmitry Soshnikov
Hi, Just recently was working with Ruby's code. And found useful again its (actually from Perl) "approximately equal" operator: =~ The operator is just a sugar for `test' method of RegExp. if (/ecma/.test("ecmascript")) { console.log("ECMAScript"); } is sugared into: if ("ecmascript" =~ /

Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

2011-12-17 Thread Dmitry Soshnikov
On 17.12.2011 9:56, Andrea Giammarchi wrote: if both V8 and SpiderMonkey will follow that logic to trap invoke-only method, I'll do my best to promote and explain how it works and why addressing anyhow does not make sense since there is nothing to address being inexistent. It was my main th