Single argument Array.prototype.splice

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Single argument Array.prototype.splice

Allen Wirfs-Brock-2

ES3 and 5 specify Array.prototype.splice such that [1,2,3].splice(1) means the same thing as [1,2,3].splice(1,0)

 

Mozilla documents (https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/splice) an extended form of splice:

array.splice(index, [howMany, [element1][, ..., elementN]]);  // SpiderMonkey extension

 

where [1,2,3].splice(1) essentially means [1,2,3].splice(1, [1,2,3].length)

 

Most other browsers also seem to support this extensions.  Was it an oversight that ES5 was not updated to include support for this extended behavior? 

 

Is there consensus that this is defacto standard behavior that is needed for interoperability among browsers and that it should be incorporated into Harmony?

 

Allen


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Single argument Array.prototype.splice

Brendan Eich-3
<base href="x-msg://5851/">
On Oct 27, 2010, at 10:37 AM, Allen Wirfs-Brock wrote:

ES3 and 5 specify Array.prototype.splice such that [1,2,3].splice(1) means the same thing as [1,2,3].splice(1,0)
 
array.splice(index, [howMany, [element1][, ..., elementN]]);  // SpiderMonkey extension
 
where [1,2,3].splice(1) essentially means [1,2,3].splice(1, [1,2,3].length)
 
Most other browsers also seem to support this extensions.  Was it an oversight that ES5 was not updated to include support for this extended behavior? 

An oversight from the ES3 era, carried forward into ES5 without review that I can recall.


 Is there consensus that this is defacto standard behavior that is needed for interoperability among browsers and that it should be incorporated into Harmony?

I suspect this is a de-facto standard we should codify in Harmony. Thanks for bringing it up.

/be


 
Allen
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Codifying de-facto standards

Geoffrey Sneddon-3
On 27/10/10 21:38, Brendan Eich wrote:
>>   Is there consensus that this is defacto standard behavior that is needed for interoperability among browsers and that it should be incorporated into Harmony?
>
> I suspect this is a de-facto standard we should codify in Harmony. Thanks for bringing it up.

How much of de-facto standards are going to be codified? What about
things which aren't entirely interoperability implemented, but the basic
premise is an absolute requirement for web compatibility (e.g., the
recent thread on function hoisting). What about things which are needed
for web compatibility, interoperability implemented, but disallowed in
ES5/Strict (e.g., Function.arguments, Function.caller, octal escapes
(which are defined differently to all impls as raised before ES5 was
finalized), etc.)?

I'd very much like to get to a point where you can implement something
web compatible from the spec, which would mean defining things some
don't like, and changing other definitions that people don't like
either… At the moment, it's impossible to implement a fully compliant
ES5 implementation without sacrificing web compatibility.

--
Geoffrey Sneddon — Opera Software
<http://gsnedders.com>
<http://opera.com>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Codifying de-facto standards

Mark S. Miller-2
On Sat, Nov 13, 2010 at 8:41 AM, Geoffrey Sneddon <[hidden email]> wrote:
On 27/10/10 21:38, Brendan Eich wrote:
 Is there consensus that this is defacto standard behavior that is needed for interoperability among browsers and that it should be incorporated into Harmony?

I suspect this is a de-facto standard we should codify in Harmony. Thanks for bringing it up.

How much of de-facto standards are going to be codified? What about things which aren't entirely interoperability implemented, but the basic premise is an absolute requirement for web compatibility (e.g., the recent thread on function hoisting). What about things which are needed for web compatibility, interoperability implemented, but disallowed in ES5/Strict (e.g., Function.arguments, Function.caller, octal escapes (which are defined differently to all impls as raised before ES5 was finalized), etc.)?

I'd very much like to get to a point where you can implement something web compatible from the spec, which would mean defining things some don't like, and changing other definitions that people don't like either… At the moment, it's impossible to implement a fully compliant ES5 implementation without sacrificing web compatibility.

That may be -- I do know of one example (parseInt), which IMO we should therefore add to the ES5 errata. But *none* of the examples you give are conflicts between ES5 and legacy web compat, since legacy web code doesn't say "use strict". Rather, your examples are ways in which ES5/non-strict is a compatible subset of de-facto cross browser JavaScript. As for codifying the rest of de-factp cross-browser JavaScript, that is the role of Appendix B of the ES5 spec. If Harmony includes a successor to appendix B for codying de fact ES5/non-strict behavior, I agree it might make sense to include Function.arguments, Function.caller, octal escapes, and the items at <http://code.google.com/p/es-lab/source/browse/trunk/src/ses/whitelist.js> that are marked "non-standard" or "whatwg".

