Le 16/03/2011 08:59, Tom Van Cutsem a écrit :
David,
I agree that Proxy.isProxy (or Object.isProxy) is strictly a better
name than Proxy.isTrapping.
I also agree that in developer-facing documentation, using the terms
proxy vs regular object instead of trapping vs fixed proxy is
better.
Le 16/03/2011 09:11, Tom Van Cutsem a écrit :
Hi,
I have no objections to the use cases you're proposing, but in the
interest of keeping the Proxy.createFunction method somewhat simple,
why isn't the following sufficient:
// [[Construct]]-less functions:
var f =
Le 16/03/2011 10:25, Tom Van Cutsem a écrit :
David,
This open issue is indeed one that merits further discussion here.
Some thoughts and comments:
* I think we did come to an agreement that custom property attributes
were seen as very useful for communicating new kinds of meta-data
about
+1 to standardizing the timer family.
I always thought this wasn't in because the specification didn't have
any asynchronism and specifying timers would open Pandora's box.
- peter
On Fri, Mar 18, 2011 at 1:51 PM, David Bruant bru...@enseirb-matmeca.frwrote:
Hi,
_Foreword_
Each time I
The __proto__ property has been around for ~13yrs and is now a de
facto standard supported by Chrome, Firefox, Safari, Opera, Adobe
Flash, Adobe AIR, Rhino, Ringo, Narwhal, Node.js.
It's available on desktops, mobile phones, tablets, and even eReaders.
The __proto__ property is a powerful
On Fri, Mar 18, 2011 at 9:14 AM, John-David Dalton
john.david.dal...@gmail.com wrote:
The __proto__ property is a powerful language feature that cannot be
reproduced through any existing part of the language.
Current proposals like,
http://wiki.ecmascript.org/doku.php?id=strawman:array_create,
I believe the current hope is to kill off __proto__ as quickly as is possible.
I'm not taking a position in this argument, this is just my current
understanding.
That said your examples environments that support it is slightly misleading as
there's only a few JS engines being used between
@Oliver
That said your examples environments that support it is slightly misleading
as there's only a few JS engines being used between them: Caraken
(Opera person is this correct?), JavaScriptCore, SpiderMonkey and V8. AIR
uses webkit so pulls in JSC, and presumably ActionScript as well,
Hi David, I think this is an excellent idea. I will add it to the
concurrency strawman.
However, since the concurrency strawman is on he agenda for May and I'm
currently overloaded preparing for next week's March meeting, I won't get to
this till April. Once I have a draft, further feedback would
I see the use of setting prototypes at runtime, but with proxies I
think it is not needed, and .__proto__ is commonly used in attacks
(webkit based browser have a couple of attacks still viable using this
to get to various things). For example a prototype injection:
function foo() {};var tmp =
On 18 March 2011 17:25, Wes Garland w...@page.ca wrote:
Right: the barrier to setTimeout functionality is that ECMAscript does not
define a concurrency model.
If we can define a concurrency model, then we can build setTimeout.
Two things off the top of my head to consider:
- timer
On Fri, Mar 18, 2011 at 9:29 AM, John-David Dalton
john.david.dal...@gmail.com wrote:
@Mike Shaver
For other possible uses please check out:
http://msdn.microsoft.com/en-us/scriptjunkie/gg278167
https://github.com/jdalton/fusebox#readme
Those all look like they are needing
As I understand it, this type of thing was kept out of the language
proper intentionally, because of its strong dependency on host
environment. Some host environments may require tight and overriding
control of any event handling system, and exactly which types of
events (such as timeouts) are
For symmetry with
Object.create, you might want Boolean.create, Date.create and so
forth, but that's still initialization-time, and TBH I would be
surprised if there were actually many collisions between libraries
that augment those prototypes.
In the Script Junkie article I cover a few
There is a general problem of supporting creation of special behavior objects
(EG, Boolean, RegExp, anything fronted by a Proxy(??)) with arbitrary
prototypes that I'm looking at for a Harmony strawman. However, I think in
practice that this occurs very rarely for anything other than Array.
Array create seems like a good interface for that particular use case even if
the general solution that
encompasses things other than Array ended up being something different.
Limiting it to Array.create seems shortsighted. It's useful for
Strings, Numbers, RegExp, and others.
Adding
The point is that there are comprehensive solutions in the works that can be
part of ES6, but those will take some time to reach consensus. If the
community is looking for an immediate alternative to the most common use case
of LHS __proto__ that is not supported by ES5, then Array.create is
On Mar 18, 2011, at 10:02 AM, John-David Dalton wrote:
For symmetry with
Object.create, you might want Boolean.create, Date.create and so
forth, but that's still initialization-time, and TBH I would be
surprised if there were actually many collisions between libraries
that augment those
Le 18/03/2011 18:02, John-David Dalton a écrit :
Date.create, Function.create and the like clutters the API. I would be
for a more generic Object.setPrototypeOf() addition.
http://es5.github.com/#x15.2.3.2
The problem is that it would break an invariant of the ECMAScript
language which is that
There is a general problem of supporting creation of special behavior
objects
Yes, I think it would be ok to assume that the spirit of __proto__ can
be achieved by a solution that sets the [[Prototype]] at creation.
This would possibly help with WebKit's security concerns while not
On 3/18/11 1:33 PM, Oliver Hunt wrote:
It also extends trivially to non-es objects, eg. Object.subclass(Image) or
somesuch in the DOM, etc.
Note that currently WebIDL calls for that to not work (in the sense that
it examines the [[Class]] of DOM objects, so if you Object.create(new
You wouldn't need to reset the __proto__ of result if construction and
initialization were separated, if the __proto__ of objects were only set by
`new constructor`. If `constructor.apply` did _not_ create a new object, only
initialized it according to the arguments.
[The pattern you give is
I think so -- my proposal doesn't take instances, nor produce instances, it
takes the constructor function (Image is one of a handful of DOM constructor
that can actually be used to construct things) and returns a new constructor
that will produce an instances of the target object with a
On Fri, Mar 18, 2011 at 10:45 AM, Oliver Hunt oli...@apple.com wrote:
I think so -- my proposal doesn't take instances, nor produce instances, it
takes the constructor function (Image is one of a handful of DOM constructor
that can actually be used to construct things) and returns a new
I think Oliver's original formulation is more correct, but regardless this
really would have to be specified using ES5 pseudo code.
This is along the path of what I was calling a generalized solution to the
problem and as such I think it needs deeper/longer consideration to be sure we
have it
I think Oliver's original formulation is more correct, but regardless this
really would have to be specified using ES5 pseudo code.
This is along the path of what I was calling a generalized solution to the
problem and as such I think it needs deeper/longer
consideration to be sure we have
Can you provide some concrete real world examples of setting alternative
prototypes on Number, Boolean, and String instances? RegExp too, but that's a
different beast. Also I don't believe that oliver's solution helps you much
for functions.
On Mar 18, 2011, at 12:12 PM, John-David Dalton
Le 18/03/2011 18:00, Oliver Hunt a écrit :
I kind of dislike the proliferation of .create methods. It's seems
inelegant. What if we had (use __proto__ for semantic description)
Object.subclass = function(constructor) {
use strict;
function cons() {
var result =
Hi Robert,
I've put some thought into this topic, and I have a few comments for you
(see below).
On Fri, Mar 18, 2011 at 10:09 AM, Robert Accettura rob...@accettura.comwrote:
I'll prefix this by saying I'm not entirely certain if this should be
ECMA vs. HTML5 or dual track similar to the
On Mar 18, 2011, at 10:02 AM, John-David Dalton wrote:
For symmetry with
Object.create, you might want Boolean.create, Date.create and so
forth, but that's still initialization-time, and TBH I would be
surprised if there were actually many collisions between libraries
that augment those
On Mar 18, 2011, at 9:20 AM, Oliver Hunt wrote:
I believe the current hope is to kill off __proto__ as quickly as is
possible. I'm not taking a position in this argument, this is just my
current understanding.
This makes it sound quick. There's no way to guarantee that.
Also, to kill it
On Mar 18, 2011, at 1:08 PM, John-David Dalton wrote:
You are missing shaver's point that initiializing is not the same as
reassigning later on a created and reachable object.
No, I got it.
Sorry I didn't read ahead -- everyone seems to get this point now, which is
progress.
Did I miss
Did I miss new, mutating uses of __proto__ in PrototypeJS?
Nope, nothing new in PrototypeJS.
Mutating use of __proto__ can be found in
https://github.com/jdalton/fusejs as 1 of the 3 techniques used.
The __proto__ fork is only being used by Safari (because of a loong
time iframe bug
On Mar 18, 2011, at 12:33 PM, John-David Dalton wrote:
Can you provide some concrete real world examples of setting alternative
prototypes on Number, Boolean, and String instances? RegExp too, but that's
a different beast. Also I don't believe that oliver's solution helps you
much for
JFTR, I remember the previous the same discussion(s) and mentioned
earlier the thing similar to this `Object.subclass`, though, just with
providing an ability to specify the [[Class]] for `Object.create`. E.g.
for a unclassified inheritance:
let foo = Object.create(Array.prototype, Array,
I think I understand what you doing here, especially for Array but I don't
think it really addresses my Number, Boolean, String question.
Instances of those instances usually aren't created via explicit constructor
calls but by implicit conversions that the ES5 spec. hardwires
to the
Le 18/03/2011 18:00, Oliver Hunt a écrit :
I kind of dislike the proliferation of .create methods. It's seems
inelegant. What if we had (use __proto__ for semantic description)
Object.subclass = function(constructor) {
use strict;
function cons() {
var result =
On Fri, Mar 18, 2011 at 1:53 PM, John-David Dalton
john.david.dal...@gmail.com wrote:
Ya, some people have that reaction at first, but after use it's not
bad. Most of the time you create a string or value once then pass
around the variable.
Because these sandboxed natives chain, usage is
But AIUI the point of sandboxing is to keep different libraries from
stepping on each other's toes, and AFAICT such libraries use literals
(string, array, object and regexp) quite liberally.
Sandbox natives are used so FuseJS plays well with others while allowing the
extension/modification of
On Fri, Mar 18, 2011 at 5:11 PM, John-David Dalton
john.david.dal...@gmail.com wrote:
Extending the Object.prototype is a compatibility nightmare
It was a compatibility nightmare when people didn't namespace, and
when you couldn't make non-enumerable properties. Using a namespace
for additions
The private names proposal would private another way to avoid creating
extension methods with conflicting names
http://wiki.ecmascript.org/doku.php?id=strawman:private_names
On Mar 18, 2011, at 5:14 PM, Mike Shaver wrote:
On Fri, Mar 18, 2011 at 5:11 PM, John-David Dalton
It was a compatibility nightmare when people didn't namespace, and
when you couldn't make non-enumerable properties. Using a namespace
for additions to the prototype chain and using ES5's defineProperty to
keep those additions from affecting enumeration behaviour seems like
it overcomes
On Mar 18, 2011, at 9:25 AM, Wes Garland wrote:
Right: the barrier to setTimeout functionality is that ECMAscript does not
define a concurrency model.
If we can define a concurrency model, then we can build setTimeout.
See my previous reply. JS with setTimeout has only pseudo-concurrency
On Mar 18, 2011, at 12:56 PM, Shabsi Walfish wrote:
I'm not convinced that this use case, or any other use case I could think of
for the web (with the possible exception of DRM/encryption on streaming
media), would really benefit from speed. On the whole, you would most likely
be
On Mar 18, 2011, at 5:54 AM, Peter van der Zee wrote:
+1 to standardizing the timer family.
I always thought this wasn't in because the specification didn't have any
asynchronism and specifying timers would open Pandora's box.
How so? I created JS and its run-to-completion execution model
On Mar 15, 2011, at 6:43 PM, David Bruant wrote:
Unfortunately, currently, on FF4, the property descriptor is rewritten, but
with my comments on the code, you can see what results I would expect. But
the potential of having my library-specific property descriptor format is
here.
Thanks
On Mar 18, 2011, at 1:46 PM, Dmitry A. Soshnikov wrote:
Other examples:
https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/create.js
Thanks, this is helpful.
So the mutable __proto__ (no matter in which name and view) can be
standardized only if (1) no security issues,
"Asynchronous" has a good (Greek) meaning but it is overused and abused. JS setTimeout is in fact not truly "without time" but more nearly "synchronous" to some resolution lower bound (4ms in the new HTML5 world), or "isochronous" in some virtual timeline.With setTimeout and setInterval and
On Mar 18, 2011, at 5:11 PM, John-David Dalton wrote:
You can even create more than one of say the Array
constructor as with fuse.Array and fuse.dom.NodeList (also an Array
constructor but with DOM methods on it's prototype)
And this **is** possible, in part, because of __proto__.
But to
On Mar 18, 2011, at 4:53 PM, Brendan Eich wrote:
On Mar 18, 2011, at 12:56 PM, Shabsi Walfish wrote:
I'm not convinced that this use case, or any other use case I could think of
for the web (with the possible exception of DRM/encryption on streaming
media), would really benefit from
Le 19/03/2011 01:11, Brendan Eich a écrit :
On Mar 15, 2011, at 6:43 PM, David Bruant wrote:
Unfortunately, currently, on FF4, the property descriptor is
rewritten, but with my comments on the code, you can see what results
I would expect. But the potential of having my library-specific
On Fri, Mar 18, 2011 at 4:53 PM, Brendan Eich bren...@mozilla.com wrote:
On Mar 18, 2011, at 12:56 PM, Shabsi Walfish wrote:
I'm not convinced that this use case, or any other use case I could think
of for the web (with the possible exception of DRM/encryption on streaming
media), would
On Mar 18, 2011, at 6:44 PM, Shabsi Walfish wrote:
On Fri, Mar 18, 2011 at 4:53 PM, Brendan Eich bren...@mozilla.com wrote:
In support of Robert's point, we have Firefox Sync [1], which client-side
encrypts many blocks of user data (not just passwords; cookies, history,
etc.) to hide it
On Mar 18, 2011, at 9:44 PM, Shabsi Walfish wrote:
On Fri, Mar 18, 2011 at 4:53 PM, Brendan Eich bren...@mozilla.com wrote:
On Mar 18, 2011, at 12:56 PM, Shabsi Walfish wrote:
I'm not convinced that this use case, or any other use case I could think of
for the web (with the possible
On Mar 18, 2011, at 7:18 PM, David Bruant wrote:
As I said, one way to bring setTimeout would be to standardized a
lower-level mechanism based on which setTimeout could be implemented.
Now you've got two problems...
It is not precisely understood why setTimeout(..., 0) breaks the web if run
But to get back to shaver's point: you are requiring a stylized, non-standard,
popular-library-incompatible dialect of JS to be used from the start to work
inside FuseJS's sandboxes, IIUC. Right?
Mike was getting OT onto the specifics and merits of sandboxed natives/FuseJS.
I was originally
On Mar 18, 2011, at 7:27 PM, John-David Dalton wrote:
But to get back to shaver's point: you are requiring a stylized,
non-standard,
popular-library-incompatible dialect of JS to be used from the start to work
inside FuseJS's sandboxes, IIUC. Right?
Mike was getting OT onto the specifics
There's LOTS of sites out there that still (unfortunately) do unsafe
overwriting/overloading of the native's prototypes. For instance, just a few
months ago, I ran across a site that was creating a Array.prototype.push()
implementation that was incompatible with the standard implementation.
Speaking as someone who has written and currently maintains a
*synchronous* server-side JavaScript environment (based on V8), I attest
to the statement that I would *not* like it if V8 had `setTimeout()`
(...etc) in it, because unless V8 were going to take care of that
completely black-box for
On Fri, Mar 18, 2011 at 4:26 PM, Brendan Eich bren...@mozilla.com wrote:
On Mar 18, 2011, at 9:25 AM, Wes Garland wrote:
Right: the barrier to setTimeout functionality is that ECMAscript does
not define a concurrency model.
If we can define a concurrency model, then we can build
On 3/19/11 12:24 AM, Mark S. Miller wrote:
Is this 4ms codified in spec language somewhere? I couldn't find it by
casual searching.
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-windowtimers-settimeout
step 5 (though note also step 9, which is the part that makes
Kyle;
On Fri, Mar 18, 2011 at 11:53 PM, Kyle Simpson get...@gmail.com wrote:
Speaking as someone who has written and currently maintains a *synchronous*
server-side JavaScript environment (based on V8),
I resemble this description, except that my platform is built on
SpiderMonkey rather than
On Mar 18, 2011, at 9:31 PM, Mark S. Miller wrote:
On Fri, Mar 18, 2011 at 4:53 PM, Brendan Eich bren...@mozilla.com wrote:
Mark Miller alluded to a crypto API task group without Ecma TC39. I'm open to
it, provided we can include some of the domain experts who have participated
on this list
On Mar 18, 2011, at 8:53 PM, Kyle Simpson wrote:
What I was saying is, if I run this program through V8 right now (with its
theoretical future support of setTimeout() included), then what will happen:
function fn() {
print(hello);
}
for (var i=0; i10; i++) {
setTimeout(fn,i*1000);
}
On Mar 18, 2011, at 9:43 PM, Wes Garland wrote:
I don't have breaks the web data, but executing f before setTimeout()
returns (rather than wait for us to get back in the event loop) changes the
semantics of the program. This might seem obvious, but I have seen the
analogue in suggestions
65 matches
Mail list logo
