Re: Versioning?
@Gavin Barraclough :
I don't get the point of having the code break in old browsers...
When you use this code:
use version 6; with ({hi:Hi!}) alert(hi);
It will throw an error and this is what you want it to do. Just like
when you used use strict;
Of course, it would work in old browsers and not in new because they
would know with isnt allowed anymore. But again, that's what i expect:
When i dev in new browsers, it tells me what is bad and when I put it
on old browser, they just don't care and have it work.
But if you use:
use version 6;
to opt-in, then you CAN NOT write backward compatible code while using
some ES6 features (even those that can be polyfilled)...
On Tue, Dec 20, 2011 at 12:16 AM, Axel Rauschmayer a...@rauschma.de wrote:
My understanding:
- Shim: retrofit a new API in an older context.
- Polyfill: “A shim that mimics a future API providing fallback
functionality to older browsers.”
On Dec 19, 2011, at 19:54 , Rick Waldron wrote:
Mark, It [polyfill] was coined by Remy
Sharp http://remysharp.com/2010/10/08/what-is-a-polyfill/
...I still don't understand how it differs from shim
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Have the scope accessible as an object and implement a new with operator / block
Hi,
There is this one thing in JavaScript I really hate: You can't so
{{$varName}} as in PHP so as soon as you need dynamic names, you have
to put everything in an object...
I don't know how scopes are implemented but there should be a not so
hard way to make them available as JS objects. The same way window
(or global or self or whatever) works for the global scope. Something
like this:
var a = { };
var b = [ ];
window[ 'a' ] === a;// true
window[ 'b' ] === b;// true
( function ( ) {
var a = { };
var b = [ ];
scope[ 'a' ] === a;// - true
scope[ 'b' ] === b;// - true
}( ) );
And the scope would inherit the parent scope. Here (this code would be
inside the function:
var scope = Object.create( window, {
a: {
value: a,
enumerable: true,
writable: true,
configurable: true
},
// same with b
} );
About the properties:
- enumerable true seems obvious
- writable too, except for variable declared with const
- configurable, I'd say false since you cannot use delete on variables
declared with var. But if you want the same behavior as window, then
variables declared with var would have configurable=false and the ones
declared as properties of the scope would have configurable=true.
var a = { };
window.b = { };
console.log( delete a );// false
console.log( delete b );// true
console.log( a );// Object
console.log( b );// ReferenceError: b is not defined
I always though this behavior was strange but since it is and doesn't
bother anyone...
About security, maybe Object.getPrototypeOf should throw an error on
scopes. Because having a child scope change your variables could be
strange... But that would only be a problem for scripts made with
third-party scripts included in own scripts that declare fake
variables to remove access to some features:
( function ( ) {
var window, setTimeout, undefined;
( function ( ) {// this function is from third party. It got
inserted in this code to make it safer
// whatever but can't access setTimeout
).call( undefined );
}( ) );
And without Object.getPrototypeOf and scope:
( function ( ) {
var window, setTimeout, undefined;
( function ( ) {// this function is from third party. It got
inserted in this code to make it safer
Object.getPrototypeOf( Object.getPrototypeOf( scope )
).setTimeout( function( ) { }, 100 );// you can access setTimout
).call( undefined );
}( ) );
This might not seam that useful but when you think about the with
operator from ES 3, if you add this scope thing, it becomes easy to
make it work properly.
I don't know how we could call it but what it would do is setting the
inner scope to an object. So ALL variables in that block would be
the object's properties and it would remove any other variable.
Here is an example:
( function ( ) {
var a = 'a';
var b = 'b';
var o = {
b: 'B',
c: 'C'
};
// here, scope == { a: 'a', b: 'b', o: { b: 'B', c: 'C' } }
with ( o ) {
// /!\ scope is still the same!
// otherwise you would have no access to real variables
b;// 'B'
c;// 'C'
try {
a;
} catch ( e ) {
e;// ReferenceError: a is not defined
}
scope.a;// 'a'
scope.b;// 'b'
scope.c;// undefined
}
} )( );
What do you think?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Have the scope accessible as an object and implement a new with operator / block
2011/12/20 Xavier MONTILLET xavierm02@gmail.com:
Hi,
There is this one thing in JavaScript I really hate: You can't so
{{$varName}} as in PHP so as soon as you need dynamic names, you have
to put everything in an object...
I don't know how scopes are implemented
Not being able to get hold of the scope as an object enables important
optimizations and is a feature, not a bug.
--
Erik Corry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Have the scope accessible as an object and implement a new with operator / block
What kind of optimizations? The variable have to be in some kind of
structure and it should be possible to read it as an object the same
way you read it as variables...
The fact that the inheritance between scopes I spoke of would be
hard to implement because they keep a one level deep structure and
change it when they change scope would be understandable. But no being
able to read the structure seems strange to me.
On Tue, Dec 20, 2011 at 11:19 AM, Erik Corry erik.co...@gmail.com wrote:
2011/12/20 Xavier MONTILLET xavierm02@gmail.com:
Hi,
There is this one thing in JavaScript I really hate: You can't so
{{$varName}} as in PHP so as soon as you need dynamic names, you have
to put everything in an object...
I don't know how scopes are implemented
Not being able to get hold of the scope as an object enables important
optimizations and is a feature, not a bug.
--
Erik Corry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Versioning?
I was speaking of ES 5 + use strict; since it needs you to opt-in.
ES 5 itself doesn't.
Given the nature of the changes in ES6 I'm not sure that there will be much
scope to write code that benefits form utilizing ES6 and yet would still run
on a browser supporting only ES5. If you want to write code that will run on
an browser that only supports ES5, I think you will find you need to stick to
writing ES5 code.
Weakmaps, private names, optimized arrays are all much better in ES 6
but could be (kind of) implemented in ES 5.
On Tue, Dec 20, 2011 at 11:28 AM, Gavin Barraclough
barraclo...@apple.com wrote:
On Dec 20, 2011, at 1:38 AM, Xavier MONTILLET wrote:
use version 6; with ({hi:Hi!}) alert(hi);
It will throw an error and this is what you want it to do. Just like
when you used use strict;
No, that is not what this program is spec'ed to do in ES5. In a conforming
ES5 implementation, this program will alert Hi!.
If you make a browser that throws an error on receiving this input, it is not
ES5 conformant.
use version 6;
to opt-in, then you CAN NOT write backward compatible code while using
some ES6 features (even those that can be polyfilled)...
Given the nature of the changes in ES6 I'm not sure that there will be much
scope to write code that benefits form utilizing ES6 and yet would still run
on a browser supporting only ES5. If you want to write code that will run on
an browser that only supports ES5, I think you will find you need to stick to
writing ES5 code.
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Have the scope accessible as an object and implement a new with operator / block
I would love to have something like Python’s locals(): http://docs.python.org/py3k/library/functions.html#locals It would not allow modifications, but it would still be very useful. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Have the scope accessible as an object and implement a new with operator / block
On 20 December 2011 11:24, Xavier MONTILLET xavierm02@gmail.com wrote: What kind of optimizations? Optimizations such as putting variables in registers, putting variables on the stack, overlaying variables with disjoint life times, eliminating some variables entirely, minimizing closure environments, to name just a few. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Have the scope accessible as an object and implement a new with operator / block
Well what about you add an if that checks whether scope is used or not and if it is disables these optimizations? On Tue, Dec 20, 2011 at 11:46 AM, Andreas Rossberg rossb...@google.com wrote: On 20 December 2011 11:24, Xavier MONTILLET xavierm02@gmail.com wrote: What kind of optimizations? Optimizations such as putting variables in registers, putting variables on the stack, overlaying variables with disjoint life times, eliminating some variables entirely, minimizing closure environments, to name just a few. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Have the scope accessible as an object and implement a new with operator / block
In a way it would be like proxies: slow if used but doesn't change anything if you don't use them. On Tue, Dec 20, 2011 at 11:51 AM, Xavier MONTILLET xavierm02@gmail.com wrote: Well what about you add an if that checks whether scope is used or not and if it is disables these optimizations? On Tue, Dec 20, 2011 at 11:46 AM, Andreas Rossberg rossb...@google.com wrote: On 20 December 2011 11:24, Xavier MONTILLET xavierm02@gmail.com wrote: What kind of optimizations? Optimizations such as putting variables in registers, putting variables on the stack, overlaying variables with disjoint life times, eliminating some variables entirely, minimizing closure environments, to name just a few. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: noSuchMethod: funargs + invoke-only-phantoms
- @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 reproduce this. Both in tracemonkey and ff8 I get the following:
js var t = {}
js var p = Proxy(t, {})
js p.x = 1
1
js Object.getOwnPropertyDescriptor(t, 'x')
({value:1, writable:true, enumerable:true, configurable:true})
js Object.getOwnPropertyDescriptor(p, 'x')
({value:1, writable:true, enumerable:true, configurable:true})
There is, however, a TM-specific bug that I suspect may be the cause of
your observed non-configurable by default behavior:
https://bugzilla.mozilla.org/show_bug.cgi?id=601329
2. Can't return descriptor with `configurable: false' for non-existing
property; get: cannot report a non-configurable descriptor for
non-existent property But we need it in case virtual methods
You can (and probably should) advertise a virtual method as
configurable:true.
The proxy throws this exception because, for properties that do not exist
on the wrapped target, it cannot guarantee that they will always be
non-configurable. For example, if your proxy handler now says that foo is
{value:10, configurable:false}, nothing stops your proxy handler from later
claiming that foo is {value:0, configurable:true}.
Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [Proxies] VirtualHandler fundamental traps: defaults
2011/12/17 David Bruant bruan...@gmail.com I don't think that the default you propose are a good idea, because it will make bugs harder to track. Object.getOwnPropertyDescriptor returning 'undefined' for any property does not sound like a good idea. Likewise for Object.getOwnPropertyNames returning [] systematically. That is indeed a concern. Abstract methods err on the side of safety. Default behaviors can turn against you if they don't do what you expected. Another idea would be to have no default for virtual handler fundamental trap and that the fundamental traps are the default direct proxies traps (forwarding to the target). I don't agree here: the VirtualHandler is designed to support proxy abstractions that explicitly do not want to use their target object, i.e. they want to ignore the target object as much as possible. VirtualHandlers are for creating virtual objects (for instance, a remote object proxy for which there is no real physical target object acting as a backing store). Indeed, the reason why the VirtualHandler implements the entire handler API, overriding all the default trap behavior, is precisely to avoid falling back to forwarding to the target. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Have the scope accessible as an object and implement a new with operator / block
On 20 December 2011 11:51, Xavier MONTILLET xavierm02@gmail.com wrote: Well what about you add an if that checks whether scope is used or not and if it is disables these optimizations? That's what's done for things like the `arguments' object. And it's an ugly mess, in terms of semantics as well as implementation. I believe it's fair to say that it is widely considered a misfeature these days. (ES is moving away from it, as well as from the global object.) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Proxies] VirtualHandler fundamental traps: defaults
[off-list] Le 20/12/2011 14:11, Tom Van Cutsem a écrit : VirtualHandlers are for creating virtual objects (for instance, a remote object proxy for which there is no real physical target object acting as a backing store). Speaking of which, I'm reading the PDF version Structure and Encapsulation in Distributed Systems: the Proxy Principle by Marc Shapiro right now :-) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Are Private name and Weak Map the same feature? and the Assoc API
On 17 December 2011 00:24, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
I used to think this way about private names and proxies, and argued
for this position. However, I was wrong and it's a bad idea. Here's
why:
You might want to implement an object with a private field and a
public method like this:
let o = (function () { let n = new Name(); return { [n]: 0; get:
function() { return this[n]; }}})();
But, if we don't censor private names in proxies, this abstraction leaks!
Consider:
let p = new Proxy(...);
o.get.call(p);
Now the name is leaked to the proxy. And there's no way you can fix
this, without resorting to some other method of hiding things like
closures.
Hm, isn't this example rather demonstrating that the ability to do
self stealing -- i.e., the lack of lexical `this' -- is violating
basic abstraction principles (as we all know)? That is, in JS you have
to manually fix such abstractions using .bind on your methods (or
potential nicer alternatives in ES6). Arguably, the problem is not
proxies or private names (under David's semantics) per se.
But of course, we cannot really fix `this', so we introduce public
name conversion (and other ad-hoc complications surrounding private
names) as compatibility hacks that prevent blatant leaks for existing
JS idioms. It's not puristic, but it is convenient and pragmatically
safer.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Alternative proposal to privateName.public
Le 17/12/2011 14:24, David Bruant a écrit :
(...)
# Proposal
What about a 'trapped' boolean in the private name constructor?
It would work this way:
`JavaScript
var n = new Name(false); // don't trap when used is a proxy
var p = new Proxy({}, maliciousHandler);
p[n] = 21; // the set trap is NOT called!
var v = p[n]; // the get trap is NOT called and v === 21
`
Basically, when the private name is created with the 'trapped' boolean
to false, the proxy becomes oblivious to being called with these private
names.
There has been some other proposals suggesting ways to bypass the proxy
to work directly on the target. Since I have been brief, my proposal
could be interepreted as such and it was not my intention. So here are
additional code snippets to further explain my proposal.
-
var n = new Name(false); // untrapped name
var t = {};
var p = new Proxy(t, maliciousHandler);
p[n] = 21; // the malicious set trap is NOT called!
var v = p[n]; // the malicious get trap is NOT called and v === 21
Object.getOwnPropertyDescriptor(t, n); // undefined
-
In this proposal, in the case of untrapped names, only the proxy
identity is used internally. No trap is called and the target remains
untouched.
There is neither implicit nor explicit forwarding to the target. If the
code in possession of both a reference to the private name and a
suspicious object does not want the suspicious object to have to do
anything with the name, it can define the private name as untrapped and
the proxy will be oblivious to the private name.
This choice is made in order to make the private name owners responsible
for what they do with the private name, choose who they want the name to
be shared with.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Are Private name and Weak Map the same feature? and the Assoc API
Le 20/12/2011 14:45, Andreas Rossberg a écrit :
On 17 December 2011 00:24, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
I used to think this way about private names and proxies, and argued
for this position. However, I was wrong and it's a bad idea. Here's
why:
You might want to implement an object with a private field and a
public method like this:
let o = (function () { let n = new Name(); return { [n]: 0; get:
function() { return this[n]; }}})();
But, if we don't censor private names in proxies, this abstraction leaks!
Consider:
let p = new Proxy(...);
o.get.call(p);
Now the name is leaked to the proxy. And there's no way you can fix
this, without resorting to some other method of hiding things like
closures.
Hm, isn't this example rather demonstrating that the ability to do
self stealing -- i.e., the lack of lexical `this' -- is violating
basic abstraction principles (as we all know)?
This particular example used 'this', but similar examples may not.
-
let marker = (function(){
let n = new Name();
let counter = 0;
return {
mark: function(o){
o[n] = counter++;
}
readMark: function(o){
return o[n];
}
};
})();
marker.mark(maliciousProxy);
-
...and the name just leaked allowing a malicious proxy to mess with the
marking.
That is, in JS you have
to manually fix such abstractions using .bind on your methods (or
potential nicer alternatives in ES6). Arguably, the problem is not
proxies or private names (under David's semantics) per se.
But of course, we cannot really fix `this', so we introduce public
name conversion (and other ad-hoc complications surrounding private
names) as compatibility hacks that prevent blatant leaks for existing
JS idioms. It's not puristic, but it is convenient and pragmatically
safer.
Indeed. What do you think of the different alternative proposals
(especially regarding the ad-hoc complications you point out)?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Versioning?
On Mon, Dec 19, 2011 at 12:21 PM, Xavier MONTILLET xavierm02@gmail.com wrote: And what do you mean by opt-in for ES6 ? New syntax ? Everything in ES 6 ? Not everything. Let me try to explain the opt-in. ES6 must not break existing code. This is non-negotiable. Nobody will use a Web browser that breaks the Web. However, a few of the ES6 proposals are impossible to accept, for this very reason... unless there is an opt-in. Since no existing code contains an ES6 opt-in, any new features that are enabled by the opt-in can't break existing code. As I understand the current proposals, opt-in will be required for scripts that - use the new 'module' keyword, which isn't reserved in ES5; - expect (typeof null) to be null, rather than 'object' as in ES5; - need the top-level scope to be declarative, rather than tied to the global object as in ES5; or - declare functions in Blocks, with nice standard semantics, different from current browsers which all do it a little different. ...precisely because these are the features that could otherwise change the behavior of existing code. All other new features will be available whether you use the opt-in or not. Now: in order for TC39 to ditch the opt-in, they would have to either ditch these four features ... or somehow make the new syntax totally distinct from all existing code, so that existing code doesn't break. Here is what I might do: - keep modules, but change the syntax to eliminate the 'module' keyword, use an ES5 ReservedWord, or make 'module' a contextual keyword (lots of options here, none pretty); - give up on typeof null; - keep top-level declarative scope, but only in module code; - specify less-nice, more-Web-compatible semantics for functions in Blocks -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Versioning?
Le 20/12/2011 22:45, Jason Orendorff a écrit : As I understand the current proposals, opt-in will be required for scripts that (...) - need the top-level scope to be declarative, rather than tied to the global object as in ES5; Where is the proposal for this? I can't find it at http://wiki.ecmascript.org/doku.php?id=harmony:proposals David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