Note that Harmony itself is a successor only to ES5/strict, so any such enhancements to the codification of ES5/non-strict should stay in an appendix.

 

--
Geoffrey Sneddon — Opera Software
<http://gsnedders.com>
<http://opera.com>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Codifying de-facto standards

Brendan Eich-3
In reply to this post by Geoffrey Sneddon-3
On Nov 13, 2010, at 8:41 AM, Geoffrey Sneddon wrote:

> On 27/10/10 21:38, Brendan Eich wrote:
>>>  Is there consensus that this is defacto standard behavior that is needed for interoperability among browsers and that it should be incorporated into Harmony?
>>
>> I suspect this is a de-facto standard we should codify in Harmony. Thanks for bringing it up.
>
> How much of de-facto standards are going to be codified? What about things which aren't entirely interoperability implemented, but the basic premise is an absolute requirement for web compatibility (e.g., the recent thread on function hoisting).

Allen explicitly addressed this in his reply on that thread:

> From the ES5 spec section 12 statement semantics:
>
> NOTE Several widely used implementations of ECMAScript are known to support the use of FunctionDeclaration as a Statement. However there are significant and irreconcilable variations among the implementations in the semantics applied to such FunctionDeclarations. Because of these irreconcilable differences , the use of a FunctionDeclaration as a Statement results in code that is not reliably portable among implementations. It is recommended that ECMAScript implementations either disallow this usage of FunctionDeclaration or issue a warning when such a usage is encountered. Future editions of ECMAScript may define alternative portable means for declaring functions in a Statement context.
>
> Also see section on functions in http://blogs.msdn.com/b/ie/archive/2010/08/25/chakra-interoperability-means-more-than-just-standards.aspx 
>
> There seem to be more browsers that treat function declarations in blocks as straightforward extensions of the function hoisting semantics (unconditionally) but Firefox does something different.
>
> As I say in the above blog post, you have to have them in a browser but anything other than trivial usage is unlike to be interoperable.
>
> Allen


When browsers do not implement the same (within epsilon) semantics for certain syntax put forth in a would-be de-facto standard, obviously browser-independent web content cannot count on more than the intersection semantics.

Ecma TC39 is not going to standardize union-semantics (browser X does A, browser Y does B, etc.).

This leaves us with room to draft, prototype-implement, user-test, and ultimately de-jure-standardize a better common semantics for the given syntax. That's the plan for functions in blocks, as noted several times on this list over the years. There's a placeholder on the wiki:

http://wiki.ecmascript.org/doku.php?id=harmony:block_functions

but the action is happening here:

http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings

Both are linked from

http://wiki.ecmascript.org/doku.php?id=harmony:proposals


> What about things which are needed for web compatibility, interoperability implemented, but disallowed in ES5/Strict (e.g., Function.arguments, Function.caller, octal escapes (which are defined differently to all impls as raised before ES5 was finalized), etc.)?

Those are more interoperably implemented, although perhaps not perfectly. No ECMA standard bothered to specify them -- a failing on the committee's part, or (some argue) a shunning that these monstrosities deserved, to help drive them away.

How'd that shunning work out? Not so well.

Nevertheless, we have no plans to standardize these in a future spec, and Harmony builds on ES5 strict which poisons the properties. This is not just "shun harder", in all cases. We're trying to add new and better forms to get people away from the bad old thing (rest params and default parameter values instead of arguments).

Octal we've covered on this list, most recently at:

https://mail.mozilla.org/pipermail/es5-discuss/2010-February/003502.html

where you started the thread ;-).

I think everyone who posted was neutral or positive on allowing "\0" for the NUL character in strings.

Allen replied here:

https://mail.mozilla.org/pipermail/es5-discuss/2010-February/003507.html

proposing an "approved extensions" list. We haven't built that yet, but it might be the way to handle the de-facto standards that have enough intersection semantics to be usable cross-browser.


> I'd very much like to get to a point where you can implement something web compatible from the spec, which would mean defining things some don't like, and changing other definitions that people don't like either… At the moment, it's impossible to implement a fully compliant ES5 implementation without sacrificing web compatibility.

