Hello,
well, never mind. As I though about it, private name is protected finely by
.public mechanism. It will never be leaked or disclosed by o[n], exactly as
Brendan wrote. You are handed a public key which is no use for you unless
you know the private one (the name object itself). Even
Hello,
I've come with the idea how to let proxies forward private names without
compromising the private name and the value stored under it, as well.
Please, could revise it and find the flaws?
Thank you, Herby
The proposal:
1. for the [[Get]] handler (scenario when that is called with
Le 18/12/2011 14:24, Herby Vojčík a écrit :
(...)
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
Le 18/12/2011 14:43, Herby Vojčík a écrit :
Hello,
I've come with the idea how to let proxies forward private names
without compromising the private name and the value stored under it,
as well.
It is an interesting idea, but is there a use case associated with this
idea? As far as I'm
Hi,
Here is a code snippet using the current direct proxy proposal and the
private name proposals:
-
var name = new Name();
var target = {};
var p = new Proxy(target, {/* all default transparent forwarding traps
*/});
target[name] = 1;
p[name] = 2;
// target[name] === 1
//
On 18.12.2011 2:51, Brendan Eich wrote:
From: Dmitry Soshnikovdmitry.soshni...@gmail.com
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
On 17.12.2011 20:19, Lasse Reichstein wrote:
On Sat, Dec 17, 2011 at 12:12 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
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
On 17.12.2011 21:22, Sam Ruby wrote:
On Sat, Dec 17, 2011 at 6:12 AM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
And the other thing is RegExp-substringing with using bracket notation:
string[RegExp, startIndex].
ecmascript[/ecma/, 0]; // ecma
This is actually the sugar for:
2011/12/17 Dmitry Soshnikov dmitry.soshni...@gmail.com:
Hi,
Just recently was working with Ruby's code. And found useful again its
(actually from Perl) approximately equal operator: =~
Perl's =~ operator is more comparable to String.prototype.match than
RegExp.prototype.test.
Perl operators
On 18.12.2011 23:18, Mike Samuel wrote:
2011/12/17 Dmitry Soshnikovdmitry.soshni...@gmail.com:
Hi,
Just recently was working with Ruby's code. And found useful again its
(actually from Perl) approximately equal operator: =~
Perl's =~ operator is more comparable to String.prototype.match than
2011/12/18 Dmitry Soshnikov dmitry.soshni...@gmail.com:
On 18.12.2011 23:18, Mike Samuel wrote:
2011/12/17 Dmitry Soshnikovdmitry.soshni...@gmail.com:
Hi,
Just recently was working with Ruby's code. And found useful again its
(actually from Perl) approximately equal operator: =~
Perl's
I haven’t seen these two functions among the proposed additions for Math
(should these be in a math module?):
function nthRoot(n, x) {
return Math.pow(x, 1/n);
}
function log_b(b, x) {
return Math.log(x) / Math.log(b);
}
Have they been considered and rejected?
Both the proposed implementations do fp rounding twice, and so produce
an inaccurate answer. I think we should probably leave it to the user
to define incorrect math functions, rather than bake them into the
language.
2011/12/19 Axel Rauschmayer a...@rauschma.de:
I haven’t seen these two
13 matches
Mail list logo
