On Apr 23, 2010, at 2:47 PM, Asen Bozhilov wrote:
However thanks for your reply!
No problem, your question about why ASI is not disabled by ES5 strict
mode was a good one!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Brendan Eich wrote:
On Apr 19, 2010, at 4:27 PM, Peter van der Zee wrote:
ES5 introduced the concept of directives, using perfectly fine
fallback with no side effects. This was, as far as the above goes,
perfect. Older implementations couldn't possibly trip over it since a
string literal
On Apr 23, 2010, at 1:24 PM, Asen Bozhilov wrote:
Brendan Eich wrote:
On Apr 19, 2010, at 4:27 PM, Peter van der Zee wrote:
ES5 introduced the concept of directives, using perfectly fine
fallback with no side effects. This was, as far as the above goes,
perfect. Older implementations
Brendan Eich wrote:
On Apr 23, 2010, at 1:24 PM, Asen Bozhilov wrote:
Brendan Eich wrote:
On Apr 19, 2010, at 4:27 PM, Peter van der Zee wrote:
ES5 introduced the concept of directives, using perfectly fine
fallback with no side effects. This was, as far as the above goes,
perfect. Older
On Apr 19, 2010, at 11:13 PM, Peter van der Zee wrote:
On Mon, Apr 19, 2010 at 11:25 PM, Brendan Eich bren...@mozilla.com
wrote:
On Apr 19, 2010, at 4:27 PM, Peter van der Zee wrote:
ES5 introduced the concept of directives, using perfectly fine
fallback with no side effects. This was, as
On Mon, Apr 19, 2010 at 11:25 PM, Brendan Eich bren...@mozilla.com wrote:
On Apr 19, 2010, at 4:27 PM, Peter van der Zee wrote:
ES5 introduced the concept of directives, using perfectly fine fallback
with no side effects. This was, as far as the above goes, perfect. Older
implementations
On Sat, Apr 17, 2010 at 12:34 PM, Asen Bozhilov asen.bozhi...@gmail.com wrote:
Erik Arvidsson wrote:
Unfortunately there are use case (although limited) that cannot be solved
without a mutable __proto__. Extending built *classes* is one such use case.
function HelloElement() {
var el =
On 17.04.2010 0:30, Tom Van Cutsem wrote:
The static methods are to avoid breaking the web by
injecting even
non-enumerable names into every object -- including the global
object --
via Object.prototype. Such injection can easily break
On Sun, Apr 18, 2010 at 2:45 PM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote:
On Sun, Apr 18, 2010 at 3:56 AM, Peter van der Zee e...@qfox.nl wrote:
would be ignored by older browsers. This seems bad because downrev
browsers would try to run the script content, unless you use server-side
On Apr 19, 2010, at 4:27 PM, Peter van der Zee wrote:
Basically, this means we cannot introduce new language constructs or
syntax because older implementations will trip over the code with no
way to recover. Furthermore, for various reasons it seems feature
detection is favored over
On Fri, Apr 16, 2010 at 13:30, Tom Van Cutsem to...@google.com wrote:
The static methods are to avoid breaking the web by injecting even
non-enumerable names into every object -- including the global object --
via Object.prototype. Such injection can easily break user-controlled
object
The problem is just that parts of the ES5 Object API is useful outside of
meta programming and for everyday use we need syntactic sugar or a better
API. Passing a map of property descriptors to Object.create might be
convenient for meta programming but for everyday programming it adds a lot
2010/4/19 Brendan Eich bren...@mozilla.com:
On Apr 19, 2010, at 4:27 PM, Peter van der Zee wrote:
Basically, this means we cannot introduce new language constructs or
syntax because older implementations will trip over the code with no way to
recover. Furthermore, for various reasons it seems
On Apr 19, 2010, at 3:20 PM, Erik Arvidsson wrote:
On Sat, Apr 17, 2010 at 02:03, Dmitry A. Soshnikov dmitry.soshni...@gmail.com
wrote:
But if you insist that it is a bad practice, it's easy to manage --
just
forbid then augmentations of built-ins completely that programmers
have no
On Apr 19, 2010, at 5:15 PM, Erik Corry wrote:
2010/4/19 Brendan Eich bren...@mozilla.com:
On Apr 19, 2010, at 4:27 PM, Peter van der Zee wrote:
Basically, this means we cannot introduce new language constructs or
syntax because older implementations will trip over the code with
no way to
2010/4/20 Brendan Eich bren...@mozilla.com:
On Apr 19, 2010, at 5:15 PM, Erik Corry wrote:
2010/4/19 Brendan Eich bren...@mozilla.com:
On Apr 19, 2010, at 4:27 PM, Peter van der Zee wrote:
Basically, this means we cannot introduce new language constructs or
syntax because older
On Apr 19, 2010, at 5:50 PM, Erik Corry wrote:
I like my odds ratios bigger, thank you very much.
You are welcome.
The point is that EphemeronTables may not make Harmony, but Names
could. Coupling the latter to the former multiplies risk of neither
making it.
/be
To paraphase Charlton Heston - From my cold, dead hands...
Three cheers for polymorphism!
Cheers,
- Bill
On Apr 19, 2010, at 7:31 PM, Brendan Eich wrote:
On Apr 19, 2010, at 3:20 PM, Erik Arvidsson wrote:
On Sat, Apr 17, 2010 at 02:03, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com
On Sun, Apr 18, 2010 at 7:19 AM, Brendan Eich bren...@mozilla.com wrote:
On Apr 17, 2010, at 6:07 PM, Peter van der Zee wrote:
To be solved:
- Allow non-string-property keys
- Allow hidden properties, non-enumerable, not generically accessible
(like stringed keys are now). To be honest,
Hello Brendan,
Saturday, April 17, 2010, 7:04:52 PM, you wrote:
On Apr 17, 2010, at 7:25 AM, Dmitry Soshnikov wrote:
Excuse me, seems I missed something. I thought first that you
mentioned them in private viewpoint, but in this sentence you say
that names will help to place standard
On Sun, Apr 18, 2010 at 3:56 AM, Peter van der Zee e...@qfox.nl wrote:
would be ignored by older browsers. This seems bad because downrev
browsers would try to run the script content, unless you use server-side
version detection to ship this only to uprev browsers.
How would this work in
On Apr 18, 2010, at 7:13 AM, Dmitry A. Soshnikov wrote:
This desugared view with enclosing anonymous function means that
getPrototype name is available only in scope of of this function and
when this scope ends, getPrototype name will be GC'ed (and related
object too -- {value: ...})
That
On Apr 18, 2010, at 3:56 AM, Peter van der Zee wrote:
On Sun, Apr 18, 2010 at 7:19 AM, Brendan Eich bren...@mozilla.com
wrote:
On Apr 17, 2010, at 6:07 PM, Peter van der Zee wrote:
To be solved:
- Allow non-string-property keys
- Allow hidden properties, non-enumerable, not generically
On Sun, Apr 18, 2010 at 3:28 PM, Brendan Eich bren...@mozilla.com wrote:
On Apr 18, 2010, at 3:56 AM, Peter van der Zee wrote:
On Sun, Apr 18, 2010 at 7:19 AM, Brendan Eich bren...@mozilla.com wrote:
On Apr 17, 2010, at 6:07 PM, Peter van der Zee wrote:
To be solved:
- Allow
On Apr 18, 2010, at 10:00 AM, Peter van der Zee wrote:
This could be fixed by some kind detection scheme for these
directives.
You can't detect new syntax except by embedding it in a string and
eval'ing the string inside a try/catch.
You can add the directive and detect whether it has
Title: Re: Approach of new Object methods in ES5
Hello Brendan,
Sunday, April 18, 2010, 5:01:52 PM, you wrote:
On Apr 18, 2010, at 7:13 AM, Dmitry A. Soshnikov wrote:
This desugared view with enclosing anonymous function means that
"getPrototype" name is available onl
On Fri, Apr 16, 2010 at 9:51 AM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
On Fri, Apr 16, 2010 at 08:43, Brendan Eich bren...@mozilla.com wrote:
ES4 since Waldemar's 1998-era JS2 work was concerned with the problem of
versioning APIs implied by (1) greatly, and not just adding
On Fri, Apr 16, 2010 at 8:58 PM, Brendan Eich bren...@mozilla.com wrote:
Another Harmony idea:
http://wiki.ecmascript.org/doku.php?id=strawman:names for unforgeable
property names not equated to any string. These cannot collide, and with
sugar to let them be used with . (not only in computed
Hello David,
Saturday, April 17, 2010, 2:01:09 AM, you wrote:
var foo = {x: 10, :y: 20} // although...
where :y - is your private Name symbol.
Choose any:
...
and so on, there are many interesting naming conventions (which are
not yet borrowed by backward compatibility).
Any of
On Apr 17, 2010, at 7:25 AM, Dmitry Soshnikov wrote:
Excuse me, seems I missed something. I thought first that you
mentioned them in private viewpoint, but in this sentence you say
that names will help to place standard methods/properties in built-
ins prototypes avoiding naming collisions.
On Apr 17, 2010, at 12:06 AM, David Herman wrote:
A Name object that is required to be a leaf in the live object
graph has the advantage that it can be strongly referenced by the
implementation when used as a property name (key), without
reference cycles being possible. Implementations
But I meant not only naming convention, but that by this naming
convention this properties (symbols) will be hidden -- just like in
Python, when _ and __ properties become unavailable outside...
You still haven't specified what outside means. What does get to see a hidden
name and what
On Apr 17, 2010, at 11:04 AM, Brendan Eich wrote:
On Apr 17, 2010, at 7:25 AM, Dmitry Soshnikov wrote:
Excuse me, seems I missed something. I thought first that you
mentioned them in private viewpoint, but in this sentence you say
that names will help to place standard methods/properties
On 2010-04-17, at 00:06, David Herman wrote:
PS Still, I have my doubts about using any such mechanisms for versioning.
The topic is not versioning in full, rather hiding properties added to
built-in prototypes.
I had the impression Tucker was thinking about versioning, but I may have
There are multiple levels of opt-in versioning:
(1) versioning of the language itself
(2) language support for versioning of libraries
I agree with what you're saying wrt (1), but wrt (2), feature detection is
feasible, and I'd think more tractable than version detection.
Dave
On Apr 17,
Erik Arvidsson wrote:
Unfortunately there are use case (although limited) that cannot be
solved without a mutable __proto__. Extending built *classes* is one
such use case.
function HelloElement() {
var el = document.createElement('div');
el.__proto__ = HelloElement.prototype;
el.text =
On Sat, Apr 17, 2010 at 11:40 PM, Brendan Eich bren...@mozilla.com wrote:
On Apr 17, 2010, at 3:03 PM, David Herman wrote:
There are multiple levels of opt-in versioning:
(1) versioning of the language itself
(2) language support for versioning of libraries
I agree with what you're
On Apr 17, 2010, at 6:07 PM, Peter van der Zee wrote:
To be solved:
- Allow non-string-property keys
- Allow hidden properties, non-enumerable, not generically
accessible (like stringed keys are now). To be honest, I'm still not
100% clear on this one.
I don't see how these two differ.
Hello,
I'd like to clarify the question about approach used in ECMA-262-5
regarding the code design for new methods of Object constructor.
I've read the section Attribute Control API Design and Rationale of
Proposed ECMAScript 3.1 Static Object Functions: Use Cases and
Rationale document:
On 16 April 2010 13:13, Dmitry A. Soshnikov dmitry.soshni...@gmail.com wrote:
I think that approach used in ECMA-262-5 for new object methods contradicts
ES nature.
+1
The new API seems quite random. I hope that JavaScript is not turning into PHP.
-dean
On Apr 16, 2010, at 5:28 AM, Dean Edwards wrote:
On 16 April 2010 13:13, Dmitry A. Soshnikov dmitry.soshni...@gmail.com
wrote:
I think that approach used in ECMA-262-5 for new object methods
contradicts ES nature.
+1
The new API seems quite random. I hope that JavaScript is not
On Fri, Apr 16, 2010 at 2:28 PM, Dean Edwards dean.edwa...@gmail.comwrote:
On 16 April 2010 13:13, Dmitry A. Soshnikov dmitry.soshni...@gmail.com
wrote:
I think that approach used in ECMA-262-5 for new object methods
contradicts ES nature.
+1
The new API seems quite random. I hope that
2010/4/16, Dmitry A. Soshnikov dmitry.soshni...@gmail.com:
By the way, it is also petty that there's no ability to change prototype
and there is only get function for that; __proto__ extension in this
case was better.
Especially when I want to change only [[Prototype]] and keep values of
On Fri, Apr 16, 2010 at 4:18 PM, Asen Bozhilov asen.bozhi...@gmail.comwrote:
2010/4/16, Dmitry A. Soshnikov dmitry.soshni...@gmail.com:
And I have a question. Why ES5 give control on values of internal
attributes? What will improve that? Save augmentation of built-in?
Good design of JS
On Apr 16, 2010, at 7:17 AM, Peter van der Zee wrote:
On Fri, Apr 16, 2010 at 2:28 PM, Dean Edwards
dean.edwa...@gmail.com wrote:
On 16 April 2010 13:13, Dmitry A. Soshnikov dmitry.soshni...@gmail.com
wrote:
I think that approach used in ECMA-262-5 for new object methods
contradicts ES
On Apr 16, 2010, at 7:18 AM, Asen Bozhilov wrote:
2010/4/16, Dmitry A. Soshnikov dmitry.soshni...@gmail.com:
By the way, it is also petty that there's no ability to change
prototype
and there is only get function for that; __proto__ extension in
this
case was better.
Especially when I
On Apr 16, 2010, at 8:43 AM, Brendan Eich wrote:
2. Extending the language's syntax with:
(a) No versioning required in the absence of new reserved
identifiers, since new syntax cannot break existing content.
Of course I glossed over how new syntax *could* make invalid content
start
On Apr 16, 2010, at 7:18 AM, Asen Bozhilov wrote:
2010/4/16, Dmitry A. Soshnikov dmitry.soshni...@gmail.com:
By the way, it is also petty that there's no ability to change
prototype
and there is only get function for that; __proto__ extension in
this
case was better.
Especially when I
On Fri, Apr 16, 2010 at 08:43, Brendan Eich bren...@mozilla.com wrote:
ES4 since Waldemar's 1998-era JS2 work was concerned with the problem of
versioning APIs implied by (1) greatly, and not just adding properties:
deleting and redefining too. ES4 proposed namespaces (like Common Lisp
On Apr 16, 2010, at 12:51 PM, Erik Arvidsson wrote:
On Fri, Apr 16, 2010 at 08:43, Brendan Eich bren...@mozilla.com
wrote:
ES4 since Waldemar's 1998-era JS2 work was concerned with the
problem of versioning APIs implied by (1) greatly, and not just
adding properties: deleting and
On Apr 16, 2010, at 12:58 PM, Brendan Eich wrote:
However, ES5 *does* allow libraries to bind non-enumerable
properties of prototype objects. This is half of the solution, and
if the prototype in question is Object.prototype, or perhaps even
Oops, missing not: ... if the prototype in
On Fri, Apr 16, 2010 at 09:06, Brendan Eich bren...@mozilla.com wrote:
On Apr 16, 2010, at 7:18 AM, Asen Bozhilov wrote:
2010/4/16, Dmitry A. Soshnikov dmitry.soshni...@gmail.com:
By the way, it is also petty that there's no ability to change prototype
and there is only get function for
On Apr 16, 2010, at 1:11 PM, Erik Arvidsson wrote:
On Fri, Apr 16, 2010 at 09:06, Brendan Eich bren...@mozilla.com
wrote:
... settable __proto__, apart from the object initialiser use case
(i.e., on a new object not yet reachable, analogous to ES5's
Object.create), is a terrible idea.
On Fri, Apr 16, 2010 at 10:28, Brendan Eich bren...@mozilla.com wrote:
Object.create is the standardized form of Crock's beget. It's not bad for
an API, albeit longer than b-e-g-e-t (but also less likely to collide,
although collide it did with TIBET's create method on Object).
My main
On 2010-04-16, at 13:07, Brendan Eich wrote:
Another Harmony idea: http://wiki.ecmascript.org/doku.php?id=strawman:names
for unforgeable property names not equated to any string. These cannot
collide, and with sugar to let them be used with . (not only in computed
property accesses using
Name sounds like a stripped-down uninterned symbol (http://bit.ly/bY3Jkg) to
me.
Yup.
It's an object with a magic attribute that says, unlike any other object you
might try to use it as a property name, it is not coerced into a string
first. And it is compared by identity when looked
On 16/04/2010 14:48, Brendan Eich wrote:
On Apr 16, 2010, at 5:28 AM, Dean Edwards wrote:
On 16 April 2010 13:13, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com wrote:
I think that approach used in ECMA-262-5 for new object methods
contradicts ES nature.
+1
The new API seems quite random.
2010/4/16, Brendan Eich bren...@mozilla.com:
On Apr 16, 2010, at 7:18 AM, Asen Bozhilov wrote:
Special thanks for your response!
Especially when I want to change only [[Prototype]] and keep values of
other internal properties and methods for that object.
I write this having designed and
On 2010-04-16, at 14:31, David Herman wrote:
Tucker: if the property-nameness attribute weren't transferrable but names
were objects with property tables, do you think that would be powerful
enough? Or would you want the ability to define custom constructors, e.g.:
function
On Fri, Apr 16, 2010 at 9:48 PM, P T Withington p...@pobox.com wrote:
On 2010-04-16, at 14:31, David Herman wrote:
Tucker: if the property-nameness attribute weren't transferrable but
names were objects with property tables, do you think that would be powerful
enough? Or would you want the
On Fri, Apr 16, 2010 at 7:11 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
On Fri, Apr 16, 2010 at 09:06, Brendan Eich bren...@mozilla.com wrote:
On Apr 16, 2010, at 7:18 AM, Asen Bozhilov wrote:
2010/4/16, Dmitry A. Soshnikov dmitry.soshni...@gmail.com:
By the way, it is also
Hello David,
Friday, April 16, 2010, 10:31:07 PM, you wrote:
Name sounds like a stripped-down uninterned symbol (http://bit.ly/bY3Jkg) to
me.
Yup.
It's an object with a magic attribute that says, unlike any other object you
might try to use it as a property name, it is not coerced into
62 matches
Mail list logo
