Re: ES3.1 Object static methods rationale document
2008/7/16 Allen Wirfs-Brock <[EMAIL PROTECTED]>:
> I've up loaded to the wiki a new document titled: "Proposed ECMAScript 3.1
> Static Object Functions: Use Cases and Rationale"
I've got one objection to Object.getPrototypeOf: It allows inspection
and modification of prototype chains established like this:
function F(){}
/* add some prototype properties here */
newObj=new F;
F.prototype={constructor:F};
In ES3.0, this allows you to create unexposed and protected prototype
chains. There's no way to recover newObj.[[Prototype]] once
F.prototype has been changed in ES3.0 code. Granted, I've never seen
this pattern used in production code except incidentally, but it's a
guarantee that ES3.0 does have nonetheless and I could see myself
using it if I really wanted to protect an object's prototype from
being modified.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: for-in statement: null and undefined
On 03/07/2008, Kent Hansen <[EMAIL PROTECTED]> wrote: > By the way, in the ES4 reference implementation, iterating over strings > is a no-op as well; implementation bug, or are string properties not > enumerable in ES4? "X".hasOwnProperty(0) returns false, too. IIRC, this is the way it goes: A string cannot have properties itself. The temporary String object created when calling a method can have properties, but that String object is never returned from one of the ES3 (or to my knowledge ES4) methods and can thus only be returned from custom methods on the String prototype. This means that you're not likely to encounter a String object derived from a string unless you have author code that persists the temporary. The index access on a string doesn't work as property access but instead like a custom catch-all getter. > [1] > > http://www.ecmascript.org/license.php?file=es4-pre-release.M2.linux-x86.tar.gz > [2] http://wiki.ecmascript.org/doku.php?id=proposals:bug_fixes > [3] > > http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:tc39-es31-draft02jul08.pdf > [4] http://www.crockford.com/javascript/recommend.html > [5] http://www.ecmascript.org/es4/spec/incompatibilities.pdf -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: More string indexing semantics issues
On 25/06/2008, liorean <[EMAIL PROTECTED]> wrote: > Also, while String objects are created as temporaries when looking up > a property on a string, how many of those properties or methods > actually return a String object? The only situation I can think of off > the top of my head where you're going to actually have a String object > to deal with in ES3 is if you're extending the String.prototype object > with new methods. A distinction I was going to make there fell away when I rewrote an awkward formulation... s/String object to deal with/String object that you haven't explicitly created using "new String" to deal with/ -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: More string indexing semantics issues
> On Wed, Jun 25, 2008 at 3:15 PM, liorean <[EMAIL PROTECTED]> wrote:
> > Well, the way I think about String objects and strings:
> > - A string can't have properties of it's own at all, i.e. can be
> > thought of as having a noop setter and a custom getter for indices and
> > length. Any property not found by the getter should get delegated to
> > String.prototype.
> > - A String object is just a normal object delegating to a string.
> > (Could probably reuse the [[Prototype]] internal property if
> > implemented that way...) Thus, any properties set are placed on the
> > wrapper object and would as a result of that shadow the getter and
> > setter on the string.
>
>
> That's not how they work today, though, at least as far as the .length
> property goes:
>
> js> s = new String("foo")
> foo
> js> s.length
> 3
> js> s.length = 5
> 5
> js> s.length
> 3
> js>
>
> And of course it has to delegate to an object that has all the right
> methods on it.
Yes, I had thought of that too, but then I had already pressed the
send button...
> Are "numerically-named" properties >= length settable?
In saf3.1.1, ff3.0 and op9.50 they are, yes.
> > Neither the direct access of characters in the string by indiced
> > property lookup nor the use of String objects is common, so the
> > overlap is in all probability diminutive.
>
> Direct use of characters is pretty common, I think, but you sound like
> you are stating fact rather than opinion, so I'm prepared to be swayed
> by your data. String objects are very commonly created[*], by people
> calling methods or accessing properties like .length on string
> primitives.
I'm not stating that from any collected data, no. It was purely based
on three things:
- The only scripts I have seen using it both happen to be made by
advanced coders and happen to not have IE in their target audience for
some reason (extension, widget, greasemonkey script, userjs,
bookmarklet for some specific browser etc.).
- IE does not support it so logically it wouldn't be present in very
much code on the web.
- I can't recall ever seeing anybody on a forum or a mailing list
actually having a problem related to use of index lookup directly on
strings. And I'm sure that if it was common outside the developers
that do not have IE in their target audience at all, then there would
be people having trouble with it.
Also, while String objects are created as temporaries when looking up
a property on a string, how many of those properties or methods
actually return a String object? The only situation I can think of off
the top of my head where you're going to actually have a String object
to deal with in ES3 is if you're extending the String.prototype object
with new methods.
> [*] we optimize the object creation away there for built-ins, and I
> believe that WebKit is about to do the same thing, but that doesn't --
> can't! -- affect the semantics of object creation, and the
> relationship to String.prototype.
Yes, I know my way of looking at it is not quite what is happening.
But for a script writer, it's a good enough model of thought about the
relation between the primitive and compound objects.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: More string indexing semantics issues
On 25/06/2008, Allen Wirfs-Brock <[EMAIL PROTECTED]> wrote: > I think in this case I have to agree with Maciej...Webkit appears to be > doing the "right thing" by making a string appear to consistently have a set > of numerically named readonly properties that exactly correspond to the > elements of the string value. Well, the way I think about String objects and strings: - A string can't have properties of it's own at all, i.e. can be thought of as having a noop setter and a custom getter for indices and length. Any property not found by the getter should get delegated to String.prototype. - A String object is just a normal object delegating to a string. (Could probably reuse the [[Prototype]] internal property if implemented that way...) Thus, any properties set are placed on the wrapper object and would as a result of that shadow the getter and setter on the string. > In a clean-slate world, I think that should be the end of the discussion. > However, we have backwards compatibility issues to consider. By the book ES3 > allows numerically named properties to be added to String objects that are > unrelated to the string value, and 2 out of the 3 widely used browser-based > implementations that support property style access to the string value also > allow such properties to be added. Only Webkit deviates from this. Right or > wrong, from a pure compatibility perspective preserving that capability would > be important **if we think that there is any significant usage of it**. I expect almost all usage of "new String" to be from people who either come from Java or who have not learnt JavaScript beyond the rookie stage yet. And maybe one or two library writers who are too clever for their own good... > The fact that Safari seems to be getting away with its implementation > without being badgered into conformance suggests that there probably isn't > any such significant usage. Neither the direct access of characters in the string by indiced property lookup nor the use of String objects is common, so the overlap is in all probability diminutive. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Ordering
2008/5/31 Douglas Crockford <[EMAIL PROTECTED]>:
> This program...
>
>
>
> (function () {
> var keys = [
> 'koda', 0, 'bosanda', 1, 'bosoya', 2
> ];
>
> var object = {}, table, i, name;
>
> for (i = 0; i < keys.length; i += 1) {
> object[keys[i]] = i;
> }
>
> i = 0;
> table = '<table><tbody><tr><th>' +
> 'Insertion Order</th><th><code>for in</code> Order</th></tr>';
> for (name in object) {
> table += '<tr><td>' + keys[i] + '</td><td>' + name + '</td></tr>';
> i += 1;
> }
> table += '</tbody></table>';
> document.write(table);
> })();
>
>
>
> ...produces this result on current editions of Internet Explorer, Firefox, and
> Safari:
>
> Insertion Order for in Order
> kodakoda
> 0 0
> bosanda bosanda
> 1 1
> bosoya bosoya
> 2 2
>
> It produces this result for Opera:
>
> Insertion Order for in Order
> koda0
> 0 1
> bosanda 2
> 1 koda
> bosoya bosanda
> 2 bosoya
>
> Opera appears to be optimizing array-like sequences.
Opera stores property names that are array indexes in a more space
efficient manner than other property names, at the cost of not
preserving insertion order when enumerating the properties.
> What should ES3.1 say about member ordering? Should it remain unordered, or
> should Opera be required to conform, or should the other three be forced to
> adopt Opera's optimization?
ES4 requires enumeration order to follow insertion order, so the space
optimisation Opera does break the ES4 rules. Opera have bugs about
property access being a performance problem, and in the process of
fixing that may change to another storage system, so aligning with
Opera's current behaviour would be a bad idea.
I think ES3.x should either follow ES4 or stay silent on the issue,
especially considering Opera is the only browser that doesn't use
insertion order enumeration.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Namespaces as Sugar (was: complexity tax)
> On Wed, May 28, 2008 at 12:48 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: >>> I want to say thanks for making this proposal (open namespace search only >>> for lexical references). It leaves most of the use-cases I cited intact. >>> Well done, good compromise (not complete evisceration of property >>> qualifiers, or dismissal of unqualified import). While I like the idea, it doesn't address at least two of the use cases for namespaced properties: - Having both a fully typed and an untyped version of the same method on the object, allowing code to switch through just opening a namespace if the programmer knows their code is type consistent. - Allowing user classes or objects to present interfaces overriding behaviour inherited from Object which were internal and unexposeed in ES3. The first point is mainly a convenience feature. The second point can be addressed using new syntactic forms for each such case. (If using the form "operator [no newlines here] ident", that would be a safe way to do it since all code looking like that cause a syntax error in ES3.) I don't know if that's a good or bad idea though. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Odd idea
2008/5/18 Mark S. Miller <[EMAIL PROTECTED]>: > We've all been assuming that the current disconnect between JavaScript > version numbers and Ecmascript version numbers will continue. As I was > reading > <http://wiki.ecmascript.org/doku.php?id=proposals:versioning&s=versioning>: /snip/ > it occurred to me that it's not yet too late to end the madness. How > about if we align the next JavaScript version numbers with their > Ecmascript equivalents: > > How about if the JavaScript version corresponding to ES4 is JavaScript > 4? This also addresses the otherwise nasty issue of what the > JavaScript numbering should be for ES3.1. Let's call that JavaScript > 3.1 as well. Way better than the last suggestion I heard, which was "just double it" and works pretty well for JS1.3 (not quite ES3 yet), JS1.5 (pretty much in line with ES3) and JS2 (ES4) but not for ES3.1. Also it's pretty much in line with the version jumps of XHTML5, DOM5HTML (if they persist) which are specifically there to align with the HTML5 version number. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Proposed ES4 draft 1
2008/5/17 Lars Hansen <[EMAIL PROTECTED]>: > Enclosed is a quite incomplete first draft of the specification for the > Proposed ECMAScript 4th Edition. This draft is comprised of a short > introduction, the surface grammar, and a description of the core > semantics -- values, storage, types, names, scopes, and name resolution. > More will follow as it is ready, probably on a (more or less) bimonthly > schedule. See the introduction for a general discussion. In core-language.pdf, section "1.2 Null", the note reads "NOTE While the null and undefined values have similar meanings, they have different conventions of use. The null value is intended to indicate a missing object value, while the undefined value is intended to indicate a missing property on an existing object value. These indeded uses are conventions, and are not enforced by the language semantics." Besides the obvious spelling error, I think your terminology of "missing object value" and "indicating missing property on an existing object" are actually more confusing than helping. I would characterise null as being the "invalid object value"; i.e. "the object that is not an object", in analogy with NaN being "a number that is not a number". (Or s/the (object|number)/the value/ if you prefer that, since the spec specifically mentions null not being an object.) The value undefined on the other hand has several distinct meanings: It either represents a storage slot (variable/argument/object property) that has not been assigned a value, it represents a storage slot not existing at all, or it represents a storage slot explicitly being set to undefined by the programmer. Three entirely different things. I like to explain that as undefined being the "value that is not a value" in analogy to how I explain null and NaN. Not saying I think the spec should say just those things in particular, just that I think your characterisation of them is a bit dissonant with their nature, especially undefined being much broader in meaning than your definition of it. In core-language.pdf, "1.3.1 Property Binding Map", a paragraph reads: "A property binding map stores the order in which properties are added to the map. A property's position in this order is unchanged when the property is replaced. This order is used by property enumeration (see the chapter on Statements)." I just wish you make clear one detail here: Does removing and adding a property with the same name change its enumeration order, or is that equivalent to a replacement? I think it probably should remove it from the enumeration order and insert it at the end. Also, knowing a bit about Opera's planned behaviour on this for Futhark , I'd like the correct behaviour for enumeration after a delete well defined. In core-language.pdf, "1.4.5 String Values", you allow both ES3 compatible 16-bit UCS-2 code units and 32-bit Unicode code points (and, I would assume, 21-bit code units which would behave exactly as if they were UTF-32 code units). If an implementation is UTF-8 under the hood but leaves the programmer-visible indexed access per either one of those models (with notably worse algorithmical complexity for random access but not for serial access), is that okay per the spec? In core-language.pdf, "2.1 Catch-All Methods", the default behaviour of accessing the value from a dynamic property in the object's property map is mentioned. Is there a way for non-default catch-alls to do this, too? (Maybe they only want to treat a special subset of property names differently, not all names...) In core-language.pdf, "2.3 Reading a property value" the last fixme reads: "FIXME We need to specify whether the bound method is cached or not, ie, whether, given that o.m is a method, (o.m === o.m)." Whether o.m is a method or not shouldn't change anything, should it? As long as it's just named and not called it's the same object. If there's a setter or getter for that particular name or a catch-all, now, that's where this issue arises. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Forwards-compatible syntax proposal
> On Sat, May 17, 2008 at 3:21 PM, Lars Hansen <[EMAIL PROTECTED]> wrote:
>> I've spent some time examining
>> compatibility between ES3 and ES4 [1]. Opt-in to ES4 keeps you out of
>> most trouble.
2008/5/17 Steven Mascaro <[EMAIL PROTECTED]>:
> That's true if the programmer in question is confident that she's writing
> pure ES4 code. But if she's already comfortable with ES3, she will very
> likely want to move over to ES4 gradually, learning any new syntax bit by
> bit. In that case, she will want to write/copy ES3 code that will run in an
> ES4 interpreter (much like a C programmer might write/copy C code to be
> compiled by a C++ compiler). If the interpretation of code changes between
> ES3 and ES4, she will almost certainly encounter bugs that are very
> difficult to track down.
You're basically saying that ES4 mustn't change the meaning of any ES3
program here. The problem I see with that is that it wouldn't allow
any semantics expansion that reuses the old syntax forms. You'd
confine all language changes to be either pure standards library ones
(which are not entirely safe either, considering that there may be
code in the wild that use these names and objects that are "safe" to
use in ES3) or new syntactic forms that will be guaranteed to produce
a syntax error in ES3, which means they can't exist in present ES3
code.
I don't agree. ES4 must be allowed to correct broken things in ES3 in
case that may provide
security/privacy/integrity/compatibility/sensibility improvements;such
as making sure algorithms don't use hijackable global objects by
making those global objects {DD, RO, DE}; or improve broken mechanisms
like format control characters stripping (a clear case of trying to be
clever and think forward misfiring); or introducing new
identifier-like operator keywords which can take an expression operand
(e.g. the yield example Lars gave).
Opt-in gives you a choice, to check your code for a short list of
things that would produce a difference in ES3 as compared to ES4. With
no opt-in, you don't allow that to happen.
> More generally, I don't believe that requiring developers to opt in to a new
> revision of a language/format/protocol/etc. is a good idea, which is one
> reason why I consider backwards-compatibility critical. I'd be interested to
> hear Hixie's reasons.
In the case of programming languages, I'd much prefer an opt-in than a
model that:
- Doesn't allow correcting obvious mistakes in earlier versions.
- Doesn't allow patching privacy/integrity problems by adding
restrictions on present standards library properties.
- That forces all semantics additions to introduce new syntactic forms
in order to not modify the semantics of certain programs, for example
by prohibiting adding new operators and keywords.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: application/* mime-types and SVN [Was Re: Forwards-compatible syntax proposal]
2008/5/14 Mike Samuel <[EMAIL PROTECTED]>: > Ok. So it's a content-type which is not a mime-type even though it looks > like one? > Is there a separate recommendation that defines a mime-type for ecmascript? http://www.ietf.org/rfc/rfc4329.txt> -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: getter and setter inheritance
2008/5/9 Lars Hansen <[EMAIL PROTECTED]>: > My view is that getters and setters introduce properties and that whatever we > do should be appropriate to that model. That is pretty much my view as well. Just a couple of questions that might need addressing, if it hasn't been dealt with already: - Can you have a property together with a getter and/or a setter? - If so: * Is there any way to reach that property from inside the getter/setter without ending up recurring into the getter/setter? * Can a setter modify the property if there is a property but no getter? * Can a getter read the property if there is a property but no setter? > Others seem to think that getters and setters introduce a way of invoking > normal methods by a different syntax and that they are truly just methods. > In the world of classes and instances that may be appropriate, but not in > the object-and-property world of ES3, I expect. Or one could consider an ES3 property as a getter/setter pair, if one wished. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: attributes not allowed on a interface?
On 22/04/2008, Eric Suen <[EMAIL PROTECTED]> wrote:
> Since attributes not allowed on a interface, for W3C Node interface:
>
> interface Node {
> const unsigned short ELEMENT_NODE = 1;
> }
>
> what is the same statement in EcmaScript 4? I don't see the point
> why static const attributes is not allowed on a interface?
Entirely based on my own understanding of how it works:
Interfaces in ES4 are only nominal types and signatures, they do not
carry implementation and thus no initialised values. Classes do that.
So, the interface would define the properties, the class that
implement that interface carry the initialisation of those properties.
For the DOM, it all gets a bit bad since the DOM requires multiple
inheritance on the prototype chain if you want to implement a
consistent interface object - prototype inheritance as can be seen in
moz, saf and op but not in ie. In other words, the ES4 inheritance
model does not allow you to implement the DOM interfaces compatibly
with those three browsers strictly using native inheritance systems.
You'd have to implement getters and settters á la the Bindings spec[1]
to achieve that. Those getters and setters are IMO broken, because
they don't ensure a property is looked up in a subtype before they are
looked up in it's supertype[2].
[1] http://www.w3.org/TR/DOM-Bindings/#interface-prototype-object>
[2] http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0091.html>
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: strict mode
> On Wed, Apr 16, 2008 at 10:11 AM, Lars Hansen <[EMAIL PROTECTED]> wrote: > > http://wiki.ecmascript.org/doku.php?id=proposals:globals, > and there's always the reference implementation. I think the 'global' > variable has moved from intrinsic to __ES4__ but that's just a detail. On 17/04/2008, Mark S. Miller <[EMAIL PROTECTED]> wrote: > What is the significance of intrinsic vs __ES4__? I'm asking because I'm > thinking of possibly proposing that "global" also name the global object in > ES3.1. However, ES3.1 has no namespaces. __ES4__ is per default open in ES4 mode but not in ES3 mode, it's a way to protect the ES3 namespace from being infected by names and functionality that could break live ES3 programs. intrinsic is on the other hand not open per default but has to be specified explicitly, either in implicit::identifier form or through a use implicit directive. Or that's my understanding of it, anyway. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 stable draft: object initializers
On 16/04/2008, Waldemar Horwat <[EMAIL PROTECTED]> wrote:
> There is also another ambiguity in the grammar:
>
> var {x:y, p:q} = expr;
>
> is both an assignment expression statement and a destructuring variable
> binding statement.
An assignment to an object literal seems like total bogus though - LHS
of an assignment should be a storage location and not an object. So
logically it makes sense only as a destructuring assignment.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Declarations
> Michael O'Brien wrote:
> > As a follow up, the following somewhat surprised me.
> >
> > {
> > let b = 1
> > {
> > function fun() {
> > print("CALL: " + b)
> > }
> > }
> > }
> > fun()
> >
> > gives:
> >
> > **ERROR** EvalError: uncaught exception: ReferenceError: unresolved
> > lexical reference {multiname: [ns public '']::b [ns internal '']::b
> > [ns public '__ES4__']::b } (near /Users/dherman/es4/src/builtins/
> > Error.es:86:55-86.55)
> >
> >
> > ie. the function is hoisted to the outer var block, but does not seem
> > to capture the scope chain of where it was declared and b is out of
> > scope.
> >
> > Is this correct or an RI bug?
On 16/04/2008, Waldemar Horwat <[EMAIL PROTECTED]> wrote:
> This is incorrect and an RI bug, but for a different reason: fun should be
> undefined in the outer scope, since it should not get hoisted out of the
> inner block, as we agreed at the last face-to-face meeting.
While ES3 has that case as a SyntaxError, implementations of ES3 allow
it. SpiderMonkey (tested in JS1.7 mode) is the only browser hosted
implementation that I could find which does not hoist the function
declaration and initialisation to the top of the current function
scope at compile time. What SpiderMonkey does is that it hoists the
function to the current function scope at run time though. Which means
that:
alert(foo);
{
function foo(){}
alert(foo);
}
is a reference error at the first line, while:
{
function foo(){}
alert(foo);
}
alert(foo);
is not an error.
So the choice to not hoist a function declaration to function scope at
least at run time seems like it would break code written for any of
our current browser hosted implementations. I would be much more
comfortable with hoisting the declaration at compile time and doing
the initialisation at run time to preserve the relation with control
flow. (As I discussed in [1].)
Isn't it better to do what SpiderMonkey does for regular function
declarations in statements, as a lowest-common-denominator for how
widely the function declaration is accessible, and only make a
qualified block scoped function:
{
let function(){}
}
to be bound in block scope?
Also another point to make about this: You are effectively adding a
function-declaration-within-statement production, something ES3 left
undefined. Browser implementations vary in how these constructs are
treated with relation to control flow and compile time vs. run time
initialisation (see [2] for a breakdown of behaviour in various
engines). If you allow it at all, you should be explicit about what
the rules for declaration hoisting and initialisation timing really
are - current implementations are not interoperable.
I personally prefer preserving control flow versus preserving
use-before-definition mechanics (this is more useful of the two
absolutes, and doing something like the inconsistency of
JavaScriptCore is madness), and preserving the scoping to function
level since all browser hosted implementations currently guarantee use
even after the block has exited.
[1] https://mail.mozilla.org/pipermail/es4-discuss/2007-March/000483.html>
[2] https://mail.mozilla.org/pipermail/es4-discuss/2007-March/000495.html>
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Strict mode recap
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Jon Zeppieri > > > Let me turn it around. > > From my perspective, it isn't an E4X vs. ES4 distinction; > > it's a "looking up a property of a first-class object" vs. > > "using a local variable" (or, if you prefer, "looking up a > > property of an activation > > object") distinction. It's not as if this is an uncommon > > distinction in programming languages, and the advantage of > > keeping the distinction is better static analysis, better > > performance, more tractable code. On 04/04/2008, Lars Hansen <[EMAIL PROTECTED]> wrote: > Your comment about inhibiting static analysis isn't right; if ns::x is a > name then either ns is known to be constant at compile time or not, and > if it is, then nothing prevents early binding. ES3 systems perform > analyses that are inhibited by eval and with, and statically detect > whether eval and with are used in order to decide whether to perform the > analyses. I thought the argument was about the ns::[name] form... While the namespace may be known at compile time, the actual variable name is not - which means that the implementation actually has to be able to look local variable names up as strings, instead of just object members. That is similar in effect to locally scoped eval. ES3 allows restricting eval such that this string look up only has to work if the compiler actually sees an "eval" in the fucntion body, though. I guess the same argument can be made for these dynamic namespace lookups too, however. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Strict mode recap
On 04/04/2008, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
> This is like the E4X example in one crucial respect: in both cases,
> you're accessing a property of a first-class object. I'm not arguing
> against this use of computed names. I don't see any significant
> difference between the above and:
>
> var obj = { x: "hello" };
> print(obj["x"]);
>
> My claim is simply that...
>
> function foo() {
> var x = "hello";
> }
>
> ... here, x is not a property of a first-class object. x's binding
> environment isn't a datum. But:
>
> function foo(name) {
> ...
> return null::[name];
> }
>
> ... treats the environment as if it were a datum. I know that in the
> ES3 spec all bindings are referred to as properties of objects, but
> activation objects are only notional entities. The current ES4
> proposal seems to raise their status by giving programmers a simple
> mechanism to (practically) reify them.
Except you can't actually make the activation object a first class
object. The null namespace (or any other namespace) is orthogonal to
the activation object - you can now look up local variables
dynamically instead of just statically, but the scope still cannot be
leaked out of the function in any way.
The only notable change is that you now have a method of making
dynamic lookup of the local variables in a scope instead of only
static lookup. The method of doing so is considerably better than
locally scoped eval because it's restricted to doing just that and
nothing more.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object initializers
On 21/03/2008, Lars Hansen <[EMAIL PROTECTED]> wrote:
> I've attempted to sum up everything we have decided about object
> initializers (aka object literals). A short draft spec is included.
> Comments welcome from everyone, especially from ES4 WG members who might
> remember about things I've forgotten, or correct misunderstandings.
Just a few ideas, I think there's a few declarative features I'd like
to see added:
- I'd *really* like to see some declarative syntax for setting
{DontEnum} flag on properties in object initialisers.
- A declarative way to set catch-alls.
- A declarative way to set the [[Call]] property.
- And maybe declarative way to set the [[Prototype]] property. (This
would of course be const.)
var
a={
dontenum toString: function()'[object customObj]'
},
b={
[[Prototype]]: a,
[[Call]]: function()...,
get *: function(propname)...,
set *: function(propname, value)...,
...
};
The brackets for syntax would from what I can tell work here, since
they are syntax errors in ES3. Or using some double keyword syntax I
guess.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Dumb Q: Where on the ES4 Wiki are draft spec pages???
On 19/03/2008, ToolmakerSteve98 <[EMAIL PROTECTED]> wrote: > WTF? I have no idea what i am now looking at. > I click on various links. None show me anything interesting -or- are not > accessible without logging in. > > I want to see whatever there is so far of a spec -- > what do I do??? I believe the public feature specs drafts are here: http://wiki.ecmascript.org/doku.php?id=features_specs:feature_specs> Lars has posted some more for review here on es4-discuss though. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Controlling DontEnum (was: ES4 draft: Object)
> > [mailto:[EMAIL PROTECTED] On Behalf Of liorean > > ReadOnly would need to be instanciated at the same time, no? On 13/03/2008, Lars Hansen <[EMAIL PROTECTED]> wrote: > I assume you're referring to my having left the value argument out > by mistake (second argument). > > Or was there something else? Value and type, though you addressed types earlier in your reply. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Controlling DontEnum (was: ES4 draft: Object)
On 13/03/2008, Lars Hansen <[EMAIL PROTECTED]> wrote: > Since our method is creating a new property and not setting > one, I suggest __createProperty__ as the most appropriate > name, so I'm going to use that below. Sounds perfectly reasonable to me. > I still think it may be right that properties in non-public > namespaces should not be enumerated, but I also think that's > orthogonal to the discussion that's going on here, about > dynamic properties and their attributes. We've pretty much > decided (ticket #233 has some of the discussion) that for > future compatibility there ought to be a difference between > fixture properties and DontDelete "dynamic" properties. So > dynamic properties have at least one attribute bit like they > do in ES3 (for deletability). Consequently, they might as > well have all the ES3 bits: for enumerability and writability. For ES4, shouldn't this function also take a type binding? > Ergo, let's assume that we are not finessing more than we > have to, and dynamic properties have all these attribute bits. > I don't know why __createProperty__ should not be able to > set all of these. Neither can I. > (They're not independent, ReadOnly implies DontDelete.) > > __createProperty__ should throw an exception (TypeError?) if > the property already exists on the object or would shadow a > ReadOnly property, a la [[CanPut]], or if the object is not > dynamic. It should probably throw an exception if its > arguments are not consistent (ReadOnly && !DontDelete). If ReadOnly is specified, is there even a reason to look at DontDelete? > Pesonally I like the strings approach, but the only interface > among these four that has good compile-time checking is the > first one, so I'm going to propose that we use that one, > with dontEnum as the first flag, dontDelete as > the second, and readOnly as the third (based on a guess about > the frequency of use). Thus on Object.prototype and as an > intrinsic propety on Object instances: > > function __createProperty__(name:EnumerableId, > dontEnum:boolean=false, > dontDelete:boolean=false, > readOnly:boolean=false): void ReadOnly would need to be instanciated at the same time, no? And you probably want to be able to specify a type binding for ES4. > * The above does not preclude complementary declarative > mechanisms in ES4 (but not in ES3.1 obviously) Good to hear, because I still want to see something that can be used in object literals and property declarations. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [selectors-api] Why have two identical differently named interfaces?
Oops, don't know how I ended up sending that to this mailing list - it was intended for the WebAPI WG list... -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [selectors-api] Why have two identical differently named interfaces?
On 12/03/2008, Boris Zbarsky <[EMAIL PROTECTED]> wrote: > I guess I could do the two interfaces, but I'm having a hard time seeing > different extensions being made to these two interfaces (as opposed to wholly > new interfaces being invented, as was done here). I can actually imagine one extension that only makes sence on elements and not on any other nodes - element-rooted instead of subtree-only-but-document-rooted queries. (I don't see any real benefit from such an interface though, but I've seen the idea mentioned on the mailing lists.) -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
On 11/03/2008, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > This is not unreasonable, but if adding to Object.prototype is truly > terrifying then I think the approach Mark Miller linked to, of static > methods on the Object constructor, is cleaner: /snip/ > It might even be better to make this transition one-way, since it > shouldn't be allowed to make built-in properties that are DontEnum > enumerable: Could as well make it a global function then. Just give it an obscure __preventEnumeration__(obj, propName) signature or something. I would very much like to see a declarative keyword for use with global, class and namespace variable and function declarations and in object literals. There's really not much reason to require a function call for a declarative feature if there's a cheap and much nicer way to do it in ES4, as long as you have a solution for ES3. (Kinda like how there's a specific slice syntax in ES4, but the slice functionality itself is ES3 compatible.) -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
On 11/03/2008, Lars Hansen <[EMAIL PROTECTED]> wrote: > As far as I can see this is not a problem in the file I sent out, nor in > the one I received from the reflector. > > What mailer are you using? Gmail's web interface. And checking, it appears only using the View link, not the Download link. So it appears to be GMail's fault. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
On 10/03/2008, Lars Hansen <[EMAIL PROTECTED]> wrote: > Draft 2 of the spec for the Object class. Changelog near the beginning. The intrinsic toString method returns the concatenation of "[", "object", the class name of the object, and "]". There should probably be a whitepace between "object" and the class name, as is the case in the implementation. If the object is the result of calling the Object constructor with a host object (Host objects), it is implementation-defined whether valueOf returns its this value or another value such as the host object originally passed to the constructor. "(Host objects)" looks a bit weird like that. Should probably be either "(see Host objects)" analogously to how you later use "(see HasProperty-defn)" or reference style, "[Host objects]" The function magic::getPrototype extracts the [[Prototype]] property from the object. See magic:getPrototype. And here a reference to documentation elsewhere. Probably should try to be consistent about how those look. I assume these are going to be links in the finished spec? -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
On 10/03/2008, Lars Hansen <[EMAIL PROTECTED]> wrote: > Draft 2 of the spec for the Object class. Changelog near the beginning. The draft HTML seems a little broken. There's … in it early on, later these appear raw in the source (which displays as an empty square in Opera and IE8). And near the end of the document you have "" Slightly broken conversion tool? -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Error classes
> On Mar 9, 2008, at 3:31 AM, Michael Daumling wrote: > > line > > > > The initial value of the line prototype property is the line number of > > the executing code that created the Error instance. This is an integer > > value, starting with the number 1. On 09/03/2008, Brendan Eich <[EMAIL PROTECTED]> wrote: > FYI, this property is named lineNumber in SpiderMonkey -- consonant > with fileName, if a bit verbose to match. I remember writing an error handler that provided cross browser as-much-information-as-the-browser-provides data about errors. (The code is sadly gone together with the domain I used it on, however, so I can't look it up.) I recall there was some engine that used the name lineNo for that (together with a property for getting the column number I think, though I can't recall the name). There was also some engine using the name source for the file name. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Error classes
On 09/03/2008, Michael Daumling <[EMAIL PROTECTED]> wrote: > What I would suggest is something along the following lines. It should > be made clear that these properties must be present, but that the actual > value of these properties are implementation dependent. This creates a > reliable framework for returning extended error information to be used > in error logging or error display. > > fileName > > The initial value of the fileName prototype property is an > implementation-defined string that reflects the name of the source file > containing the script that created the Error instance. > > The implementation of this property is optional. If not implemented, the > value of this property is the empty string. > > line > > The initial value of the line prototype property is the line number of > the executing code that created the Error instance. This is an integer > value, starting with the number 1. > > The implementation of this property is optional. If not implemented, > than value of this property is zero. How about javascript: urls; javascript in data: urls; javascript from eval, setTimeout with string, setInterval with string, Function constructor; javascript written directly into the page using DOM; javascript written directly into the page using innerHTML? -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: eval
On 06/03/2008, Lars Hansen <[EMAIL PROTECTED]> wrote: > eval(x) > look up "eval" > if the found value v is the original eval function and > the binding object x holding eval is an ES global object and > the global object on the scope chain for v is x then Is this the same x as in "eval(x)" above? The way the sentence runs, that seems not to be the case. If this is going into spec text, another letter should probably be used to avoid any ambiguity. >invoke eval as follows: > the scope chain is the lexical chain in effect at the point of > invocation > the variable object is the innermost variable object in effect > (which is to > say that it excludes binding objects introduced for "let", > "catch", named > function expressions, "switch type", and note also that > code at the top > level of a class is static initialization code so the > variable object > is the global object) > the value of "this" is the global object x And here again. > else > we don't care; invoke v as a normal function -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Triple quoted strings
On 06/03/2008, liorean <[EMAIL PROTECTED]> wrote: > (Hmm. Were there any proposal for adding a any-includes-newline flag > or a any-including-newlines escape instead of the [\s\S] cludge? If > not, is \A) Never finished that sentence it seems. It should have run: If not, is \A or some similar escape sequence for it possible to add at this stage? -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Triple quoted strings
On 06/03/2008, P T Withington <[EMAIL PROTECTED]> wrote: > I'd like to see us keep triple-quoted strings. But with a simpler > (tried and true?) syntax, say that of Python 'long strings'. (Which > to my mind are just heredocs without a choice of delimiter.) Seems to > me we just tried to be too clever parsing triple-quoted strings, > leading to all those funny edge cases that started this thread. Is the current syntax so bad, then, or complicated? The treatment of the string content itself is basically the same as for any other string with the single exception of newlines being allowed. The external syntax seems like it would match this regex: /((["'])\2\2)((?:\\[\s\S]|(?!\1(?!\2))[\s\S])*)\2/ (Hmm. Were there any proposal for adding a any-includes-newline flag or a any-including-newlines escape instead of the [\s\S] cludge? If not, is \A) I don't see it being such a bad idea - it's just syntactic sugar over normal ES3 strings. Just to prove the point, transforming such a string to the equivalent ES3 can be done like so: var reTripleQuotedString = /((["'])\2\2)((?:\\[\s\S]|(?!\1(?!\2))[\s\S])*)\2/, es4TripleQuotedString='"""some\nstring" \'\'\'with "" several \\""" different quirks\\\n\n\'\'\' in it """""', match=reTripleQuotedString.exec(es4TripleQuotedString), delim=match[2], reDelim=new RegExp(delim,'g'), contents=match[3], es3String=delim+contents.replace(reDelim,'\\'+delim).replace(/\n/g,'\\n')+delim; // es4TripleQuotedString => """some //string" '''with "" several \""" different quirks\ // //''' in it """"" // es3String =>"some\nstring\" '''with \"\" many \\"\"\" different quirks\\n\n''' in it \"\"" Sure, we could have wanted a more advanced string building mechanism that was literal all the way, without ES3 escaping. Or we could have wanted a more dynamic string that expanded expressions in it using some syntax. Or we could have wanted a user selectable delimiter. But for the use case of not having to make multiline strings instead be long strings containing \n where there is conceptually a newline, and for the use case of not having to escape singly quoted delimiters in the string, what we have is good enough. I think we should keep it as-is. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Triply quoted string literals
On 04/03/2008, Waldemar Horwat <[EMAIL PROTECTED]> wrote: > I'm not sure what the intent is, but as this is written: > > """abc""""def""" > > will evaluate to the same string as 'abc""""def'. That's not how I read the spec. As I read it, it will evaluate to the same string as 'abc"', followed by a nonsensical def""" which should trigger a syntax error. > Furthermore, > > """\""" > > turns into: > > \ > > to which we're then supposed to apply escape processing, but that is not > possible because there is no character following the backslash. What happens? No it doesn't. That is three quotes followed by an escaped quote followed by two quotes (which do not end the triply quoted string), as I read the spec. > What does the following evaluate to? > > """\n\\\"\t""" > > Is it the same as "\n\\\"\t"? Looks to be so, yeah. > If so, then triple quoting seems like an extraneous feature, as we still > need to go through and double every backslash located inside the string. Seems so to me. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: How to unsubscribe from list?
On 22/02/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Question in subject Answer found at the address you see in the footer to every message to the list: > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Greedy triple-quoted string literals
> > > On Feb 18, 2008 1:17 PM, liorean <[EMAIL PROTECTED]> wrote:
> > > > Basically the idea was along the lines of investigating the effects of
> > > > removing GetValue usage from those productions whose semantics just
> > > > pass values through (such as all the shortcut evaluation operators,
> > > > parenthesised expressions, plain assignment, function arguments,
> > > > return statement etc.). The only semantics that would in effect be
> > > > changed are those for function calls. Function calls would always
> > > > "remember" the this-object of any member lookup since they are passed
> > > > around as a Reference object, while still not making that object
> > > > outside detectable. Of course if the function is referenced again
> > > > using member lookup, then a new Reference object would be created with
> > > > the new base object and the function object itself GetValue'd out of
> > > > the old Reference object.
On 20/02/2008, Garrett Smith <[EMAIL PROTECTED]> wrote:
> a.f = function(){
>return this;
> }
> s.f = a.f
>
> print( f() ) // s
Well, you'd have to do f=s.f first, but you've got the principle right.
> a.f ;
Just mentioning it doesn't change anything. The reference is created
by mentioning it, but since you're not storing it anywhere it just
gets garbage collected. You'd have to do f=a.f, jsut like you had to
do f=s.f above.
> print( f() ) // a
>
> Is this right?
With the changes above, then yes. The idea is that member lookups for
functions create a Reference (or rather a base:value tuple instead of
a base:slotname tuple), which is stored. This would be an intermediary
internal type that is never actually detectable from the script itself
other than in the form of retained this-values when passing function
objects around.
> > On 19/02/2008, Garrett Smith <[EMAIL PROTECTED]> wrote:
> > > Is this like getValue with a hint for a thisArg?
> On Feb 19, 2008 10:21 AM, liorean <[EMAIL PROTECTED]> wrote:
> > No, not really. And the way I described it is not quite what I want,
> > either. I'd want something similar to but not exactly like the
> > Reference type, such that a tuple with base and value is stored, not
> > base and name-of-property as is the case for Reference. A Reference
> > would allow replacing the value of the property between initialisation
> > and use, while I'd want something that stores the actual value at the
> > time of initialisation. Using a Reference also would require recursive
> > GetValue, which can be eliminated at initialisation time if it stored
> > the value instead of the name of the property.
> If I'm understanding you correctly, you want a Reference type on a
> function. Is this correct?
I want a base:value tuple returned from member lookups if the value of
the lookup is a function object. The Reference type is a base:slotname
tuple, meaning the actual value lookup would be delayed until use,
which is undesirable.
> And that Reference has a value pointing to the object which will be
> the this arg in Call. Right?
Yes.
> > If the event implementation is specified to extract
> > the function object, and calls fobj.[[Call]](EventTarget, arguments)
> > when the event is triggered, then it's not a problem at all. The specs
> > for DOM events do NOT specify how the this-object should be handled.
> > Nor do any other relevant spec from what I can tell. At the moment,
> > DOM0 and Saf/Op/Moz send the EventTarget as this-argument. Ie doesn't
> > send it for attachEvent et al, nor do some other DOM2Events
> > implementations (e.g. the one in Tasman).
>
> I can't remember the last time I tried to use Mac IE. I remember that
> it supported neither attachEvent nor addEventListener.
There's newer versions of Tasman. Tasman 0.9 was used in the MSN/OSX
browser, which contained DOM support much closer to that of Gecko,
Presto and Webkit than to that of Tasman 0.1 or Trident. Tasman 1.0 is
also used in Entourage in Office:Mac.
> > Instance methods would ignore any this-value sent, no? So this really
> > wouldn't change anything for them at all.
>
> Can you explain more?
The way I understands the ES4 proposals, [[Call]] on instance methods
ignore the first argument (the this.value) and instead always set the
instance as the this-value. So whatever first argument is sent to
[[Call]], it will have exactly zero impact on the semantics of the
program. Or is this a misunderstanding?
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Greedy triple-quoted string literals
> On Feb 18, 2008 1:17 PM, liorean <[EMAIL PROTECTED]> wrote:
> > Basically the idea was along the lines of investigating the effects of
> > removing GetValue usage from those productions whose semantics just
> > pass values through (such as all the shortcut evaluation operators,
> > parenthesised expressions, plain assignment, function arguments,
> > return statement etc.). The only semantics that would in effect be
> > changed are those for function calls. Function calls would always
> > "remember" the this-object of any member lookup since they are passed
> > around as a Reference object, while still not making that object
> > outside detectable. Of course if the function is referenced again
> > using member lookup, then a new Reference object would be created with
> > the new base object and the function object itself GetValue'd out of
> > the old Reference object.
On 19/02/2008, Garrett Smith <[EMAIL PROTECTED]> wrote:
> Is this like getValue with a hint for a thisArg?
No, not really. And the way I described it is not quite what I want,
either. I'd want something similar to but not exactly like the
Reference type, such that a tuple with base and value is stored, not
base and name-of-property as is the case for Reference. A Reference
would allow replacing the value of the property between initialisation
and use, while I'd want something that stores the actual value at the
time of initialisation. Using a Reference also would require recursive
GetValue, which can be eliminated at initialisation time if it stored
the value instead of the name of the property.
> > This change would eradicate a pet peeve of mine:
> > var
> > o={
> > f:
> > function(){
> > return this;
> > }
> > },
> > f=o.f;
> > o.f(); // => o
> > f(); // => window
> > (o.f)(); // =>o
> > (f=o.f)(); // => window
> >
>
>
> (o.f)(); // =>o
>
> This should be window.
No it shouldn't. The grouping syntax specifically doesn't call
GetValue in order to make delete and typeof operators able to use
function-call-like syntax. Which makes up for this asymmetry.
> > With the change, all of those would return o.
> >
> > I never quite finished my analysis of the backwards compatibility and
> > security implications of doing such a change though.
> > For backwards compatibility the issues with doing such a change should
> > be minor in live code. It would only affect code that both expects the
> > this-object to be the global object and which extracts the function
> > from an object using shortcut evaluation or assignment operation.
> >
>
> Any event registry using load/onlunload would seem to have problems.
>
> MyWIndowListeners = {
> onunload : function(){}
> };
>
> onunload = MyWIndowListeners.onunload;
That's not a problem. It's a question of how the [[Call]] is made on
the event handler. If the event implementation is specified to extract
the function object, and calls fobj.[[Call]](EventTarget, arguments)
when the event is triggered, then it's not a problem at all. The specs
for DOM events do NOT specify how the this-object should be handled.
Nor do any other relevant spec from what I can tell. At the moment,
DOM0 and Saf/Op/Moz send the EventTarget as this-argument. Ie doesn't
send it for attachEvent et al, nor do some other DOM2Events
implementations (e.g. the one in Tasman). Since the function call is
not part of ECMAScript, and this change affects the member lookups and
storage both, any external call into ECMAScript that does a GetValue
would get the old behaviour and any external call that sends a
this-value of it's own would be unaffected. Only an external call that
doesn't do a GetValue would get the remembered this-value.
> Instance methods in ES4 are bound. One implication to that is that
> theres a new function for each instance. It's not as cheap as having a
> prototype method.
Instance methods would ignore any this-value sent, no? So this really
wouldn't change anything for them at all.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Greedy triple-quoted string literals
On 18/02/2008, Lars T Hansen <[EMAIL PROTECTED]> wrote:
> It's been pretty quiet around here since we debated tail calls...
I never finished my part of that discussion... I have a long message
half-written on it since how long? Three months ago? I never quite
finished my line of thought though.
Basically the idea was along the lines of investigating the effects of
removing GetValue usage from those productions whose semantics just
pass values through (such as all the shortcut evaluation operators,
parenthesised expressions, plain assignment, function arguments,
return statement etc.). The only semantics that would in effect be
changed are those for function calls. Function calls would always
"remember" the this-object of any member lookup since they are passed
around as a Reference object, while still not making that object
outside detectable. Of course if the function is referenced again
using member lookup, then a new Reference object would be created with
the new base object and the function object itself GetValue'd out of
the old Reference object.
This change would eradicate a pet peeve of mine:
var
o={
f:
function(){
return this;
}
},
f=o.f;
o.f(); // => o
f(); // => window
(o.f)(); // =>o
(f=o.f)(); // => window
With the change, all of those would return o.
I never quite finished my analysis of the backwards compatibility and
security implications of doing such a change though.
For backwards compatibility the issues with doing such a change should
be minor in live code. It would only affect code that both expects the
this-object to be the global object and which extracts the function
from an object using shortcut evaluation or assignment operation.
For security, there's somewhat greater implications. IF the function
cooperates (and ONLY in that case) the this-value could be extracted
through return value or assignment to a scoped variable. This can only
happen if the function itself either returns the this-object or
assigns it to an external variable.
> That is what Comen, Leiserson, and Rivest[*] call greedy in
> their discussion of greedy algorithms: "A //greedy algorithm// always
> makes the choice that looks best at the moment. That is, it makes a
> locally optimal choice in the hope that this choice will lead to a
> globally optimal solution."
>
> Knuth does not include the term in his index, sadly, nor do any of my
> other algorithm books. Can somebody dig up a conflicting definition
> so that we can get a real discussion going?
When discussing "greedy" and "lazy" in terms of quantifierrs in regex,
the usual way to talk about them is that out of multiple valid
matches, "greedy" choses the match containing as many repetitions as
possible, and "lazy" choses the match containing as few repetitions as
possible. I don't know of a text that has a more formal definition
than that, really, nor do I know of any definition of greedy/lazy
algorithms as opposed to greedy/lazy quantifiers in regex or grammars.
I've got no formal CS education though, so I've not read that much of
the literature...
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Greedy triple-quoted string literals
On 18/02/2008, Lars T Hansen <[EMAIL PROTECTED]> wrote: > The correct interpretation is that a triple quoted string starts with > three quotes of the same kind and ends when the same three quotes are > seen in sequence provided that the character following the three is > not that same quote character. > > (Whether you want to call that greedy or not depends on whether you > think it's greedy to take what you can when you can take it, or > whether you think it's greedy to avoid taking something now because > you think you can take more later. Generally speaking a greedy > algorithm is one that makes a locally optimal choice about what is > best, so I think the description on the wiki is OK. The above > description is more precise.) I think that's a confusion waiting to happen that I certainly wouldn't want to see in spec text. The concept of "greedy" matching that I have would mean that the last triple quote delimiter in the source would be considered to be the endpoint of the literal that started with the first triple quote delimiter in the source. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Function inside if statement?
Just wanted to point out the thread starting here: https://mail.mozilla.org/pipermail/es4-discuss/2007-March/000483.html>. It discusses this issue. Brendan gave this answer, a few replies in: > Since this is an ES3 extension, allowed by chapter 16, we could > codify the majority-share practice, except that it sucks. We have so > far avoided specifying function statements, preferring to leave them > to implementations to experiment with, on into the ES4 future. I did a summary of what the engines did in various browsers at: https://mail.mozilla.org/pipermail/es4-discuss/2007-March/000495.html> The discussion detours a bit after that. Also, Microsoft included these tests as section 2.9 in their "JScript Deviations from ES3" document at: http://wiki.ecmascript.org/lib/exe/fetch.php?id=resources%3Aresources&cache=cache&media=resources:jscriptdeviationsfromes3.pdf> Note that the reason Safari according to that document doesn't give any results is that the test uses plain function declarations in the statement bodies. If the statement bodies had been wrapped in a statement list (curlies) then Safari would have given a profile very similar to that of Firefox except for the break-within-labelled-statement case, IIRC. In other words, to do a full set of tests one need to try both the statement-list wrapped versions and the plain function declaration versions, because they may have differing results. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Why packages and namespaces?
I think Brendan had a nice explanation of that some time back: On 10/08/2007, Brendan Eich <[EMAIL PROTECTED]> wrote: > There's more work to do, including rationalizing and minimizing > concepts including units and packages. A couple of notes: > > A package is a named pair of namespaces (public and internal), some > rules for using those namespaces within the package body, and some > special forms for importing names from the package's public namespace. > > Program units are compilation units, so unlike packages, which are > never "closed" and can be extended in a given trust domain, units > come to an end at the right curly brace. > > /be -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: proper tail calls
> On Jan 22, 2008, at 11:03 AM, Neil Mix wrote: > > I also want to make clear: this isn't about debugging code that uses > > PTC intentionally -- that tradeoff is up to the developer. This is > > about the novice coder who finds a stack trace on a production system > > from code that he doesn't own which just happens to be invoking PTC > > implicitly. On 22/01/2008, Brendan Eich <[EMAIL PROTECTED]> wrote: > I've already copped to low expectations about current-era debuggers, > and it is possible the same dismal view applies to logging traces, at > least on my part. Having to deal with a stack backtrace where you > (n00b or l33t, doesn't matter) have to hop around in 3, or 30, source > files to see how the heck control flowed from function f to g when f > doesn't call g, is Not Fun. The lack of stack traces in ECMA-262, and > anything like Python's much better backtrace support in JS > implementations, may be remedied, and then we'll all feel PTC pain. Maybe it'd make sense to have some "use ImplicitTailCallElimination=bool;" directives that can be used to make sure an implementation has or lacks implicit tail call elimination when running the code, still having explicit TCE possible even with "use ImplicitTailCallElimination=false;", leaving the default behaviour for implicit TCE up to the implementation? Or would that be three ways too many to handle it? -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: proper tail calls
> > On 1/21/08, Igor Bukanov <[EMAIL PROTECTED]> wrote:
> > > Consider another example:
> > >
> > > function f(a) {
> > >function f2 { return a * 2; }
> > >if (a == 0) return 0;
> > >goto return f(a - 1);
> > > }
> > >
> > > f(1 << 20);
> > >
> > > One may expect that this would require O(1) space. But this is not the
> > > case as the implementation may not eliminate f2.
> On 21/01/2008, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
> > But the above example *does* only require O(1) space. On each call to
> > f, a new closure is constructed, but it's dropped on the floor as soon
> > as the next iteration occurs.
On 21/01/2008, Igor Bukanov <[EMAIL PROTECTED]> wrote:
> You can not deduce that from ES4 specs that it does not require that f
> should be ever dropped.
Unless I'm entirely mistaken, neither ES3 nor ES4 places any
significant requirements on the implementation of memory allocation,
dead object detection or garbage collection systems used in an engine.
They leave all that up to the common sense of the engine developers.
However, once f has exited, there's no single live reference to it's
closure in that example. And it's closure is the only reference to f2.
That means that, at the discretion of the DoD and GC systems, the
memory could at any time be reclaimed. If the recursion exhibits a
space growth such that GC may be called for, then all those closures
should be collected, including the f2 from each closure and any other
heap stored values whose only reference comes from one of those
closures.
On 21/01/2008, Igor Bukanov <[EMAIL PROTECTED]> wrote:
> > > function f(a) {
> > >if (a == 0) return 0;
> > >goto return f(a - 1);
> > > }
> > >
> > > f(1 << 20);
> > >
> > > the implementation is still allowed to use heap for integers. So even
> > > in this example the space complexity may be O(N).
> > What is N here? Surely, it's has nothing to do with the number of
> > calls to f. This example has nothing do to with PTC.
> Even with the tail call optimization implemented, the space complexity
> of f(N) with f from the above example can be O(N) if the
> implementation uses heap to allocate integers.
IIRC, at least ES3 (and probably ES4 as well... since I haven't seen
any actual spec text written for ES4, I can't say either way) makes no
statements whatsoever about the internal storage used by the engine.
ES3 doesn't even contain the word "heap", and the only uses of the
word "stack" are the following two:
10 Execution Contexts
When control is transferred to ECMAScript executable code, control is
entering an execution context. Active execution contexts logically
form a stack. The top execution context on this logical stack is the
running execution context.
Even when a stack is mentioned it's just a logical stack, it doesn't
say anything about the actual implementation of anything.
> > > Hence the questions:
> > > how useful to specify the details of tail call optimizations without
> > > putting restrictions on the rest of the runtime?
> > In my experience, very.
> I was not able to construct a single useful example where one can
> reason about the space complexity of the tail calls given that ES4
> does not specify the space complexity of other aspects of the runtime.
> For this reason goto return looks very strange in ES4. It allows to
> assert a very specific space complexity property yet it is not
> possible to assert that, say a - 1 should not use heap allocation.
Well, I make a difference here between the live objects space and the
dead objects space. Whether there are tons of dead objects or not
makes no difference as to the space consumption of the live object
space. And the live object space in presence of proper tail calls will
grow only by the last closure unless the function explicitly makes
values externally reachable.
> > On 21/01/2008, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
> > > But the above example *does* only require O(1) space. On each call to
> > > f, a new closure is constructed, but it's dropped on the floor as soon
> > > as the next iteration occurs.
> On 21/01/2008, Igor Bukanov <[EMAIL PROTECTED]> wrote:
> > You can not deduce that from ES4 specs that it does not require that f
> > should be ever dropped.
On 21/01/2008, Igor Bukanov <[EMAIL PROTECTED]> wrote:
> Sorry for bad English here. I wanted to say:
>
> You can not deduce that from ES4 specs. The specs does not require
> that closures created during execution of a function would ever be
> dropped.
You can't deduce that any memory needed at any time by an ES3 engine
will be recovered, either. Garbage collection is left up to the engine
implementors.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Add call and apply methods to RegExp.prototype
On 22/12/2007, Brendan Eich <[EMAIL PROTECTED]> wrote: > Summarizing my questions: > 1. Is regexp callability worth adding in ES4? I would say a tentative no to that. It neither adds anything new nor significantly reduces code size. As you say, re() is only five characters shorter than re.exec. The only real benefit from it that I can see is that it allows generalised functions to call any function-or-regex argument on a string, instead of having to fork the code. > 2. If yes to 1, do we really need .call and .apply? I don't think it's needed, except for symmetry with real functions. (Does this stance make me a hypocrite for being the one who filed the RFE for this feature in Opera?) -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Global functions
On 14/12/2007, Michael O'Brien <[EMAIL PROTECTED]> wrote: > So should functions be treated like var declarations or as let > declarations. Seems like they are like vars in the RI. > > Is this right? I don't see how they could be anything else for ES3 compatibility's sake. At least, within a single compilation unit. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Draw control and page description updates
On 12/12/2007, Alistair Braidwood <[EMAIL PROTECTED]> wrote: > It doesn't seem very practical or sensible to require the developer to > order code in a specific way to avoid these sorts of performance penalties > and my prefered solution would be to add "I'm about to edit the page > description, please suspend drawing ops" and "I've finished editing the page > description, now you may draw" functionality to the language - which is why > I've mailed this group. Not saying that it's not a good idea (I'd view it akin to locking for threads, just less generally useful), but what on earth does that have to do with ECMAScript? ECMAScript doesn't deal with documents, browsers, laying them out visually or drawing them. The browser is just one of numerous possible host environments. The specifications that deal with the browser host in particular are the DOM ones. The W3C WebAPI group seems to have control over most of DOM specs (SVG DOM, HTML DOM and similar aside), that's probably a better place to ask for this. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Anyone got an emacs mode file for es4?
On 06/12/2007, Lars Hansen <[EMAIL PROTECTED]> wrote: > I use java-mode for all my ES needs. It works well unless you're a big > fan of leaving out semicolons, or using a lot of function expressions. I find it very hard to find a mode that fits my demands even for ES3 (I'm not an emacs user, but I haven't found an editor with a good ES mode at all), not to speak of ES4. Particularly if you're using a lot of function expression, object literals or array literals. In a way, I'd be more comfortable with a Scheme/LISP based mode (except expressions aren't necessarily contained in parentheses and there's statements syntax to consider as well) than a Java or C based mode, but there's not many modes that combines a good handling of statement-based code with good handling of expression-based code, especially when the expressions can contain statements such as function expressions. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Is this-propagation as written useful?
Hello!
Just looking at the this-propagation stuff, and what struck me
immediately is that the absolutely most desired use case to cover is
not at all covered. That use case would look something like this:
function moveLeft(){
/*...*/
}
elm.onevent=function(){
setTimeout(moveLeft, delay);
}
Where moveLeft wants to access this.style to change the position of the element.
Another similar use case that is not covered is sending this-bound
methods as callbacks.
Frankly, I think these two use cases dwarf the use cases for
this-propagation with named function calls where the function name has
to be a local of a shared scope. When people have questions related to
scope handling and the this-value, in my experience ALL such problems
stem from uses of eval, uses of Function/setTimeout/setInterval, uses
of with or the various ways of doing event handlers. I've yet to see
anybody posting a problem they have in this area which is actually
solved by the very limited this-propagation ES4 adds, and I've been an
active member in many JavaScript mailing lists and forums since before
ES3 became a standard.
In my opinion, this proposal should be extended in such a way that you
can actually do
setTimeout(fn, delay);
and have the this-value delegated. Even better if the proposal allowed
setTimeout(this.fn, delay);
setTimeout(a.b, delay);
with the this-value set to the original this when the function was
called in the first case, a in the second case.
The naive way of doing that would be to make member lookups return a
delegate object remembering the parent instead of a plain function
object. If called as a regular function call, it would use the
delegated parent. If no such parent existed, it would use the current
this-object (not the global object, unless the local this-value is the
global object). I suspect doing that might be a security problem
however, besides potentially breaking live scripts.
Another way might be to introduce a keyword for explicit this-delegation:
setTimeout(delegate this.fn, delay);
or simply a binding function:
setTimeout(this.fn.bind(this), delay);
or a more full-fledged delegation mechanism:
setTimeout(this.fn.delegate(this,args));
ES4's this-propagation at this moment seems to be extremely limited in
use, and specifically tailored to avoid the use cases where
this-propagation is most desired, judging from real-world problems.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Function.prototype.toString spec
0022,
literalise(typeof arguments === u ? u : arguments.callee));\u000a
prompt(\u0022anonymous\u0022, literalise(typeof anonymous === u ? u :
anonymous));\u000a prompt(\u0022onclick\u0022, literalise(typeof
onclick === u ? u : onclick));\u000a}"
Ff3.0b1/SpiderMonkey:
Function(str):
argument.callee: "function anonymous() {\u000avar u =
\u0022undefined\u0022;\u000aprompt(\u0022arguments.callee\u0022,
literalise(typeof arguments === u ? u : arguments.callee));\u000a
prompt(\u0022anonymous\u0022, literalise(typeof anonymous === u ? u :
anonymous));\u000aprompt(\u0022onclick\u0022, literalise(typeof
onclick === u ? u : onclick));\u000a}"
anonymous: "undefined"
onclick: "undefined"
setTimeout(str,10):
argument.callee: "undefined"
anonymous: "undefined"
onclick: "undefined"
fn:
argument.callee : "function () {\u000avar u =
\u0022undefined\u0022;\u000aprompt(\u0022arguments.callee\u0022,
literalise(typeof arguments === u ? u : arguments.callee));\u000a
prompt(\u0022anonymous\u0022, literalise(typeof anonymous === u ? u :
anonymous));\u000aprompt(\u0022onclick\u0022, literalise(typeof
onclick === u ? u : onclick));\u000a}"
anonymous : "undefined"
onclick : "undefined"
onclick:
argument.callee: "function onclick(event) {\u000avar u =
\u0022undefined\u0022;\u000aprompt(\u0022arguments.callee\u0022,
literalise(typeof arguments === u ? u : arguments.callee));\u000a
prompt(\u0022anonymous\u0022, literalise(typeof anonymous === u ? u :
anonymous));\u000aprompt(\u0022onclick\u0022, literalise(typeof
onclick === u ? u : onclick));\u000a}"
anonymous: "undefined"
onclick: "function onclick(event) {\u000avar u =
\u0022undefined\u0022;\u000aprompt(\u0022arguments.callee\u0022,
literalise(typeof arguments === u ? u : arguments.callee));\u000a
prompt(\u0022anonymous\u0022, literalise(typeof anonymous === u ? u :
anonymous));\u000aprompt(\u0022onclick\u0022, literalise(typeof
onclick === u ? u : onclick));\u000a}"
Ff2.0.0.11/SpiderMonkey:
Function(str):
argument.callee: "function anonymous() {\u000avar u =
\u0022undefined\u0022;\u000aprompt(\u0022arguments.callee\u0022,
literalise(typeof arguments === u ? u : arguments.callee));\u000a
prompt(\u0022anonymous\u0022, literalise(typeof anonymous === u ? u :
anonymous));\u000aprompt(\u0022onclick\u0022, literalise(typeof
onclick === u ? u : onclick));\u000a}"
anonymous: "undefined"
onclick: "undefined"
setTimeout(str,10):
argument.callee: "undefined"
anonymous: "undefined"
onclick: "undefined"
fn:
argument.callee : "function () {\u000avar u =
\u0022undefined\u0022;\u000aprompt(\u0022arguments.callee\u0022,
literalise(typeof arguments === u ? u : arguments.callee));\u000a
prompt(\u0022anonymous\u0022, literalise(typeof anonymous === u ? u :
anonymous));\u000aprompt(\u0022onclick\u0022, literalise(typeof
onclick === u ? u : onclick));\u000a}"
anonymous : "undefined"
onclick : "undefined"
onclick:
argument.callee: "function onclick(event) {\u000avar u =
\u0022undefined\u0022;\u000aprompt(\u0022arguments.callee\u0022,
literalise(typeof arguments === u ? u : arguments.callee));\u000a
prompt(\u0022anonymous\u0022, literalise(typeof anonymous === u ? u :
anonymous));\u000aprompt(\u0022onclick\u0022, literalise(typeof
onclick === u ? u : onclick));\u000a}"
anonymous: "undefined"
onclick: "function onclick(event) {\u000avar u =
\u0022undefined\u0022;\u000aprompt(\u0022arguments.callee\u0022,
literalise(typeof arguments === u ? u : arguments.callee));\u000a
prompt(\u0022anonymous\u0022, literalise(typeof anonymous === u ? u :
anonymous));\u000aprompt(\u0022onclick\u0022, literalise(typeof
onclick === u ? u : onclick));\u000a}"
> Note there is no Identifier in this output and an identifier is
> required in FunctionDeclaration syntax. Should
> Function.prototype.toString be specified to return a representation
> with FunctionExpression syntax?
IMO, if the serialisation includes a name, that name should be usable
as a variable reference within it. So the serialisation should never
include a name if it's not there.
However, this simple rule falls apart for several reasons, most
important that function declarations are bound in the outside scope
only, and not on the inside scope at all. This means a dissociated
function object from a function declaration will no longer be able to
use the original name as a reference to itself.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Regex: How should backreferences contained in the capturing match they reference to work?
Tried to sum up the issue a little more coherently and well articulated in a blog post: http://web-graphics.com/2007/11/26/ecmascript-3-regular-expressions-a-specification-that-doesnt-make-sense/> Doesn't really say anything I haven't said somewhere in this thread already, though. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Close review of Language Overview whitepaper
features that are sorely missed as a > result to classes. Well, structural types doesn't really affect the object types, do they? AIUI structural types are part of the contract system, not the inheritance model. The object is still just a plain object, it just has the given constraints. > Type definitions: Seeing the example of a type definition for a record > makes this feature seem even more redundant with classes. > > Data Types: If structural types cannot be recursive, then one of the > canonical applications of record-like types, the linked list, cannot > be implemented this way. I assume it can be with classes. Yet another > reason to fold any interesting record features into classes. Again, the difference is one of contract versus implementation. Structural types cannot provide implementation, they can only provide constraints. > Nullability: Are non-nullable types really worth it? I am not sure. > Does any other explicit type system for a dynamic OO language have > such a concept? The whitepaper says that "the ability to store null is > occasionally the source of run-time errors" but will not dynamic- > checking result in runtime errors anyway when assigning null to a non- > nullable variable (except in strict mode)? It's a very desired distinction for at least library writers. Getting early detection of this is very good for both code correctness and due to possible performance improvements if the engine optimises it. > Section VII. > > Type annotations and type checking: This section implies that type > annotations are not at all being added for performance reasons and may > indeed be harmful to performance. Wow! Seriously? I think runtime > assertions are interesting when debugging but I do would not want them > happening for every assignment statement in a release build of my C++ > code. I am not sure why ECMAScript programmers would want that. Later > this section says "it is plausible" that typed programs will run > faster and not slower with enough analysis, but this issue seems far > too crucial to take such a blase attitude. Unless we can show that > type annotations won't cause a performance hit in practice, and in > particular give a convincing argument that the relevant analysis can > be done with reasonable speed and without introducing an ahead-of-time > compile phase, then it is irresponsible to include type annotations as > currently designed. I am willing to believe that this is the case, but > I cannot sign on to an attitude that we don't care if typed programs > get faster or slower. Nor am I willing to take experience based on > ahead-of-time compilers as definitive. Most of the benefit from type annotations and type checking can be gotten through a good enough compiler even for ES3 code, so I think the performance side of the issue, while still important, is not at all as important as being able to put guarantees for correctness. > Section IX. > > Expression closures: I actually find the examples hard to follow given > my expectation of ES3-like syntax. I think this may actually be > syntactic salt. Mostly it's a question of the code being perceived as slightly off if you're used to the ES3 function expression syntax only. I still think the syntax is a bit heavy, but it's pretty neat to have if you're from FP background. > Destructuring assignment and binding: I grudgingly accept that this > sort of construct has been proven in the context of Python and Perl. It's sugar and honey to me:) > Slicing: This one I mildly object to. Array/String slicing is not, to > my knowledge, particularly common in ECMAScript code of today. I am > dubious that it merits its own operator syntax. Seems like an innocent enough extension to me, and for some of the uses, it should definitely allow engine to perform it faster than if the developers had to code the equivalent functionality using only ES3. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Bringing up the issue of numerical constraints again
Hello! Since we now have a namespace for uint specific math operations, and discussion in another thread about using pragmas for throwing if assigning to ReadOnly properties... Is it possible we could have a look at the idea of adding constrained primitive types or adding a pragma changing the mechanism for, or adding a separate set of operations, constraining number types by the simple rule of (input > output_type.MAX_VALUE) and (input < output_type.MIN_VALUE) throwing an out-of-bounds error. I'm a little concerned that a type of uint allows assigning negatives with a silent round-the-corner conversion and allows values of NaN and Infinity. (I imagine for example the DOM interfaces that have uint constraints really would like these to throw an out-of-bounds exception or similar.) Also, the RI gives an Overflow exception for values 2^32 or greater, which I'm not sure whether it's the intended behaviour or a result of the underlying implementation that is in fact intended to fail silently like the other cases. >> function fn(input:uint):uint input; >> fn(0x7fff); 2147483647 >> fn(-0x8000); 2147483648 >> fn(Infinity); 0 >> fn(NaN); 0 >> fn(0x1); unhandled exception: Overflow >> function fn(input:int):int input; >> fn(0x7fff) 2147483647 >> fn(0x8000) -2147483648 >> fn(-0x8000) -2147483648 >> fn(NaN) 0 >> fn(Infinity) 0 >> fn(0x1) unhandled exception: Overflow -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: roundTiesToEven
On 11/11/2007, Jonathan Watt <[EMAIL PROTECTED]> wrote: > I've noticed that rounding in the reference implementation is implemented > using > IEEE roundTiesToEven, but in browsers .5 values appear to round towards zero. > Although roundTiesToEven is desirable from a computational point of view, > there's likely a significant risk that changing to this method could break > some > existing ECMAScript. That's really serious breakage - books, tutorials, references and real world code all take for granted that halves alway round up. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Chris Wilson: What I think about ES4
On 04/11/2007, Mitch Skinner <[EMAIL PROTECTED]> wrote: > Nicolas Cannasse wrote: > > Mozilla and Adobe thought the same and came up with the > > ScreamingMonkey project, which is an ES4 runtime that can be installed > > for Internet Explorer. Nice, but how long will that work ? Given that > > Microsoft has no intention of helping, I can foresee that each > > IE/Windows update will break something. > > I thought that ScreamingMonkey planned on using a published & fairly > stable API to do this. Does anyone know of non-Microsoft users of this > API? How hard would it be for them to break it? Very, very hard. The API might not be considered the most well designed any longer, but there's hooks for it absolutely everywhere. Most notably, it's used by WSH (the windows scripting host), by IIS (in ASP), by IE, by outlook, by visual studio etc. Microsoft has a compatibility nightmare if they decide to change it by any other means than adding new features. > Assuming that vbscript and silverlight use this same API, I have to > think they'd be pretty conservative with it. Even if it were to change, > it couldn't be that hard for ScreamingMonkey to keep up. First of all, Silverlight uses a brand new scripting engine, called Managed JScript, that runs on the DLR on top of the .NET CLR. Managed JScript doesn't use the Active Scripting APIs at all, from what I've read about it. Second, Microsoft can do absolutely nothing to it except for additions. There are outside users of these APIs from both sides, e.g. the ActiveScripting languages such as ActivePerl, ActivePython, ActiveRuby, HaskellScript use the API from the scripting engine side, while programs such as the JScript/VBScript external IDEs/debuggers as well as several in-house applications in major companies use the API from the host side. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Es4-discuss Digest, Vol 8, Issue 44
On 31/10/2007, Ric Johnson <[EMAIL PROTECTED]> wrote: > I still am missing something. If someone could somehow prove that ES4 is > flawed, do we have actually have a chance to fix it before it is burned > over my childhood memories? How do we do that? Do I need to draw up a > diagram comparing similar systems and show failure rates mathematically > and then mail it to Al Gore? There's features broken and there's language broken. I'd argue that the ES3 regex model is broken, that ES4 could and should fix it*, and that it won't hurt live code to do so but will help making regex in ES make sense. But on the other hand, ES3 has an unambiguous spec on this point, and Opera and Mozilla both seem to implement it as specified. Not fixing it right now would not really hurt the language, the language isn't broken by this feature being broken, except for making it harder to fix in the future (and possibly harder to add new features such as conditionals and lookbehinds). So language not broken, only less useful that it could be. I've yet to see any single argument with technical merit that the language is broken - I've seen broken features, mostly broken since ES3 that can't be fixed without breaking backwards compatibility, but nothing that breaks the language. The argument about ES4 additions size > ES3 size is the only one that seems to have any merit whatsoever, and that only in the way of being somewhat limiting on limited power devices such as mobile phones, where the compiler and vm size must be kept low. > To put another face on it, it seems to me we are being unfair. If Opera > put in a new feature in their browser, I assume most people would just > believe it was their business. BUT if Microsoft decides to put a direct > interpreter for .net in IE8 and CALL it JavaScript (or jScript), we > would ALL cry foul. Is ES4 the new OOXML? In effect, some major > players are getting together to force a standard that the others do not > agree on. Then again, if Microsoft simply did not implement Javscript2, > would the other vendors be happy? I think there'd be considerably more happiness if Microsoft provided a .NET based ECMAScript 4 compliant JScript version in IE8/9, whether based on JScript.NET or as a DLR runtime, than if they didn't provide an ECMAScript 4 engine at all by IE9. Even a COM/IDispatchEx version would be welcomed over not having an ECMAScript 4 engine at all. Sure, we have an effort to get a Tamarin version to hook into IE by COM/IDispatchEx. Who will distribute it (pretty sure Microsoft will not), can it reach enough users to matter? Can the distributor be trusted in corporate environments? Can it be compatible enough with legacy JScript to be used as an all-out replacement? Actually, I'd be more comfortable with an ECMAScript 4 engine based on .NET in IE than I would be with even a Microsoft backed Tamarin engine. I think the more interoperable implementations on different virtual machines the better, and ECMAScript 4 on .NET opens up for single language client and server side code, which I think many developers would like. (Most of them just don't want the single language to be JavaScript...) * I've had the argument before, the idea is simply summed up as: - Backreferences to capturing submatches that have not participated or that failed to match should fail. (In ES3 these succeed at matching the empty string.) - A capturing submatch should be reset only next time it participates in a match. (Instead of each time the containing group is repeated, as ES3 states.) - Backreferences to repeated submatches must always reference the value of the submatch last time it participated and matched. (IE/JScript uses the first match always, even if there are later matches. One example trick that doesn't work in ES3 but works in other regex implementations is this pattern used for conditionals: (?=(a)()|())\1?b(?:\2c|\3d) However, this fails in the ES3 model since all of \1, \2 and \3 will always match the empty string, instead of either both \1 and \2 failing or \3 failing. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM
On 29/10/2007, Robert Sayre <[EMAIL PROTECTED]> wrote: > * Temper tantrums about the name. >(there's really nothing to negotiate, aiui) I can understand wanting to change the name for the reason Steve Yegge mentions in "How to Ignore Marketing and Become Irrelevant in Two Easy Steps" - Both JavaScript and ECMAScript are horrible names. On the other hand they have a considerable mindshare and I think it would be more confusing if the name was changed to something entirely unknown. I don't buy the argument that ES4 shouldn't be named "ECMAScript 4" or "JavaScript 2" because it's too big a a change to it's predecessor however. ES4 has been developed specifically to be an update to ECMAScript 3/JavaScript 1.x. As long as ES4 doesn't throw away considerable parts of ES3 (which it doesn't) then I can't see how that point is valid. The size of the "new" language compared to the size of "old" language isn't important, what's important is the fact it's pretty much entirely additional features that were lacking in the predecessor or added orthogonal mechanisms that makes things possible in the engine that were not possible before. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Syntax for union types
On 27/10/2007, James Clark <[EMAIL PROTECTED]> wrote: > (int, string) doesn't seem to me to be a syntax that the average JS > programmer will guess means union. I would have thought a better choice > would be (int | string) (especially given that regexps use |) or a keyword. Honestly, there's very little in the type system that I think will come entirely natural for ES3 users. Annoted object types look like object initialisers with name-value pairs, annoted array types look like array initialisers, the constructor syntax looks entirely weird, parametric types don't look like anything else in the language etc. And other parts too - destructuring assignment, array comprehensions etc, all look slightly foreign. I really don't think this syntax is that very foreign (it's a quite natural way to list different types something can be after all), and with all the new syntax related to typing, as well as other syntax additions, it's going to be one tiny part of an entire new domain to learn. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Rule 317
> On Tue, 2007-10-23 at 14:58 +0200, liorean wrote:
> > It's there to prevent the grammar from being ambiguous. "function",
> > "let" and "{" have different meaning in statement context from
> > expression context. If the ExpressionStatement construct allowed them,
> > then they would be ambigous in statement context, they could have
> > either the statement or the expression semantics. So, in order to
> > prevent this ambiguity, they are not allowed in ExpressionStatement.
On 23/10/2007, David Teller <[EMAIL PROTECTED]> wrote:
> So I guess this could just be handled by making this rule have a lowest
> priority ?
Not really. In statement context, a function without a name should be
a syntax error, it shouldn't be handled as function expression because
that'd be pointless. If the function object is only accessible through
the return value of the function expression but it's in statement
context - i.e. return values are thrown away - then compiling the
function at all is totally pointless, you're just adding a
non-reachable object for the garbage collector to deal with. In a
statement context, "{" is a block opener and not the beginning of an
object literal. In a block statement "Identifier :" is a label
statement and not a property assignment. "*string* :" is a syntax
error because ":" is not a valid operator there. (Not sure how type
annotations play into this, I might be wrong here...)
So you see, they can't just be lowest priority. They must fail with a
syntax error. For ES3 compatibility's sake, if nothing else. Also,
it's better to not let nonsensical constructs be allowed.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Rule 317
On 23/10/2007, David Teller <[EMAIL PROTECTED]> wrote:
> Hello list,
>
> I'm still fighting the syntax of JS2. Attempting to feed it into a
> parser generator (menhir, for the moment), has already allowed me to
> find a few typoes in the spec and a few useless variables in the
> reference implementation, which is all I have to show for the moment.
> That and the fact that all XML* productions seem absent from the RI.
>
> At the moment, though, I'm being puzzled by rule 317:
>
> ExpressionStatement
> | ListExpression (allowColon, allowIn)
>[if lookahead not in { "function", "let", "{" }]
>
> Besides the fact that this rule is annoying to implement, does it
> actually mean what it intends ? In addition to blocks, it also prevents
> an assignment to an object pattern from starting the ListExpression. Is
> that desired ?
It's there to prevent the grammar from being ambiguous. "function",
"let" and "{" have different meaning in statement context from
expression context. If the ExpressionStatement construct allowed them,
then they would be ambigous in statement context, they could have
either the statement or the expression semantics. So, in order to
prevent this ambiguity, they are not allowed in ExpressionStatement.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: is ES4 getting too bloated?
On 22/10/2007, Brendan Eich <[EMAIL PROTECTED]> wrote: > Give the overview at http://www.ecmascript.org/es4/spec/overview.pdf > a read and let us know what you think. Page 17: "In addition, any value in the language converts to a member of AnyBoolean (undefined, null, zero, and the empty string converting to false and everything else converting to true)." Doesn't NaN belong in the category that autoconverts to false too? -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: instanceof Operator
On 21/10/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Does instanceof operator check 'constructor' property in [proto] chain? No. It uses the [[HasInstance]] private method of the object passed in as the right operand. In the case of 'string' instanceof String; F is String and 'string' is V in the following algorithm: 15.3.5.3 [[HasInstance]] (V) Assume F is a Function object. When the [[HasInstance]] method of F is called with value V, the following steps are taken: 1. If V is not an object, return false. 2. Call the [[Get]] method of F with property name "prototype". 3. Let O be Result(2). 4. If O is not an object, throw a TypeError exception. 5. Let V be the value of the [[Prototype]] property of V. 6. If V is null, return false. 7. If O and V refer to the same object or if they refer to objects joined to each other (section 13.1.2), return true. 8. Go to step 5. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: instanceof Operator
On 21/10/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> var a;
> a= {};
> a instanceof Object //true
> a= [];
> a instanceof Array //true
> a='asdf';
> a instanceof String //false
> a= 7;
> a instanceof Number //false
>
> Why?
Because those are primitives of type double and string respectively.
They are not instances of any of the compound types Object, String or
Number.
Something silly that JavaScript inherited from Java that the world
would be much better off without, but as I understand it won't be
corrected because of real world compatibility problems.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: 'switch' operator improvement
On 16/10/2007, Peter Hall <[EMAIL PROTECTED]> wrote:
> already you can do something like this:
>
> var str;
> switch(true){
> case /a/.test(str):
> alert('a');
> break;
> case /b/.test(str):
> alert('b');
> break;
> }
I can only imagine that solution being preferable to chained
if..else-statements in one case, and that would be if you actually
used the fall through mechanism. If you don't fall through, it's just
bloat without any gain.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: SYNTAX BUG
On 16/10/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > In the next line there is ambigious between RegEx and comment > str.match(//); Not really. // is always a line comment starter in ES3: 7.8.5 Regular Expression Literals /- - -/ NOTE Regular expression literals may not be empty; instead of representing an empty regular expression literal, the characters // start a single-line comment. To specify an empty regular expression, use /(?:)/. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Arrays with non-integer properties
tes), > not an array object with non-integer properties. > It is thus obviously (at least, that's how I analyse it) not the way one > should serialize > such an array. It cannot be serialised using JSON/ES3 literal syntax. Not if you want to retain both the array-ness and the properties with non-array-ish names. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: 13.2.2 [[Construct]], constructor, and [[Class]] (was __proto__)
On 23/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> Function objects get a non-enumerable constructor.
> function F(){};
> F.constructor === Function; // true
> F.prototype.hasOwnProperty('constructor'); //true
> F.prototype.propertyIsEnumerable("constructor"); // false.
Of course.
> Object instances don't, unless it's a prototype object created by
> [[construct]]
> (new F).constructor === F.constructor; // true. Undesirable
Wrong, it's false.
(new F).constructor === F.constructor; // => false
(new F).constructor === F.prototype.constructor; // => true
> This works fine for shallow inheritance
> Objects don't get a constructor
In what way do you mean they don't? Their constructor is the Object
object, as you show next:
> ({}).constructor === Object.prototype.constructor; // True.
> > On 23/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> > > 1. The constructor property should be on the object instance *created*
> > > by the function.
> On 9/23/07, liorean <[EMAIL PROTECTED]> wrote:
> > That argument I agree with. It should be on the instance and not the
> > prototype.
On 23/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> Which is different from the way built ins work, but seems OK.
Well, at least if you want to make sense out of the prototypal
inheritance scheme. The built ins are all single level IIRC,k and
don't need to set up their prototype relationship in user code. A
prototype system that didn't just clobber the old prototype when
setting up prototype chains maybe could have done it better. But that
won't happen in ECMAScript.
> > On 23/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> > > 2. (new function(){}).constructor should be Function.
> On 9/23/07, liorean <[EMAIL PROTECTED]> wrote:
> > I agree.
Actually I don't agree here, see my reply to Brendan earlier.
> > And in ES3 it is, unless the function either:
And I was thinking of (function(){}).constructor here, not (new
function(){}).constructor, when I said in ES3 it is. It isn't, which
is proper since the object is constructed by the anonymous function
object, not the Function object.
On 23/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> When there is an anonymous constructor, we have the ability to get at
> the constructor property.
I don't see this as a problem - the constructor property should be the
function that actually constructed the object. Since ES3 allows any
value (except eval, I think) to be assigned to any variable (except
read only ones and those with special setters), the difference between
function declarations and function expressions is that declarations
are *by default* accessible through a variable name only, and function
expressions are *by default* accessible through the return value of
the expression only. There's no way to actually tell a function
derived from a function expression and a function derived from a
function declaration apart after the fact. (Well, except for that
function expressions make the name optional.)
So, if we want to be able to get at constructors at all, we can't
distinguish between how functions are derived - either we provide the
functionality, or we don't.
> function Animation(element){
>var looped = 0;
>var e = element;
>
>function construct() {
> this.loopCount = function() {
> return looped;
> }
> this.loop = function() {
> looped++;
> }
>}
>return new construct();
> }
>
> new new Animation().constructor().constructor; // construct
Sure. It's a closure, it exposes a property it's told to expose. (If
you use the new keyword, that it exposes the function object as the
constructor property of the constructed object should be expected.)
You can do this without the new keyword if you want to not expose the
function object, or use the delete keyword to explicitly remove it.
> On 9/23/07, liorean <[EMAIL PROTECTED]> wrote:
> > A disagreement of terminology I think. If you ask me, a function
> > instance is a function object. When using a function instance as a
> > constructor, you create an instance of that constructor (== function
> > instance) which is a plain, ordinary, mundane, normal,
> > run-of-the-mill, typical object. (Agh, ran out of synonyms!)
On 23/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> F is a Function instance
> f is a function instance
>
> The terminology is confusing.
F is an instance of Function
f is an instance of F
Function is a function object
F is a function object
f is an object
As I see it, the meaning of "function instance" is an object that is
function-like, in other words a function object or a special host
object (like Function.prototype, which is a function but not an
instance of Function).
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: 13.2.2 [[Construct]], constructor, and [[Class]] (was __proto__)
> > On 23/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> >> 2. (new function(){}).constructor should be Function.
> On Sep 23, 2007, at 8:59 AM, liorean wrote:
> > I agree. And in ES3 it is, unless the function either:
On 23/09/2007, Brendan Eich <[EMAIL PROTECTED]> wrote:
> No:
>
> js> (new function(){}).constructor
> function () {
> }
> js> function C(){}
> js> new C().constructor
> function C() {
> }
Ah, my mistake there, was thinking of (function(){}).constructor for a
moment there.
> in no case is the value of (new function(){}).constructor Function.
Thinking about it with the new keyword in mind, I just realise that
what Garrett suggested makes no sense anyway - the function object is
the constructor. The function object is an instance of Function, but
the resulting object is an instance of the function object. Making the
object have Function as it's constructor property breaks the
prototype-constructor relationship.
> > On 23/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> >> It appears that es4 ref impl has the correct result for instancof
> >> on primitives
> On Sep 23, 2007, at 8:59 AM, liorean wrote:
> > A bugfix, IIRC.
On 23/09/2007, Brendan Eich <[EMAIL PROTECTED]> wrote:
> Incompatbile enough that we are not taking the chance -- we are
> changing this to match ES1-3, and to avoid boolean <: Boolean etc.
Sad to hear that, but I guess compatibility will have to rule here.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: 13.2.2 [[Construct]], constructor, and [[Class]] (was __proto__)
> > On 22/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> > > What I've found is that it's always giving wrong constructor property
> > > with inheritance chains.
> > >
> > > A <-- B <-- C
> > > c = (new C).constructor;// A
> > >
>
> I meant an enumerable superclass property!
> On 9/22/07, liorean <[EMAIL PROTECTED]> wrote:
> > You get that if you do the following:
> >
> > function A(){}
> > function B(){}
> > B.prototype=new A;
> > function C(){}
> > C.prototype=new B;
> >
> > Because if you do that, you replace the prototype containing the
> > original constructor property (e.g. a reference back to the function
> > C) with an instance of another constructor (e.g. B), but that instance
> > doesn't have the constructor property that the original prototype had.
> > If you want to keep the constructor properties, you need to do that
> > manually. (With the obvious result that then the constructor property
> > will be enumerable. Which can be changed through adding a call on
> > propertyIsEnumerable in ES4.)
On 23/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> Ah, sorry, I said a few things wrong!
>
> 1. constructor is DontEnum.13.2 - http://bclary.com/2004/11/07/#a-13.2
> (It's the user-defined superclass property that is enumerable.)
If I wasn't clear on that, the that's the difference between the one
that the implementation would set up for you and the one you'd have to
create manually to preserve the constructor chain in ES3. And ES4
allows for making it non-enumerable manually, so in ES4 code using the
prototypal inheritance model could be rid of this problem, albeit with
a slight cludgyness added to the code because developers actually have
to both add the property to an instance and set it to be
non-enumerable.
> 1. The constructor property should be on the object instance *created*
> by the function.
That argument I agree with. It should be on the instance and not the prototype.
> > On 22/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> > > How about a constructor property on the function instance?
On 23/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> 2. (new function(){}).constructor should be Function.
I agree. And in ES3 it is, unless the function either:
- Returns another object than that it was passed from [[Construct]]
- Creates a constructor property on the this object that is not a function
- Has it's prototype overwritten
A disagreement of terminology I think. If you ask me, a function
instance is a function object. When using a function instance as a
constructor, you create an instance of that constructor (== function
instance) which is a plain, ordinary, mundane, normal,
run-of-the-mill, typical object. (Agh, ran out of synonyms!)
> On 9/22/07, liorean <[EMAIL PROTECTED]> wrote:
> > Which could be done, of course, it should be a simple thing to add
> > that in the algorithm for [[Construct]]. But then we have the question
> > of what to do with constructors that return other objects than that
> > set up by steps 1 through 5 of the [[Construct]] algorithm. A
> > constructor can return other objects, you know.
On 23/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> In ES4, it is a syntax error to specify a result type of a
> constructor. If someone is using new F, the constructor property of
> the instance should be F.
If it's a constructor in the ES4 introduced classical inheritance
sense, I have no arguments against that. And neither do I have any
strong arguments against it for type annoted functions. The rather
weak argument I do have against the latter is that it makes it harder
to simply add type annotations to old type consistent ES3 code and
have it work.
But for ES3 and real web compatibility, I don't think changing the
algorithm to not allow ordinary ES3 functions used as constructors to
return objects other than the one set up by [[Construct]] will work.
Take a look at this article for example:
http://www.digital-web.com/articles/objectifying_javascript/>
It's only one of many articles, tutorials and scripting tips and
tricks I've seen that uses the new keyword that way.
I've actually seen developers arguing that it's a proper way of using
the new keyword since the new keyword makes it clear you're
constructing an object up front instead of using regular function
calls that only make it obvious after you've read the function body.
Typical example is the argument that "new function(...){...}(...)"
makes it's usage as setting up an object more clear than
"(function(...){...}(...))" or "(function(...){...})(...)".
Re: __proto__
On 22/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
> What I've found is that it's always giving wrong constructor property
> with inheritance chains.
>
> A <-- B <-- C
> c = (new C).constructor;// A
>
> So to do this, I can use a chaining technique to hardcode the
> inheritance structure reading __proto__ or using hand-rolled
> constructor chaining, but then that requires that clients who try to
> get the constructor build their inheritance with the same approach
> that I do, and get an enumerable constructor property on their class
> as a side effect.
You get that if you do the following:
function A(){}
function B(){}
B.prototype=new A;
function C(){}
C.prototype=new B;
Because if you do that, you replace the prototype containing the
original constructor property (e.g. a reference back to the function
C) with an instance of another constructor (e.g. B), but that instance
doesn't have the constructor property that the original prototype had.
If you want to keep the constructor properties, you need to do that
manually. (With the obvious result that then the constructor property
will be enumerable. Which can be changed through adding a call on
propertyIsEnumerable in ES4.)
> The chaining technique was published many years ago by Kevin Lindsey
> and used by some popular libraries like YUI.
It's actually far older than that, and I think the Netscape JavaScript
guides and references even contained a crash course in this. I think
it's mentioned in my oldest JavaScript books, published around 1996.
> How about a constructor property on the function instance?
Wouldn't help, the constructor property would have to be set on the
object the constructor builds.
Which could be done, of course, it should be a simple thing to add
that in the algorithm for [[Construct]]. But then we have the question
of what to do with constructors that return other objects than that
set up by steps 1 through 5 of the [[Construct]] algorithm. A
constructor can return other objects, you know. You'd have to decide
whether this property should be set up prior to step 6 in the
algorithm or subsequent to step 7. If prior, only the original object
that was created in step 1 gets it, if subsequent, return values get
it even if they are not the same as the original object.
Actually, I think this would be a nice and simple fix to ES3 that
probably wouldn't hurt much code out there.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Newlines in blockcomments
Hello!
According to ES3, a blockcomment which contains at least one newline
parses like a LineTerminator, and isn't just thrown away. That means
/**/ and /*\n*/ will behave different with regards to all the
constructs that have [no LineTerminator here] limitations.
I doubt this is expected behaviour for developers - developers don't
expect the contents of comments to change the meaning of the code
surrounding it. Further, neither SpiderMonkey, JavaScriptCore nor
JScript seem to obey this part of the ES3 spec. Opera's engines are to
my knowledge the only browser hosted ones that do.
Wouldn't it be better to simply treat all blockcomments alike?
(Opera bug 280849, Mozilla bug 397104)
(function(){
return/*
*/{};
}());
This code returns undefined in linear_b and in futhark, per ES3. This
code returns the object in SpiderMonkey, JScript and JavaScriptCore,
which I think is the behaviour that the vast majority of developers
would expect.
I haven't done any extensive studies of this in the other places where
[no LineTerminator here] can be found in the syntactic grammar.
However, I note that the behaviour is not consistent between
PostFixExpression and ReturnStatement in a few engines.
var
a=0;
a ++;
a /**/ ++;
a/*
*/ ++;
SpiderMonkey and Futhark: SyntaxError
JScript, JavaScriptCore: 2
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Regex: How should backreferences contained in the capturing match they reference to work?
On 14/09/2007, Brendan Eich <[EMAIL PROTECTED]> wrote: > "Almost all" excludes IE JScript, right? Well, it doesn't agree with me on what is the right approach, but it does agree with me that the ES3 approach is wrong. > Those implementations are > JavaScriptCore, based on PCRE, and what else? The only implementations that I know of that specifically implement the ES3 algorithms are those in SpiderMonkey, linear_b and futhark (I have no idea about SEE, Rhino, and a lot of other fringe JS engines however). And the ES4 refimpl I guess. I only said "almost all" because I haven't tested each and every one. It could be possible that the only ones behaving according to the ES3 algorithm *at all* are indeed those written to match the ES3 algorithms. It's also possible that there are those that do match the ES3 algorithms but are not written specifically for them - I just don't know of any such implementation. JavaScriptCore uses PCRE, so of course it's not written specifically for the ES3 algorithms. The JScript one is shared with at least VBScript, and I wouldn't be surprised if it was shared with VB, VBA and other COM environments as well. I don't think it's written specifically for the ES3 algorithms. It's peculiar, and I think it doesn't agree with anybody else on a few edge cases besides those I've brought up. > Again, it's the Perl connection. Not only. Both Perl and those POSIX flavour regex that implement capturing submatches... -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Regex: How should backreferences contained in the capturing match they reference to work?
On 14/09/2007, liorean <[EMAIL PROTECTED]> wrote: > Maybe you don't. But almost all regex implementations that implement > capturing submatches that are specifically implementing the ES3 > algorithm agree with me. s/that are specifically/that are not specifically/ -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Regex: How should backreferences contained in the capturing match they reference to work?
> On 9/13/07, liorean <[EMAIL PROTECTED]> wrote: > > That the spec doesn't match expectations and that there are behaviours > > that do make sense to replace it with, coupled with the fact there > > seems to be no obvious compatibility problem with changing it > > (otherwise JScript and JavaScriptCore surely would have been changed > > to match the ES3 behaviour), makes no compelling reason? On 13/09/2007, Lars T Hansen <[EMAIL PROTECTED]> wrote: > I hope I'm not being overly flip when I say that it is the spec that > circumscribes the set of expectations you are allowed to have. And > the spec is entirely clear here, ie what it says is not in question, > even if it's not always easy to find out what it says. A somewhat > determined developer who needs to rely on the behavior can discover > what behavior is expected (though he obviously can't trust the > implementations to get it right). Expectations are never formed from the spec, and that is especially true of ECMAScript since the spec is quite hard to read for laymen. Expectations are formed from a logical application of the perceived concepts underlying the language features. Regex are a special case here as well, since most regex articles and tutorials are not particularly language specific, they are typically only specific to the generalised flavour (the Perl flavour and POSIX flavour, respectively). In fact, for a long time the only JavaScript specific regex article that a fast search could find that was the one I wrote for eVolt in 2002. > It's your contention that developers will be surprised by the current > behavior. What can I say? Edge cases will always surprise somebody. > I don't feel surprised that captures are thrown away when a repeat > matcher repeats, even if you do. Maybe you don't. But almost all regex implementations that implement capturing submatches that are specifically implementing the ES3 algorithm agree with me. > Warnings are pointless on the web, and the language has no warnings > now. If we're going to do something about backreferences inside their > own captures, it would have to be to outlaw them and require a syntax > error. Warnings are pretty much useless today, yes. But you can always hope for better debugging and development tools. > I doubt we're inclined to make any incompatible changes to the > matching algorithm, and (again) I don't really see the point. That's why I stressed that JScript and JavaScriptCore, and according to Brendan above also Tamarin, fail to implement this according to ES3. It's not an incompatible change - it can't be if the two most common engines are incompatible with the spec. (I gather that'd be JScript and Tamarin.) That pretty much guarantees that there's no code relying on the spec behaviour. On 14/09/2007, Lars T Hansen <[EMAIL PROTECTED]> wrote: > I oppose this on merely Perl compatibility grounds -- ES regexes have > since evolved through other influences -- but sure, we'll give it a > fair hearing. I'm glad to hear that it'll get a fair hearing. Just throw some logs on the fire however, these all agree on backreferences to failed submatches failing to match anything-including-the-empty-string: JGsoft, .NET, Java, Perl, PCRE, Python, Ruby, Tcl ARE, POSIX BRE (according to http://www.regular-expressions.info/refflavors.html>, I haven't actually tested in all those) You can of course argue that "failed submatches fail to match" is not the same as "not-yet-captured submatches fail to match" - that would require some testing, and the only one that I have accessible personally right now is Perl. On 14/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote: > You're post on ES4 list would make for an excellent tutorial on RegExps. I've been asked to do RegExp tutorials before... http://www.evolt.org/article/Regular_Expressions_in_JavaScript/17/36435/> > I think a lot of web devs, including myself, don't have such deep > knowledge of RegExps. The differences in script engines show that it's > more than web devs who misunderstand the spec. You're examples, > including the ones on your blog, indicate that RegExps in js have some > counter-intuitive behavior. Yes. I've been meaning to flesh that out in another blog entry. Probably will have to wait until next week however. > I think it would be excellent material for an article on > developer.mozilla.org. Something to consider, at least. Ah. The problem of choosing where to place your articles... in fact, I'd probably prefer to place any future articles on dev.opera.com (I think Opera is seriously under appreciated by developers, so anything to help...). Or on eVolt, since I like that place. I think I can
Re: Regex: Named groups/backreferences
Ah, just the answers I wanted to hear:) -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Regex: How should backreferences contained in the capturing match they reference to work?
On 13/09/2007, Lars T Hansen <[EMAIL PROTECTED]> wrote: > My answer to you is obviously that you should implement the ES3 > behavior (as should JScript and JavaScriptCore). Of course I'll implement the ES3 behaviour if ES4 makes no change to it, I just think it would be better to change the behaviour to something that actually matches developer expectations instead. > The current behavior > is well-defined; it's not a hardship for anyone; the incompatibilities > among the engines are probably not a big deal (thus the incompatible > engines can be changed so that they conform); thus there is no > compelling reason to change the spec either. That the spec doesn't match expectations and that there are behaviours that do make sense to replace it with, coupled with the fact there seems to be no obvious compatibility problem with changing it (otherwise JScript and JavaScriptCore surely would have been changed to match the ES3 behaviour), makes no compelling reason? > > ES3: If I understand 15.10.2.5 Term, fourth algorithm, point 4, the > > correct results would be ['ab','a','b'] since the \2 capture would be > > set to undefined before the second repetition. Thus futhark and > > SpiderMonkey fail to implement this part of ES3 Regex. (I'd be happy > > if it turned out I'm wrong here, however.) > > FWIW, the ES4 RI agrees with Mozilla and Opera. > > Trying to trace the matching above, we have: > ...+ >(?:...) > (\2|a) succeeds without consuming input > (b)? succeeds without consuming input >so (?:...) succeds without consuming input > so ...+ starts backtracking [step 1 of the continuation for RepeatMatcher] > so (\2|a) succeeds, consuming "a" > and (b)? succeeds, consuming "b" >so (?:...) succeeds consuming "ab" with captures [a,b] > and ...+ repeats: >(?:...) > (\2|a) succeeds without consuming input > and (b)? succeeds, consuming "b" >so (?:...) succeeds consuming "b" with captures [,b] > and ...+ repeats: >(?:...) > (\2|a) succeeds without consuming input > (b)? succeeds without consuming input >so (?:...) succeds without consuming input > so + starts backtracking > so (\2|a) succeeds, consuming "a" > and (b)? succeeds without consuming input >so (?:...) succeeds consuming "a" with captures [a,] > so ...+ succeeds, matching "abba" with final capture array [a,] > > Sorry for the lack of rigor in the above, but I believe that's correct. Ah, the "undefined really means a match with the empty string" thing again. I should have known... -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Regex: Named groups/backreferences
Hello! Got some questions about named groups: "Group names must be valid lexical identifiers, and each group name must be defined only once within a regular expression." 1. Is this meant to indicate that regex add their own lexical scopes; partake in the lexical scope of their containing function if any; that the identifier must be unique within the regex and that that null, true, false, this etc. that are reserved keywords cannot be used (i.e. the Identifier construct); or just that they need to conform to the identifier syntax but reserved keywords are allowed (i.e. the IdentifierName construct)? 2. Can (?P=varname) refer to a lexical variable varname from a containing scope, or just to groups within the regex itself? 3. If it can refer to a variable in a containing scope, what constraints are put on the variable type, what conversions are made, etc? -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Regex: How should backreferences contained in the capturing match they reference to work?
Sorry for delaying my response on this. Wanted to get some public
opinions on it:
http://web-graphics.com/2007/09/05/a-quick-js-quizz-for-anybody-who-think-they-know-regex/>
Sadly I only got responses from two developers, but they both seem to
agree with me (and I was careful to not state my opinion there)...
> On 9/2/07, liorean <[EMAIL PROTECTED]> wrote:
> > var
> > re=/(a\1)+|b/,
> > a=[],
> > key,
> > aab=re.exec('aab')
> > aaab=re.exec('aaab');
> > for(key in aab)
> > a.push('aab["'+key+'"]: '+aab[key]);
> > for(key in aaab)
> > a.push('aaab["'+key+'"]: '+aaab[key]);
> > a.join('\r\n');
On 03/09/07, Lars T Hansen <[EMAIL PROTECTED]> wrote:
> From the spec it's pretty clear (to me anyhow) that SpiderMonkey and
> Opera are correct here (and the ES4 reference implementation, whose
> RegEx engine was modelled directly on the spec, agrees). The
> reasoning is that (a) the **undefined** value in the captures array
> matches any input without advancing the input pointer [15.10.2.9 step
> 8 substep 3], (b) every element in the captures array starts out as
> **undefined** [15.10.2.2 step 2 substep 4], (c) every element in the
> captures array affected by a particular set of capturing parens is
> reset to **undefined** every time those parens are entered [15.10.2.5
> case "RepeatMatcher" step 4], and (d) the captures array is only
> updated after the capturing parens are exited during matching
> [15.10.2.8 case "( Disjunction )" step 3 substep 1 subsubstep 5].
> Therefore the pattern above is always the same as /(a)+|b/. Therefore
> the results are what they are.
Seems I've been looking in entirely the wrong places. Yes, that seems correct.
> On 9/2/07, liorean <[EMAIL PROTECTED]> wrote:
> > It seems to me that, looking at the situation from the perspective of
> > a user of regex, that there are two ways of tackling this problem that
> > makes sense, and they are hinged on whether a captured submatch is
> > considered to be undefined or the empty string by default.
On 03/09/07, Lars T Hansen <[EMAIL PROTECTED]> wrote:
> In ES3 they are clearly **undefined** by default.
This was, as stated, looking from the perspective of a *user* or
regex, not an implementer. The ES3 spec is actually the solution that
makes least sense from the user perspective, if you ask me. I'd even
call it a weird choice, given the alternatives. To throw out a
submatch before trying to match it the next time instead of just
replacing the submatch value after the next match is unintuitive
behaviour.
> On 9/2/07, liorean <[EMAIL PROTECTED]> wrote:
> > If the capture is considered to be undefined by default, then the ES3
> > solution makes most sense... except for one thing: a capturing
> > submatch containing a backreference to the containing capture means a
> > guaranteed failure to match in that path, and is pretty easy to detect
> > at compile time.
On 03/09/07, Lars T Hansen <[EMAIL PROTECTED]> wrote:
> The way I understand the spec it means a guaranteed success. Still
> pretty silly, to be sure.
This is what I was misunderstanding - that the behaviour for when the
capture was undefined actually meant a match for the empty string.
> On 9/2/07, liorean <[EMAIL PROTECTED]> wrote:
> > Throwing a syntax error at compile time seems more
> > appropriate since I hardly think developers want their regex to spend
> > time in constructs that cannot possibly match. Alternatively, engines
> > can simply throw out that entire path at compile time and just set all
> > the contained captures to undefined - behaviour would still be
> > identical to what ES3 specifies. I.e. it's a choice between loud or
> > silent failure.
On 03/09/07, Lars T Hansen <[EMAIL PROTECTED]> wrote:
> Or a vacuous and silent success, as in this case.
Which makes less sense than either the JavaScriptCore or the JScript
behaviour, IMO.
On 03/09/07, Lars T Hansen <[EMAIL PROTECTED]> wrote:
> I'm not sure what problem you're trying to solve, but my hope is that
> once ES4 is widely implemented programmers will switch to named
> submatches to avoid the problem with numeric backreferences entirely.
The problem is the same whether it's named or not, I think. Consider:
/(?Pa(?P=as))+|b/.exec('aaab');
Is the behaviour of that any different from the behaviour of these:
/(a\1)+|b/.exec('aaab');
/(?Pa\1)+|b/.exec('aaab');
Since in this case, unless I've misunderstood the proposal, (?P=as) is
just an alias for \1.
Re: __proto__
> On 9/11/07, liorean <[EMAIL PROTECTED]> wrote:
> > It also means
> > that a prototype that is thrown away after setting up the object will
> > now be accessible.
On 11/09/2007, Lars T Hansen <[EMAIL PROTECTED]> wrote:
> That I don't get. The object is the prototype object of some other
> object, the garbage collector can't collect the proto until the
> referencing object can be collected. It's pretty clear to me that you
> can't fold the prototype into the object itself without a lot of extra
> machinery. Perhaps you can provide a concrete example?
Not anything in production code. Conceptually:
function F(){}
/* add some prototype properties here */
newObj=new F;
F.prototype={constructor:F};
That way, you've protected the newObj.[[prototype]] object from being
modified by throwing it away - the only reference to it is from
newObj, and that one isn't exposed. The usefulness of doing this
instead of using scope is not obvious to me, however, it was just
another case of how to make a [[prototype]] unaccessible from the
normal language mechanics that I could think of.
> On 9/11/07, liorean <[EMAIL PROTECTED]> wrote:
> > This would get rid of the need for a function call (Crockford's object
> > function for instance) for setting up plain ES3 prototypal
> > inheritance, and would mean some structures that are not currently
> > serialisable as JSON despite being plain value structures would become
> > serialisable.
On 11/09/2007, Lars T Hansen <[EMAIL PROTECTED]> wrote:
> I can't argue about the serialization bit.
>
> I love to argue about performance, though, so I'll take your "get rid
> of the need for a function call" as an argument about performance and
> proceed from there :)
Actually, it's not performance that I was thinking of. I just prefer
the option of making the prototype relation declarative in a JSON-like
initialiser (obviously we need variable names for it to work, so it
wouldn't be *entirely* compatible with current JSON) instead of
requiring a call to a function where the only thing the function call
would be there to do is to set up a reference to a prototype object.
Not only do you need to do the call, by the way, you also need to
change from object instanciator to member assignments.
It's mostly about giving the scenario a clean looking code. Contrast
the following:
function inheritFrom(o){
function F(){}
F.prototype=o;
return new F;
}
var
a={ /* declare some properties*/ },
b=inheritFrom(a);
b['prop0']='blah';
b['prop1']='blah';
/* ... */
to the following:
var
a={ /* declare some properties*/ },
b={
"[[Prototype]]": a,
prop0: 'blah',
prop1: 'bleh'};
I would consider being able to keep using the object instanciator when
you want to set up a relation like that a real plus when it comes to
code clarity.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: __proto__
On 11/09/2007, Lars T Hansen <[EMAIL PROTECTED]> wrote:
> On the one hand, __proto__ is another potential security hole, and it
> prevents implementations from sharing prototype objects among multiple
> documents -- the link may be read-only but the object isn't. Function
> B called from function A with object O may hack O.__proto__ and A can
> do nothing about it; suddenly all O-like objects in the system act
> differently.
>
> On the other hand, Constructor.prototype is generally available for
> any Constructor, so it's hard to see what the real damage is -- it's
> not obviously worse than some other aspects of the language.
For ES3 code, exposing __proto__ means that prototypes on constructors
protected by scope (as is becoming practice by at least library
writers today) are exposed, which they weren't before. It also means
that a prototype that is thrown away after setting up the object will
now be accessible.
> On the third hand, some implementations may have specialized objects
> for which no Constructor is available and for whom keeping
> [[Prototype]] unavailable is desirable. Similarly, some toolkits may
> have private prototype objects that are not available to client code
> because the constructor is hidden in a lexical scope (ES3) or
> package/namespace (ES4).
>
> Introspection is great, but it assumes a lot about how trust works in
> the environment.
Hmm. On another note: Would it be reasonable to standardise a way to
attach a prototype chain to a plain object instanciator? (Instead of
reading one out of an object...)
var
someObject={
mySharedValue: value},
someOtherObject={
"[[prototype]]": someObject};
This would get rid of the need for a function call (Crockford's object
function for instance) for setting up plain ES3 prototypal
inheritance, and would mean some structures that are not currently
serialisable as JSON despite being plain value structures would become
serialisable.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: isPropertyEnumerable is going to stay broken?
> On Sep 8, 2007, at 10:06 PM, Garrett Smith wrote: > > but such functionality in the > > language seems necessary. How to check enumerable attribute, including > > the prototype chain? On 10/09/2007, Brendan Eich <[EMAIL PROTECTED]> wrote: > Either reflect the __proto__ (read-only, please) property as some > implementations do, or hardcode the prototype structure and code your > propertyIsEnumerable tests accordingly. Would it be possible to add an optional boolean parameter for searching including the whole prototype chain, so that we get a mechanism to do this that doesn't depend on implementation specifics or code structure? -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Regex: How should backreferences contained in the capturing match they reference to work?
Hello,
I've been playing around with implementing ES3/ES4 regex, (more based
on observation of what the browser hosted engines seem to do than by
the spec, since I'm trying to build a non-backtracking engine) and
noted this case where the browsers don't agree:
var
re=/(a\1)+|b/,
a=[],
key,
aab=re.exec('aab')
aaab=re.exec('aaab');
for(key in aab)
a.push('aab["'+key+'"]: '+aab[key]);
for(key in aaab)
a.push('aaab["'+key+'"]: '+aaab[key]);
a.join('\r\n');
JavaScriptCore:
aab["0"]: b
aab["index"]: 2
aab["input"]: aab
aaab["0"]: b
aaab["index"]: 3
aaab["input"]: aaab
JScript:
aab["input"]: aab
aab["index"]: 0
aab["lastIndex"]: 1
aab["0"]: a
aab["1"]: a
aaab["input"]: aaab
aaab["index"]: 0
aaab["lastIndex"]: 3
aaab["0"]: aaa
aaab["1"]: aa
SpiderMonkey:
aab["0"]: aa
aab["1"]: a
aab["index"]: 0
aab["input"]: aab
aaab["0"]: aaa
aaab["1"]: a
aaab["index"]: 0
aaab["input"]: aaab
futhark:
aab["0"]: aa
aab["1"]: a
aab["index"]: 0
aab["input"]: aab
aaab["0"]: aaa
aaab["1"]: a
aaab["index"]: 0
aaab["input"]: aaab
linear_b:
aab["0"]: aa
aab["1"]: a
aab["index"]: 0
aab["input"]: aab
aaab["0"]: aaa
aaab["1"]: a
aaab["index"]: 0
aaab["input"]: aaab
ES3 spec:
From my reading of 15.10.2.9 AtomEscape, this matches what
JavaScriptCore does except for that ES3 defines the captures and sets
them to undefined, whereas JavaScriptCore doesn't seem to define them
at all - They are missing from the results rather than included with a
value of undefined.
As you can see, three different ways to interpret the handling:
JavaScriptCore:
Full match on 'aaab': 'b',
First capture: not defined
My guesson how this parsing works:
First repetition, capture is not-yet-defined so the
backreference fails to match anything, which means it goes to the
alternate path.
JScript:
Full match on 'aaab': 'aaa',
First capture: 'aa'
My guess on how this parsing works:
First repetition, the first capture is '', thus the
submatch is on 'a'+''='a', which is the new value of the first
capture.
Second repetition, first capture is 'a', thus the submatch
is on 'a'+'a'='aa', which is the new value for the first capture.
This is consistent with what happens as you add more 'a's
to the string being matched.
SpiderMonkey, futhark, linear_b:
Full match on 'aaab': 'aaa',
First capture: 'a'
My guess on how this parsing works:
First repetition, the first capture is set to '', thus the
submatch is on 'a'+''='a', which is the new value of the first
capture.
Second repetition, first capture is reset to '', thus the
submatch is on 'a'+''='a', which is the new value for the first
capture.
Third repetition, first capture is reset to '', thus the
submatch is on 'a'+''='a', which is the new value for the first
capture.
It seems to me that, looking at the situation from the perspective of
a user of regex, that there are two ways of tackling this problem that
makes sense, and they are hinged on whether a captured submatch is
considered to be undefined or the empty string by default.
If the capture is considered to be undefined by default, then the ES3
solution makes most sense... except for one thing: a capturing
submatch containing a backreference to the containing capture means a
guaranteed failure to match in that path, and is pretty easy to detect
at compile time. Throwing a syntax error at compile time seems more
appropriate since I hardly think developers want their regex to spend
time in constructs that cannot possibly match. Alternatively, engines
can simply throw out that entire path at compile time and just set all
the contained captures to undefined - behaviour would still be
identical to what ES3 specifies. I.e. it's a choice between loud or
silent failure.
If the capture is considered to be the empty string by default, then
the JScript solution makes most sense. There's little logic in
resetting the capture to the empty string once the submatch has been
captured.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: some errata in PDF
> > On 26/08/07, Garrett Smith <[EMAIL PROTECTED]> wrote: > > > Missing: > > > Function.prototype.caller > On 8/25/07, liorean <[EMAIL PROTECTED]> wrote: > > Should this property really be on the prototype? On 26/08/07, Garrett Smith <[EMAIL PROTECTED]> wrote: > It's useful for two cases: > 1. Debugging > 2. enforcing an entry point to a constructor. Neither of these cases seems to have anything at all to do with the prototype, if you ask me. I don't see why you would ever want to access the caller property on the prototype. The property is not useful for the prototype itself (which is a function of zero formal parameters with an empty function body returning nothing) since the only case you could access it is from a called function, and the prototype having an empty function body means it does not access it when called, so there is absolutely no need for it. Nor would it be useful for function instances to delegate to the prototype, since the value is only interesting per instance. Even further, it's not really appropriate to have it on the function object of instances at all, since it only makes sense when the function has been called, i.e. in the function body itself. A much more sensible place to put it is on the arguments object, since that is per instance, per call. Having it on the function object at all is itself simply bad design coming from Netscape's hurried implementation. It being accessible through the function object is a language wart, plain and simple. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: some errata in PDF
On 26/08/07, Garrett Smith <[EMAIL PROTECTED]> wrote: > Missing: > Function.prototype.caller Should this property really be on the prototype? Even placing it on the Function instances alone seems a bad idea to me, since the value is per call and not per function object. But placing it on the Function prototype seems an even worse idea. It should really be a property on the function object only for compatibility reasons in engines which have to use it (and even then only exist while the function is executing). > Function.prototype.name ? Makes more sense - the Function prototype is a function per ES3, so if function instances should have a name property, then the Function property should probably have it as well. IIRC ES3 doesn't specify it, but it's in the browser hosted engines. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: class prototype object vs class instance properties
On 17/08/07, Garrett Smith <[EMAIL PROTECTED]> wrote:
> What is the difference between a class's prototype object and it's
> instance properties?
Prototype properties are fallbacks if the property does not exist on
the instance.
> class A {
> var x : uint = 10; // instance property.
> prototype var x : uint = 20; // another instance property in the
> prototype chain.
> }
>
> class B extends A { }
>
> My understanding is that the result would be:
>
> new B().x; // result is 20.
>
> What would be the benefit of a class having a prototype over 9instance
> properties/methods?
Prototype properties can be shadowed by instance properties without
being changed, prototype properties are fallbacks if the instance
property does not exist, and prototype properties are not part of the
actual instance, so can be used as memory footprint reduction if one
has lots of instances that don't need separate values for that
instance property.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Self type
> Peter Hall wrote:
> > type B = {b:Self};
On 14/08/07, Cormac Flanagan <[EMAIL PROTECTED]> wrote:
> Yes, I think this should be fine.
I'm all for allowing recursive structural types e.g. for use as binary
trees or linked lists.
type BinTree = {sin:Self, dx:Self, value:*};
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Question about joined function object of ECMA-262 3rd edition
On 05/08/07, Shijun He <[EMAIL PROTECTED]> wrote:
> I read your post again today. And I found the key point is the
> definition of "Equated".
Yeah, but my argument was flawed since the spec never actually says
what I read out from it.
> 13.1.1
> Both uses obtained their FunctionBody from the same location in the
> source text of the same ECMAScript program. This source text consists
> of global code and any contained function codes according to the
> definitions in section 10.1.2.
>
> Q1: what is "source text of the same ECMAScript program" or "this source
> text"?
"this source text" refers to this: "... FunctionBody from the same
location in the source text of the same ECMAScript program"
"the same location in the source text of the same ECMAScript program"
refers to the source code being from the same place in the same
program (or file), not different places in the same program, or from
different programs.
> Q2: what is global code and what is contained function codes?
I included the definition of global code and function code right after
the equated grammar productions quote:
10.1.2 Types of Executable Code
There are three types of ECMAScript executable code:
• Global code is source text that is treated as an ECMAScript
Program. The global code of a particular Program does not include any
source text that is parsed as part of a FunctionBody.
/.../
• Function code is source text that is parsed as part of a
FunctionBody. The function code of a particular FunctionBody does not
include any source text that is parsed as part of a nested
FunctionBody. /.../
Global code is straightly as defined. By "any contained function
codes" they refer to the function codes of the functions that are
joined, and from the use of the word "any" presumably their nested
function codes as well.
> Let's give a example here:
>
> function A() {
> return function B(x) {
> return x * x;
> }
> }
> var b1 = A();
> var b2 = A();
>
> Is the "source text" means all code or just means "return x * x"?
> I think it means all codes, then the global code of it is:
> function A() {...}
> var b1 = A();
> var b2 = A();
> The contained function codes are:
> return function B(x) {...}
> and
> return x * x;
>
> You said: "if a nested function relies on the containing function, the code
> it relies on is not part of either the global code or it's contained
> function code"
>
> So I don't understand it. Do you mean the source text should be "return x *
> x"?
The contained function code of B is "return x * x", yes, and the
joined functions are B, but from different calls to A, so they have
different [[Scope]]. Now, consider this code:
function A(y) {
return function B(x) {
return x * y;
}
}
var
b1 = A(1),
b2 = A(2);
Here the contained function code of B is "return x * y". The function
bodies are in the terms of ES3 equated - their only difference is
[[Scope]]. Which means that b1 and b2 formally may be joined here, but
an implementation cannot reuse the same function object since the y
variable from closure is used (i.e.B depends on the containing
function A). The engine would have to actually implement the joining
mechanism or some equivalent*.
My argument was wrong here - since y is part of A's variable object
and not B's variable object, I considered it part of the containing
function code (A's code). But it really isn't, so the flaw in my
argument.
* Actually implementing the joining mechanism is not an optimisation
by any means - I cannot see it actually improving the engine in any
area, neither memory footprint, byte code size nor performance. The
optimisation lies in the cases where you can skip having different
objects at all, not in the case of having two objects that are always
in sync. Keeping two distinct but identical objects in sync after they
have been created is a net loss performance wise and footprint wise,
not a net gain. Every change to a propety of one of the joined
function objects have to be duplicated on the other object.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Question about joined function object of ECMA-262 3rd edition
On 04/08/07, Shijun He <[EMAIL PROTECTED]> wrote: > On 7/27/07, liorean <[EMAIL PROTECTED]> wrote: > > Functions with different scope may be joined, but only if the scope > > difference will lead to no externally observable difference. > > I would like to say my opinion again: though your words is very > reasonable, and I believe that may be the original meaning of the > authors of es3, but I can't read it from the specification. The spec > only say if there is no observable diff, then the impl could not only > join them but also use the same object at all. You're right, the specification doesn't say it outright. The specification is made for implementators though. The implementing joined functions for *more* than the special case of when the difference is not externally observable is not possible without breaking the semantics of the scoping and closure mechanisms of the language. In fact, even joined functions for the special case of no externally observable differences is tricky - if "externally observable" only refers to variable scoping, then certain valid ES3 programs *will* have ambiguous semantics - those programs that use global objects or the joined function object itself as storage. Both Neil Mix and Lars T Hansen gave examples which show the ambiguity of the language due to allowing joined function objects even in the case of only doing them for the case of no externally observable differences. > You know english is not my native language, so may be I misunderstand it. No, you don't misunderstand it. I just read more between the lines than you do. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Question about joined function object of ECMA-262 3rd edition
> On 7/27/07, liorean <[EMAIL PROTECTED]> wrote: > > x()===y() may return false the same way x()===x() may return false. > > Functions in JavaScript may have side effects, and the same input > > doesn't necessarily give the same output in cosecutive uses of the > > function. On 27/07/07, Shijun He <[EMAIL PROTECTED]> wrote: > No, I don't mean side effect, and there is no side effect in this > case. The result may be not equal just because they have diff > [[Scope]]. The function objects may not be joined if the they are dependent on different scopes. They may only be joined under the circumstance that the difference in scopes does not give a difference in observable behaviour. > On 7/27/07, liorean <[EMAIL PROTECTED]> wrote: > > Functions with different scope may be joined, but only if the scope > > difference will lead to no externally observable difference. On 27/07/07, Shijun He <[EMAIL PROTECTED]> wrote: > Could you point out in where the spec defines such condition? > > The spec only says: ...an implementation may detect when the > differences in the [[Scope]] properties of two or more joined Function > objects are not externally observable and in those cases reuse the > same Function object rather than making a set of joined Function > objects. > > My impression of it is: if the differences in the [[Scope]] are > externally observable, then the implementation can't reuse the same > object, but can make a set of joined Function objects. I think the meaning is rather that of: "If implementing joined functions, engines may instead simply reuse the same function object" than of "For this special case of joined functions, an engine may reuse the same function object" because of the wording of the prior and next sections. 13.1.1 Equated Grammar Productions • Both uses obtained their FunctionBody from the same location in the source text of the same ECMAScript program. This source text consists of global code and any contained function codes according to the definitions in section 10.1.2. /.../ 10.1.2 Types of Executable Code There are three types of ECMAScript executable code: • Global code is source text that is treated as an ECMAScript Program. The global code of a particular Program does not include any source text that is parsed as part of a FunctionBody. /.../ • Function code is source text that is parsed as part of a FunctionBody. The function code of a particular FunctionBody does not include any source text that is parsed as part of a nested FunctionBody. /.../ I.e. if a nested function relies on the containing function, the code it relies on is not part of either the global code or it's contained function code and in other words can't be equated. 13.2 Creating Function Objects / - - - / Step 1 allows an implementation to optimise the common case of a function A that has a nested function B where B is not dependent on A. In this case the implementation is allowed to reuse the same object for B instead of creating a new one every time A is called. Step 13 makes this optimisation optional; an implementation that chooses not to implement it will go to step 2. Note "where B is not dependent on A" and "an implementation that chooses not to implement it will go to step 2". As I understand it, this part of the spec was written with that particular optimisation in mind. Joined objects are just a way for the specification to allow it. Also, IMO it's one part of the spec that should be removed in ES4. It makes the semantics of certain valid ES3 programs ambiguous. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Question about joined function object of ECMA-262 3rd edition
On 26/07/07, Neil Mix <[EMAIL PROTECTED]> wrote:
> Wait, am I following this correctly in that:
[snip]
> var x = A();
> var y = A();
>
> x.foo = 1;
> y.foo = 2;
>
> alert(x.foo + y.foo);
>
> would show "3" in current compliant implementations, but
> theoretically in the future an implementation could exist that would
> show "4" and *still be compliant*? If I'm surmising correctly, then
> that seems...buggy.
Yes, you're following it correctly. Yes, this feature of the spec is
"buggy", in the sense that you have two incompatible behaviours that
are both correct according to the spec. So in a way, we're fortunate
the most wide spread engines don't use joined function objects.
On 27/07/07, Shijun He <[EMAIL PROTECTED]> wrote:
> Moreover, the spec says (13.1.2):
>
> NOTE Two or more objects joined to each other are effectively
> indistinguishable except that they may have different internal
> properties. The only such internal property that may differ in this
> specification is [[Scope]].
>
> As I understand, that means, if x and y are joined, then:
> x === y returns true, but
> x() == y() may return false, because their [[Scope]] may differ.
x()===y() may return false the same way x()===x() may return false.
Functions in JavaScript may have side effects, and the same input
doesn't necessarily give the same output in cosecutive uses of the
function.
Functions with different scope may be joined, but only if the scope
difference will lead to no externally observable difference. For
example:
function mkFn(x){
return function fn(y){
return y*y;
}
}
var
fn1=mkFn(1),
fn2=mkFn(2);
The variable x in mkFn will give no externally observable difference
in fn1 and fn2, thus fn1 and fn2 may be joined. If fn did use x
however, they couldn't be joined because then that would lead to an
externally observable difference.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Question about joined function object of ECMA-262 3rd edition
> Shijun He scripsit:
> > function A() {
> > function B(x) { return x*x }
> > return B
> > }
> >
> > var b1 = A();
> > var b2 = A();
> >
> > Spec says: b1 and b2 can be joined, implementation may make b1 and
> > b2 the same object because [[scope]] of them have no difference.
> >
> > Two call of A() will produce a function from the same FunctionBody, so
> > they are equated and the result function objects can be joined, am I
> > right?
On 26/07/07, John Cowan <[EMAIL PROTECTED]> wrote:
> It is not because b1 and b2 come from the same FunctionBody, but because
> the function B has no persistent state, that they can be joined (which
> is just a way of saying they are the same object). Because A has no
> local variables, B doesn't have to care that it was nested inside A.
A could have any number of local variables, b1 and b2 could still be
joined. The important factor is that it doesn't use variables from the
containing scope(s), so there is no observable difference.
> Shijun He scripsit:
> > function C(x) {
> > function D() { return x*x }
> > return D
> > }
> >
> > var d1 = C(1);
> > var d2 = C(2);
> >
> > Are these two call of A() also are equated uses of the same source?
On 26/07/07, John Cowan <[EMAIL PROTECTED]> wrote:
> No. In this case, d1 and d2 have to be different objects, because they
> have different persistent states: within d1, the variable x (which is
> free in D) is bound to 1, but within d2, the variable x is bound to 2.
> Thus d1 and d2 must be different objects.
Only because they actually use the variable x, however. They don't
have to have identical scope to be joined, but they have to be
outwardly indistinguishable. Any nested function which only uses
variables from it's own variable object can be joined. It's also
possible to join function objects in some cases where they do use
variables other than from their own variable object, given that all
variables used are guaranteed to be the same - while doing this
joining is a memory footprint optimisation, it will make for more
complex (i.e. slower) compilers however.
On 26/07/07, John Cowan <[EMAIL PROTECTED]> wrote:
> In the A-B case, it is not a requirement that b1 and b2 are the same
> object, but interpreters are permitted to make this optimization to
> save on allocation. Whether any of them actually do the optimization
> is another question. It may be more trouble than it's worth. However,
> a proper ES compiler would probably want to do so.
If any implementation would chose to do the joined objects behaviour,
are they not more likely to actually just use a reference to the same
function object instead of joining two different objects? Joining
different function objects doesn't make sense if you can actually use
the same object - after all, each removal or addition of a property on
a joined function object will take extra time depending on how many
other function objects it's joined to, each creation of a joined
function object will require one enumeration of all properties of the
original function object, and each joined function object will take up
memory.
However, I think the compiler complexity added for implementing this
will give a negliable reduction in footprint, so most implementors
haven't found it worthwile to do it.
--
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