You're right. For functions in blocks, we have a plan. For octal, some agreement to allow \0 but nothing more (shun harder, I think). For foo.arguments, shun and also add better replacements. For arguments.caller, shun.

This is not a great plan.

An "extensions list" covering what's needed for web compatibility would be helpful, whether it's part of an ECMA-262 spec or a companion spec or TR.

We have to draw the line carefully. For example, what about callable regexps? They are something Mozilla added long ago, WebKit JSC (and therefore V8) cloned, but not in IE or (AFAIK) Opera. typeof /hi/ == "object" not "function", in spite of the callability, and David-Sarah Hopwood pointed out that ES3 and ES5 do not allow [[Call]] to be defined on RegExp instances (their internal methods are fully specified).

We're trying to remove callable regexps, in coordination with JSC and V8 folks, so we do not want even a "extension list for non-IE or !document.all web content compatibility".

Let's start with the list that you've outlined:

- function declaration in block
- octal in general
  - \0 in strings
  - non-\0 in strings
- arguments.callee (ES5 strict mode error)
- arguments.caller (ES5 strict mode error)
- foo.caller given function foo (ES5 strict mode error)
- foo.arguments given function foo

Anything else?

Any testing data you or others have that demonstrates web usage of the more obscure of these would be great.

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Codifying de-facto standards

Brendan Eich-3
In reply to this post by Mark S. Miller-2
On Nov 13, 2010, at 9:09 AM, Mark S. Miller wrote:

As for codifying the rest of de-factp cross-browser JavaScript, that is the role of Appendix B of the ES5 spec. If Harmony includes a successor to appendix B for codying de fact ES5/non-strict behavior, I agree it might make sense to include Function.arguments, Function.caller, octal escapes, and the items at <http://code.google.com/p/es-lab/source/browse/trunk/src/ses/whitelist.js> that are marked "non-standard" or "whatwg".

Good point and link -- just to flatten links, here's the link from the es-lab wiki page to the whatwg wiki:



Note that Harmony itself is a successor only to ES5/strict, so any such enhancements to the codification of ES5/non-strict should stay in an appendix.

Thanks for the reminder about Annex B -- I had shunned it in my mind ;-).

Annex B is quite old. Are the Y2K-buggy getYear and setYear still required by the web? Hard to say, I hope not, but we can keep them in Annex B forever. This does seem like the place, rather than a separate TR as I thought, to document other de-facto standards.

/be


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Codifying de-facto standards

Brendan Eich-3
In reply to this post by Brendan Eich-3
On Nov 13, 2010, at 10:09 AM, Brendan Eich wrote:

> On Nov 13, 2010, at 8:41 AM, Geoffrey Sneddon wrote:
>
>> What about things which are needed for web compatibility, interoperability implemented, but disallowed in ES5/Strict (e.g., Function.arguments, Function.caller, octal escapes (which are defined differently to all impls as raised before ES5 was finalized), etc.)?
>
> Those are more interoperably implemented, although perhaps not perfectly. No ECMA standard bothered to specify them -- a failing on the committee's part, or (some argue) a shunning that these monstrosities deserved, to help drive them away.
>
> How'd that shunning work out? Not so well.
>
> Nevertheless, we have no plans to standardize these in a future spec, and Harmony builds on ES5 strict which poisons the properties. This is not just "shun harder", in all cases. We're trying to add new and better forms to get people away from the bad old thing (rest params and default parameter values instead of arguments).

There's no guarantee this will work, of course. No schedule assurances either. The old content using foo.arguments was likely written years ago and it is no longer maintained. There may be no one to maintain it, or no budget to find and pay someone to maintain it.

So we're not sure we can ever get rid of foo.arguments, but old forms do die off. JS has changed incompatibly since 1995, for example. Some presentational aspects (important ones) of table layout have changed. Old plugins do die. To view the web from 1995, you really do need an old browser and possibly a VM emulating or running an old OS. Sad but true, and since true, grounds for hope that better forms (which are justified anyway) will replace the bad old ones.


> We have to draw the line carefully. For example, what about callable regexps? They are something Mozilla added long ago, WebKit JSC (and therefore V8) cloned, but not in IE or (AFAIK) Opera.

Opera 10.61 does make regexps callable, I just tested.

But we do not want to standardize the "non-IE" or (!document.all) subset of web-compatible JS, and we're trying to get rid of callable regexps in a coordinated fashion with other implementors. I'll talk to you and Jens, along with the other browser JS implementors, in a separate email.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss