IE caching previous property positions for deleted properties
Brett
I'm working on a group of functions which aim to be able to sort a
supplied object. While I understand the ECMAScript spec does not
guarantee for...in iteration order, it does seem to have become a de
facto standard.
However, we encountered an issue in Explorer (and only Explorer) when
trying, within the function, to reassign the old properties with
different (i.e., sorted) values. Even when I explicitly delete all of
the properties on the object beforehand, when I reassign values to the
previously existing properties, the relative position of the keys is
remembered by Explorer (though not by Chrome, Opera, Safari, or
Firefox).
function reverseObj (obj) {
var keys = [], vals = [];
for (var p in obj) {
keys.push(p);
vals.push(obj[p]);
delete obj[p];
}
keys.reverse();
vals.reverse();
for (var i=0; i < keys.length; ++i) {
obj[keys[i]] = vals[i];
}
}
var assoc = {a: 'orange', b: 'banana', c: 'apple', d: 'lemon'};
reverseObj(assoc); // Does not reverse order in IE (and IE only)
Explorer, as with the other browsers, normally does add new properties
in sequence (at the end), but it breaks this pattern for those
properties which had previously existed on the object (it reassigns
them into the same relative position as before).
Does anyone know of any way to get Explorer to truly forget those
properties ever existed on the passed-in object so the relative
positions of the properties can be freely rearranged?
I wonder if this could even be a minor security issue: if a callback
were instead given to the object after the supposed deletion of
properties, the callback could guess at the properties that had
supposedly been deleted.
While it may be the case that ECMAScript just wasn't meant to be used
in this way, I'd still like for convenience to see if it can be made
to work.
thanks,
Brett
Brett
> ...if a callback were instead given to the object after the supposed deletion of
> properties, the callback could guess at the properties that had
> supposedly been deleted.
Sorry, I meant to say "...if a callback were instead given to the
function, passing it the same object reference after the supposed
deletion of properties..."
Brett
wilq
This is trully interesting. I manage to do what you want, but with a
return statement. However this strange behaviour is still there in IE.
Strange hmm... Funny thing is that if you do obj=newObj inside
function it does not change reference correctly, but if you do return
newObj, and then assing function value to a obj = reverseObj(obj) - it
changes this properly... Any explanation for that ?:)
function reverseObj (obj) {
var keys = [], vals = [],retObj={};
for (var p in obj) {
keys.push(p);
vals.push(obj[p]);
}
keys.reverse();
vals.reverse();
for (var i=0; i < keys.length; ++i) {
retObj[keys[i]] = vals[i];
}
obj=retObj;
return retObj;
}
var assoc = {a: 'orange', b: 'banana', c: 'apple', d: 'lemon'};
var assoc2 = {a: 'orange', b: 'banana', c: 'apple', d: 'lemon'};
assoc = reverseObj(assoc); // Does not reverse order in IE (and IE
only)
reverseObj(assoc2);
var a="",b="";
for (var c in assoc)
a+=c+" ";
for (var c in assoc2)
b+=c+" ";
alert(a);
alert(b);
Asen Bozhilov
> This is trully interesting. I manage to do what you want, but with a
> return statement. However this strange behaviour is still there in IE.
The order of enumeration is defined by `object', and is it
implementation depended.
> Strange hmm... Funny thing is that if you do obj=newObj inside
> function it does not change reference correctly, but if you do return
> newObj, and then assing function value to a obj = reverseObj(obj) - it
> changes this properly... Any explanation for that ?:)
Absolutely expected behavior. Property `obj' is a property of AO/VO
associated with execution context created when been calling
`reverseObj'. So when execution context finish, VO/AO of that
execution context will be marked for garbage collection, because
doesn't have any reference to AO/VO.
John G Harris
>Hi,
>
>I'm working on a group of functions which aim to be able to sort a
>supplied object. While I understand the ECMAScript spec does not
>guarantee for...in iteration order, it does seem to have become a de
>facto standard.
Javascript has something whose job is to hold values in a particular
order : Array objects. That's what array indexes do : they tell you what
order the values are in. These objects even have a built-in sort method
to save you having to write your own.
>However, we encountered an issue in Explorer (and only Explorer) when
>trying, within the function, to reassign the old properties with
>different (i.e., sorted) values. Even when I explicitly delete all of
>the properties on the object beforehand, when I reassign values to the
>previously existing properties, the relative position of the keys is
>remembered by Explorer (though not by Chrome, Opera, Safari, or
>Firefox).
<snip>
Well, both the ES3 and ES5 specifications say about for(... in ... )
that :
"The mechanics and order of enumerating the properties ... is not
specified."
so you can't be surprised if you get into trouble.
Making use of unspecified features of some browsers is irresponsible, as
a lot of web sites demonstrate now that IE8 is here.
John
--
John Harris
Thomas 'PointedEars' Lahn
> I'm working on a group of functions which aim to be able to sort a
> supplied object. While I understand the ECMAScript spec does not
> guarantee for...in iteration order, it does seem to have become a de
> facto standard.
You are mistaken. ECMAScript Ed. 3 does not only not guarantee a specific
order, it says explicitly that the order of for-in iteration is
implementation-dependent and that the order is defined by the object (*two*
uncertainties):
| 12.6.4 The for-in Statement
|
| [...]
| The mechanics of enumerating the properties (step 5 in the first
| algorithm, step 6 in the second) is implementation dependent. The
| order of enumeration is defined by the object. [...]
> However, we encountered an issue in Explorer (and only Explorer) when
There are dozens of versions of Internet Explorer; there is also Windows
Explorer (still with many versions), and several other products using the
Explorer name. Be specific in your descriptions (e.g., check the `Info'
item in the `?/Help' menu of Internet Explorer, type
'javascript:navigator.userAgent', and post both results).
> [...]
> Explorer, as with the other browsers, normally does add new properties
> in sequence (at the end), but it breaks this pattern for those
> properties which had previously existed on the object (it reassigns
> them into the same relative position as before).
That is what "implementation-dependent" means; the implementation you are
dealing with here being Microsoft JScript.
> Does anyone know of any way to get Explorer to truly forget those
> properties ever existed on the passed-in object so the relative
> positions of the properties can be freely rearranged?
Unlikely. Use an Array instance if you need an order.
| 4.3.3 Object
|
| An object is a member of the type Object. It is an unordered collection of
^^^^^^^^^^^^^^^^^^^^
| properties each of which contains a primitive value, object, or function.
| [...]
| 15.4 Array Objects
|
| Array objects give special treatment to a certain class of property names.
| A property name P (in the form of a string value) is an array index if and
| only if ToString(ToUint32(P)) is equal to P and ToUint32(P) is not equal
| to 2^32−1.
Non-order is also not the only problem with for-in iteration; it iterates
over *all* enumerable properties, including those inherited through the
prototype chain. Be aware of that and provide a filter where necessary
(there is nothing inherently wrong in augmenting prototype objects of built-
in objects as long as you provide a filter, are aware of the augmentation,
and for-in loop over these objects in a consistent way. You would probably
want to provide it for user-defined objects, too.)
[applied correction from
<news:ddef049e-51a2-4749...@u16g2000pru.googlegroups.com>]
> I wonder if this could even be a minor security issue: [if a callback were
> instead given to the function, passing it the same object reference after
> the supposed deletion of properties], the callback could guess at the
> properties that had supposedly been deleted.
I do not think the costs of finding out merit an exploit. Remember that
property names may be of arbitrary composition and length.
> While it may be the case that ECMAScript just wasn't meant to be used
> in this way, I'd still like for convenience to see if it can be made
> to work.
It was meant to be used this way.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
Brett
Specific replies to PointedEars below.
@wilq: Thanks for the workaround. Was trying to imitate an API which
worked solely by reference, but I guess I'll have to copy the object
as you suggest.
@John: I know that arrays in JavaScript are intended for this purpose,
but I find it convenient (and more intuitive) to be able to keep
ordered pairs of information tied together (as is possible in some
languages). Before HTML5, DOM Level 0 had not been formally specified
either, so I don't think it is necessarily irresponsible to rely on
non-standard features if they are effectively standard. But I see now
in this instance, that this is not the case.
> There are dozens of versions of Internet Explorer; there is also Windows
> Explorer (still with many versions), and several other products using the
> Explorer name. Be specific in your descriptions (e.g., check the `Info'
> item in the `?/Help' menu of Internet Explorer, type
> 'javascript:navigator.userAgent', and post both results).
Under Help->About (if that's what you mean--that's all I can see in my
Vista version), there is version 8.0.6001.18828IC
For userAgent, I have:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0;
SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR
3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30729; yie8)
> > Does anyone know of any way to get Explorer to truly forget those
> > properties ever existed on the passed-in object so the relative
> > positions of the properties can be freely rearranged?
>
> Unlikely. Use an Array instance if you need an order.
Yeah, thanks. I see IE has a CollectGarbage() method, but from what I
can tell, that only apparently works with whole objects whose
references have all been removed (and of course, it is not a standard
function).
Thanks again...
Jim Ley
wrote:
>@John: I know that arrays in JavaScript are intended for this purpose,
>but I find it convenient (and more intuitive) to be able to keep
>ordered pairs of information tied together (as is possible in some
>languages).
obj=new Array();
// Add pairs with:
obj.push({"name":value});
obj["name"]=value;
Then so long as none of your names are numeric - if they are, or could
be simply prefix the key one with an underscore or similar always -
you get the ability to iterate over an ordered list with regular array
syntax, and access by name.
Jim.
Thomas 'PointedEars' Lahn
> ["@John:" etc.]
Please don't. See my e-mail for details.
> I know that arrays in JavaScript are intended for this purpose,
> but I find it convenient (and more intuitive) to be able to keep
> ordered pairs of information tied together (as is possible in some
> languages).
You can also have that with ECMAScript implementations, for example:
var a = [
{foo: "bar"},
{baz: 42}
];
The tradeoff is slower access to the information, but that can be mitigated
by using a hash function.
> Before HTML5, DOM Level 0 had not been formally specified
> either, so I don't think it is necessarily irresponsible to rely on
> non-standard features if they are effectively standard.
In my experience, to perceive something that is not a standard as
"effectively standard" is often indicative of superficial testing.
> But I see now in this instance, that this is not the case.
It seldom is.
>> There are dozens of versions of Internet Explorer; there is also Windows
>> Explorer (still with many versions), and several other products using the
>> Explorer name. Be specific in your descriptions (e.g., check the `Info'
>> item in the `?/Help' menu of Internet Explorer, type
>> 'javascript:navigator.userAgent', and post both results).
>
> Under Help->About (if that's what you mean--
Yes, labels vary.
> that's all I can see in my Vista version), there is version
> 8.0.6001.18828IC
>
> For userAgent, I have:
>
> Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0;
> SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR
> 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30729; yie8)
Thanks. Apparently it is an IE 8.0 for Windows Vista on a Windows Media
Center PC, optimized for Yahoo!, working in Standards Mode (as indicated by
the "MSIE 8.0"). It would be interesting to know if other versions of IE 8,
or IE 8 in Compatibility Mode ("MSIE 7.0") showed the same symptoms.
>> > Does anyone know of any way to get Explorer to truly forget those
>> > properties ever existed on the passed-in object so the relative
>> > positions of the properties can be freely rearranged?
>>
>> Unlikely. Use an Array instance if you need an order.
>
> Yeah, thanks. I see IE has a CollectGarbage() method, but from what I
> can tell, that only apparently works with whole objects whose
> references have all been removed
Yes, garbage collection has nothing to do with this. It is the fact that
the object that had the properties still exists that causes this behavior.
> (and of course, it is not a standard function).
ACK
> Thanks again...
You are welcome.
Thomas 'PointedEars' Lahn
> Brett wrote:
>> @John: I know that arrays in JavaScript are intended for this purpose,
>> but I find it convenient (and more intuitive) to be able to keep
>> ordered pairs of information tied together (as is possible in some
>> languages).
>
> obj=new Array();
Should be
var obj = new Array();
or (equally compatible these days¹)
var obj = [];
> // Add pairs with:
>
> obj.push({"name":value});
In this example, the less compatible Array.prototype.push() call¹ is
unnecessary:
var obj = new Array(
{"name": value}
);
or
var obj = [
{"name": value}
];
> obj["name"]=value;
>
> Then so long as none of your names are numeric - if they are, or could
> be simply prefix the key one with an underscore or similar always -
> you get the ability to iterate over an ordered list with regular array
> syntax, and access by name.
Built-in non-numeric properties also need to be taken care of as they would
be overwritten otherwise. But the general disadvantage of that approach is
that the value needs to be duplicated which allows for inconsistencies. It
would be better if the non-numeric property referred to the user data; here:
obj["name"] = obj[0];
In general:
obj = {
_data: [],
add: function(name, value) {
var o = {};
o[name] = value;
_data.push(o);
o = null;
_data[name] = data[data.length - 1];
},
get: function(name) {
return _data[name];
}
};
Then:
obj.add("name", value);
/* value */
obj.get("name");
Incidentally, that is basically what collection implementations (e.g., mine)
do.
P.S.: Nice to read you again :)
PointedEars
___________
¹ See the ECMAScript Support Matrix: <http://PointedEars.de/es-matrix>
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Thomas 'PointedEars' Lahn
> In general:
>
> obj = {
> _data: [],
>
> add: function(name, value) {
> var o = {};
> o[name] = value;
var _data = this._data;
> _data.push(o);
> o = null;
> _data[name] = data[data.length - 1];
_data[name] = _data[_data.length - 1];
> },
>
> get: function(name) {
> return _data[name];
> }
> };
PointedEars
Jim Ley
<Point...@web.de> wrote:
>In this example, the less compatible Array.prototype.push() call¹ is
>unnecessary:
Only if you assume the code was whole, rather than just an example of
how to add to such an object. You're right of course though.
> It
>would be better if the non-numeric property referred to the user data; here:
>
> obj["name"] = obj[0];
Probably, depends what you mean by better, since later accessing of
the value would take an extra resolution. But that is what I'd really
do. Not sure why I didn't write it. being out of touch I guess :)
>In general:
>
> obj = {
> _data: [],
>
> add: function(name, value) {
> var o = {};
> o[name] = value;
> _data.push(o);
> o = null;
_data["_"+name] = data[data.length - 1];
> },
>
> get: function(name) {
return _data["_"+name]
> }
> };
Wouldn't that change above be better, to prevent anyone from creating
length / numbered properties by accident?
Jim.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
> > It would be better if the non-numeric property referred to the user
> > data; here:
> >
> > obj["name"] = obj[0];
>
> Probably, depends what you mean by better, since later accessing of
> the value would take an extra resolution. But that is what I'd really
> do. Not sure why I didn't write it. being out of touch I guess :)
Happens to the best of us :)
[Implemented corrections from <news:6828034.h...@PointedEars.de>]
>>In general:
>>
>> obj = {
>> _data: [],
>>
>> add: function(name, value) {
>> var o = {};
>> o[name] = value;
>> var _data = this._data;
>> _data.push(o);
>> o = null;
> _data["_" + name] = _data[_data.length - 1];
>> },
>>
>> get: function(name) {
> return this._data["_" + name];
>> }
>> };
>
> Wouldn't that change above be better, to prevent anyone from creating
> length / numbered properties by accident?
The change assumes a numeric value that losslessly converts to an unsigned
32-bit integer value was passed by accident. I would rather not make that
assumption, in order to allow people to set values for specific indexes
(much like the bracket property accessor with collection implementation).
In addition, simply prefixing with `_' has greater a chance to access built-
in properties in a harmful way if the property name is not numeric.
The Ultimate Solution[tm] would probably involve a flag to be set to
determine whether or not numeric names are allowed, and an approach that
tries hard to avoid overwriting built-in properties (see my Map
implementation for the latter.)
Dr J R Stockton
8924D9443D28E23ED5CD>, Fri, 27 Nov 2009 20:22:00, John G Harris
<jo...@nospam.demon.co.uk> posted:
>Well, both the ES3 and ES5 specifications
Does the actual *ratified* ES5 specification yet exist? Until it does,
one should not purport to cite it.
ISTM that ECMA does not understand, or at least write, English as well
as it should. I now have TWO final drafts of ECMA 5, dated April and
September. That cannot be correct : and what if the General Assembly
says "quite good, but needs some changes - produce another draft."
<http://www.ecma-international.org/publications/standards/Standard.htm>
currently offers ECMA 263-3 Dec 1999. They do not there offer ECMA
262-3 Mar 2000.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
John G Harris
Stockton wrote:
>In comp.lang.javascript message <uHOgLfKo...@J.A830F0FF37FB96852AD0
>8924D9443D28E23ED5CD>, Fri, 27 Nov 2009 20:22:00, John G Harris
><jo...@nospam.demon.co.uk> posted:
>
>>Well, both the ES3 and ES5 specifications
>
>Does the actual *ratified* ES5 specification yet exist?
Obviously I was referring to the current releases of these two
documents. In case anyone doesn't know, ES5 is currently
"Final Draft 5th Edition / September 2009",
obtainable at
<http://www.ecmascript.org/docs/tc39-2009-043.pdf>.
(It seems the ECMA site has lost its copy.)
>Until it does,
>one should not purport to cite it.
There are occasions when it's right to refer to the current draft of the
next edition. One is when you need to point out that some feature being
complained about is likely to change in the next edition, or not change,
as the case may be.
This is the case here. In ES3 the enumeration order of properties in
for-in is arbitrary. The ES4 Outline says that the enumeration order is
likely to be defined, on the grounds that it is defined in some popular
browsers. Then the ES5 Final Draft says it's likely to remain arbitrary.
It looks as though Microsoft realised they couldn't change it.
>ISTM that ECMA does not understand, or at least write, English as well
>as it should. I now have TWO final drafts of ECMA 5, dated April and
>September. That cannot be correct :
I doubt if the problem is understanding or writing English. I've seen
people in a thoroughly English organisation publish a replacement draft
with no issue or date on it. They just assumed that people would
immediately throw the previous draft away. At least ECMA put an
identifying date on it. Calling the earlier one Final can't be helped if
no-one expected changes at the time it was promulgated.
>and what if the General Assembly
>says "quite good, but needs some changes - produce another draft."
According to Crockford some ECMA members might ask the Ecma General
Assembly to reject the ES5 Draft in its current form.
><http://www.ecma-international.org/publications/standards/Standard.htm>
>currently offers ECMA 263-3 Dec 1999. They do not there offer ECMA
>262-3 Mar 2000.
The ECMA web site's List of standards doesn't mention a Mar 2000
version. Where did you find it ?
John
--
John Harris
Brett
> Brett wrote:
> > that's all I can see in my Vista version), there is version
> > 8.0.6001.18828IC
> >
> > For userAgent, I have:
> >
> > Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0;
> > SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR
> > 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30729; yie8)
>
> Thanks. Apparently it is an IE 8.0 for Windows Vista on a Windows Media
> Center PC, optimized for Yahoo!, working in Standards Mode (as indicated by
> the "MSIE 8.0"). It would be interesting to know if other versions of IE 8,
> or IE 8 in Compatibility Mode ("MSIE 7.0") showed the same symptoms.
In compatibility mode in IE 8 (and confirming that the option did also
cause the user agent to show as MSIE 7.0), I do get the same behavior.
Brett
Thanks. Good to have a workaround even if it is a bit cumbersome.
I imagine one could also allow numeric properties by requiring key
access to be done in a specific way maybe like:
obj.push({"name":value});
obj._ = {};
obj._["name"]=value;
Dr J R Stockton
8924D9443D28E23ED5CD>, Sun, 29 Nov 2009 17:43:42, John G Harris
<jo...@nospam.demon.co.uk> posted:
>On Sat, 28 Nov 2009 at 17:22:04, in comp.lang.javascript, Dr J R
>Stockton wrote:
>>In comp.lang.javascript message <uHOgLfKo...@J.A830F0FF37FB96852AD0
>>8924D9443D28E23ED5CD>, Fri, 27 Nov 2009 20:22:00, John G Harris
>><jo...@nospam.demon.co.uk> posted:
>>
>>>Well, both the ES3 and ES5 specifications
>>
>>Does the actual *ratified* ES5 specification yet exist?
>
>Obviously I was referring to the current releases of these two
>documents. In case anyone doesn't know, ES5 is currently
> "Final Draft 5th Edition / September 2009",
>obtainable at
> <http://www.ecmascript.org/docs/tc39-2009-043.pdf>.
>(It seems the ECMA site has lost its copy.)
>
>
>>Until it does,
>>one should not purport to cite it.
>
>There are occasions when it's right to refer to the current draft of the
>next edition.
Correct. But not *as* the next edition.
>>ISTM that ECMA does not understand, or at least write, English as well
>>as it should. I now have TWO final drafts of ECMA 5, dated April and
>>September. That cannot be correct :
>
>I doubt if the problem is understanding or writing English. I've seen
>people in a thoroughly English organisation publish a replacement draft
>with no issue or date on it. They just assumed that people would
>immediately throw the previous draft away.
That's mere stupidity. Any formal published draft or document should be
fully identifiable.
> At least ECMA put an
>identifying date on it. Calling the earlier one Final can't be helped if
>no-one expected changes at the time it was promulgated.
No. A draft can only sensibly be annotated as a final draft when the
document of which it is a draft is formally accepted, ratified,
released, or whatever. Before that, it can only be a dated release
candidate.
>>and what if the General Assembly
>>says "quite good, but needs some changes - produce another draft."
>
>According to Crockford some ECMA members might ask the Ecma General
>Assembly to reject the ES5 Draft in its current form.
Nicely illustrating my point. I'd like to see canvas routines in it.
ASIDE: Has anyone got dashed-line code for canvas?
>><http://www.ecma-international.org/publications/standards/Standard.htm>
>>currently offers ECMA 263-3 Dec 1999. They do not there offer ECMA
>>262-3 Mar 2000.
>
>The ECMA web site's List of standards doesn't mention a Mar 2000
>version. Where did you find it ?
I don't know. But I can say where a copy is. The link in my <js-
index.htm> leads directly to <http://www.mozilla.org/js/language/E262-3.
pdf> (1,217,793 bytes). The FAQ links to <http://www.ecma-international
.org/publications/files/ECMA-ST/ECMA-262.pdf> (720,951 bytes).
The FAQ version, unlike the later one, lacks a section numbered 15.9.1.7
and has two numbered 15.9.1.9.
Does anyone have a PDF text comparer? Although the texts are similar
(perhaps Mozilla includes 0.5MB of font?), they clearly cannot be
presumed identical.
There is also <http://www.mozilla.org/js/language/E262-3-errata.html>
(dated Monday, June 9, 2003; says Last modified Tuesday, January 15,
2008); but it sayeth not which ECMAScript Edition 3 it is Errata for.
Michael Haufe ("TNO")
wrote:
> That's mere stupidity. Any formal published draft or document should be
> fully identifiable.
...
> Does anyone have a PDF text comparer? Although the texts are similar
> (perhaps Mozilla includes 0.5MB of font?), they clearly cannot be
> presumed identical.
In regards to the ES specification comments, the current document
pending
ratification is available below along with older versions with change
history:
http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft
In December the vote of yes or no will occur. I believe the primary
antagonist to this specification is IBM due to the lack of decimal
support
in this version. The probability is in favor of this passing though I
think.
Even if it does not, browser vendors are already implementing it. In
FireFox
and Rhino for example, it will be implemented as part of JavaScript
1.9.
Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=429508
> Nicely illustrating my point. I'd like to see canvas routines in it.
Any DOM related manipulation doesn't belong in that particular
standard. On that
note though, there is talk if adding a ByteArray object which could
vastly improve
performance. Reference:
http://wiki.ecmascript.org/doku.php?id=strawman:strawman
https://bugzilla.mozilla.org/show_bug.cgi?id=497795
> ASIDE: Has anyone got dashed-line code for canvas?
I just wrote one for you here as an example:
http://thenewobjective.com/temp/dashLine.html
No doubt it could be improved, but it was a bit off the cuff and my
high school math is rusty.
Bwig Zomberi
> 8924D9443D28E23ED5CD>, Fri, 27 Nov 2009 20:22:00, John G Harris
> <jo...@nospam.demon.co.uk> posted:
>
>> Well, both the ES3 and ES5 specifications
>
> one should not _purport_to_ cite it.
>
Does the purported *ratified* ES5 specification yet exist? Until it
does, one should not actually cite it
--
Bwig Zomberi
John G Harris
Stockton wrote:
>In comp.lang.javascript message <rzCWZVGO...@J.A830F0FF37FB96852AD0
>8924D9443D28E23ED5CD>, Sun, 29 Nov 2009 17:43:42, John G Harris
><jo...@nospam.demon.co.uk> posted:
>>On Sat, 28 Nov 2009 at 17:22:04, in comp.lang.javascript, Dr J R
>>Stockton wrote:
>>>In comp.lang.javascript message <uHOgLfKo...@J.A830F0FF37FB96852AD0
>>>8924D9443D28E23ED5CD>, Fri, 27 Nov 2009 20:22:00, John G Harris
>>><jo...@nospam.demon.co.uk> posted:
>>>
>>>>Well, both the ES3 and ES5 specifications
>>>
>>>Does the actual *ratified* ES5 specification yet exist?
>>
>>Obviously I was referring to the current releases of these two
>>documents. In case anyone doesn't know, ES5 is currently
>> "Final Draft 5th Edition / September 2009",
>>obtainable at
>> <http://www.ecmascript.org/docs/tc39-2009-043.pdf>.
>>(It seems the ECMA site has lost its copy.)
>>
>>
>>>Until it does,
>>>one should not purport to cite it.
>>
>>There are occasions when it's right to refer to the current draft of the
>>next edition.
>
>Correct. But not *as* the next edition.
I never claimed it was, as you would know if you understood English.
>>>ISTM that ECMA does not understand, or at least write, English as well
>>>as it should. I now have TWO final drafts of ECMA 5, dated April and
>>>September. That cannot be correct :
>>
>>I doubt if the problem is understanding or writing English. I've seen
>>people in a thoroughly English organisation publish a replacement draft
>>with no issue or date on it. They just assumed that people would
>>immediately throw the previous draft away.
>
>That's mere stupidity. Any formal published draft or document should be
>fully identifiable.
That's what I said back then. The response was mutter, mutter, grump :-(
>> At least ECMA put an
>>identifying date on it. Calling the earlier one Final can't be helped if
>>no-one expected changes at the time it was promulgated.
>
>No. A draft can only sensibly be annotated as a final draft when the
>document of which it is a draft is formally accepted, ratified,
>released, or whatever. Before that, it can only be a dated release
>candidate.
Can you assure us that the ECMA Assembly is allowed to vote on a
document that is not flagged as Final. That's what you are implying.
They may have a defined process that says that "Final" means "this point
in the production of a Standard".
>>>and what if the General Assembly
>>>says "quite good, but needs some changes - produce another draft."
>>
>>According to Crockford some ECMA members might ask the Ecma General
>>Assembly to reject the ES5 Draft in its current form.
>
>Nicely illustrating my point.
Not really. "needs some changes" is less drastic than a total rejection.
>I'd like to see canvas routines in it.
>
> ASIDE: Has anyone got dashed-line code for canvas?
>
>>><http://www.ecma-international.org/publications/standards/Standard.htm>
>>>currently offers ECMA 263-3 Dec 1999. They do not there offer ECMA
>>>262-3 Mar 2000.
>>
>>The ECMA web site's List of standards doesn't mention a Mar 2000
>>version. Where did you find it ?
>
>I don't know. But I can say where a copy is. The link in my <js-
>index.htm> leads directly to <http://www.mozilla.org/js/language/E262-3.
>pdf> (1,217,793 bytes).
The Brief History section ends with the names of contributors, which is
something ECMA Standards don't do. At the top of the document it says
Edition 3 Final which is something ECMA Standards don't say.
We have to conclude that this is an informal version of ECMA 262,
modified by person or persons unknown.
>The FAQ links to <http://www.ecma-international
>.org/publications/files/ECMA-ST/ECMA-262.pdf> (720,951 bytes).
And <https://developer.mozilla.org/en/JavaScript_Language_Resources>
says December 1999, so it agrees with our FAQ.
>The FAQ version, unlike the later one, lacks a section numbered 15.9.1.7
>and has two numbered 15.9.1.9.
>Does anyone have a PDF text comparer? Although the texts are similar
>(perhaps Mozilla includes 0.5MB of font?), they clearly cannot be
>presumed identical.
>There is also <http://www.mozilla.org/js/language/E262-3-errata.html>
>(dated Monday, June 9, 2003; says Last modified Tuesday, January 15,
>2008); but it sayeth not which ECMAScript Edition 3 it is Errata for.
Nor does it say if it has any backing from the ECMAScript working party.
John
--
John Harris
NickFitz
>
> I'm working on a group of functions which aim to be able to sort a
> supplied object. While I understand the ECMAScript spec does not
> guarantee for...in iteration order, it does seem to have become a de
> facto standard.
The important word is "seem". As you have discovered, a little
investigation will reveal that implementation-dependent behaviour can
have unexpected aspects. For example, consider the following, taken
from "JScript Deviations from ES3" by Pratap Lakshman of Microsoft,
available as a 580KB PDF through a link at <http://wiki.ecmascript.org/
doku.php?id=resources:resources>:
"The ES3 spec leaves the mechanics of enumerating the properties as
implementation dependent. In IE, we enumerate the properties as
follows:
* Enumerate properties on immediate prototype in reverse order (w.r.t
the order in which they were added)
* Enumerate properties in-order on rest of the objects on the
prototype chain
* Enumerate properties in-order on present object."
So if your function ever received an object which has properties on
its prototype chain, you're likely to get some _really_ confusing
results.
Regards,
Nick.
Dr J R Stockton
8924D9443D28E23ED5CD>, Tue, 1 Dec 2009 20:21:34, John G Harris
A specification is invariably by default a formally-specified one; until
then it can only be a draft or proposal.
>>No. A draft can only sensibly be annotated as a final draft when the
>>document of which it is a draft is formally accepted, ratified,
>>released, or whatever. Before that, it can only be a dated release
>>candidate.
>
>Can you assure us that the ECMA Assembly is allowed to vote on a
>document that is not flagged as Final. That's what you are implying.
>They may have a defined process that says that "Final" means "this point
>in the production of a Standard".
I cannot. But ECMA are surely responsible for their own rules, and
should ensure that none are silly. The only proper non-retrospective
naming of a document as "final draft" would be where it is certain that
the decision will be of final acceptance or final rejection.
It is a foolish executioner who asks "Is that your last word?".
>>>According to Crockford some ECMA members might ask the Ecma General
>>>Assembly to reject the ES5 Draft in its current form.
>>
>>Nicely illustrating my point.
>
>Not really. "needs some changes" is less drastic than a total rejection.
Yes, because if the current version is rejected there will be one or
more future drafts. If those members were to ask for it to be accepted
with certain specified changes, that would be another matter.
>We have to conclude that this is an informal version of ECMA 262,
>modified by person or persons unknown.
OK. It's worth knowing about the two versions and the Errata, if only
in that if one has trouble believing the Dec 1999 version one can see if
the others differ.
Dr J R Stockton
g2000yqe.googlegroups.com>, Mon, 30 Nov 2009 21:32:00, "Michael Haufe
(\"TNO\")" <t...@thenewobjective.com> posted:
>On Nov 30, 11:21 am, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
>wrote:
>
>> That's mere stupidity. Any formal published draft or document should be
>> fully identifiable.
>...
>> Does anyone have a PDF text comparer? Although the texts are similar
>> (perhaps Mozilla includes 0.5MB of font?), they clearly cannot be
>> presumed identical.
>
>In regards to the ES specification comments, the current document
>pending
>ratification is available below along with older versions with change
>history:
>http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft
Thanks, noted. <FAQENTRY> That link should be in the FAQ. While it's
probably too early for authors to assume that all of any Final Draft 5
will be yet implemented in a sufficient proportion of browsers that
actual end users are using, it would certainly be wise to code in that
subset of ECMA Three which is still approved of in Drafts Five - and not
to hope that it is 100% of Three.
>> Nicely illustrating my point. I'd like to see canvas routines in it.
>
>Any DOM related manipulation doesn't belong in that particular
>standard.
Conceded. OTOH ISTM that it would be well if a non-normative part of a
Standard document such as ECMA 5 were to mention other Standards that
users might commonly wish to know of. I only came across "canvas" by
chance (and cannot recollect where),
>> ASIDE: Has anyone got dashed-line code for canvas?
>
>I just wrote one for you here as an example:
>http://thenewobjective.com/temp/dashLine.html
>
>No doubt it could be improved, but it was a bit off the cuff and my
>high school math is rusty.
Interesting. But ISTM that one does not need the trig functions - one
can probably use something like Bresenham's algorithm adapted to omit
some pixels in accordance with the pattern. My actual present need is
to draw dashed segments approximating to a smooth curve - a 7-day
running average - so it will be necessary to start each section at the
phase at which the previous ended.
Your code looks nothing like what I had in mind at first sight - and a
lot closer on careful inspection.
But canvas needs a dash-pattern stroke style for all lines, including
tot its curves.
Thanks.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
Garrett Smith
> g2000yqe.googlegroups.com>, Mon, 30 Nov 2009 21:32:00, "Michael Haufe
> (\"TNO\")" <t...@thenewobjective.com> posted:
>> On Nov 30, 11:21 am, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
>> wrote:
>>
>>> That's mere stupidity. Any formal published draft or document should be
>>> fully identifiable.
>> ...
>>> Does anyone have a PDF text comparer? Although the texts are similar
>>> (perhaps Mozilla includes 0.5MB of font?), they clearly cannot be
>>> presumed identical.
>> In regards to the ES specification comments, the current document
>> pending
>> ratification is available below along with older versions with change
>> history:
>> http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft
That is not a very official looking URL. I'm afraid it could change.
>
> Thanks, noted. <FAQENTRY> That link should be in the FAQ.
The FAQ links to ecmascript.org. From there, the draft is easily found.
This seems safer than relying on their wiki pages not changing.
[snip]
>
>
>>> Nicely illustrating my point. I'd like to see canvas routines in it.
>> Any DOM related manipulation doesn't belong in that particular
>> standard.
>
> Conceded. OTOH ISTM that it would be well if a non-normative part of a
> Standard document such as ECMA 5 were to mention other Standards that
> users might commonly wish to know of. I only came across "canvas" by
> chance (and cannot recollect where),
>
Canvas has nothing to do with ECMAScript programming language. Canvas
would what ECMAScript considers a host object.
http://jibbering.com/faq/#ecma
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
Dr J R Stockton
september.org>, Wed, 2 Dec 2009 19:59:24, Garrett Smith
<dhtmlk...@gmail.com> posted:
>Dr J R Stockton wrote:
>> In comp.lang.javascript message <e8143d7a-1ac7-4987-b76d-d6f4431176ef@j4
>> g2000yqe.googlegroups.com>, Mon, 30 Nov 2009 21:32:00, "Michael Haufe
>> (\"TNO\")" <t...@thenewobjective.com> posted:
>>> On Nov 30, 11:21 am, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
>>> wrote:
>>>
>>>> That's mere stupidity. Any formal published draft or document should be
>>>> fully identifiable.
>>> ...
>>>> Does anyone have a PDF text comparer? Although the texts are similar
>>>> (perhaps Mozilla includes 0.5MB of font?), they clearly cannot be
>>>> presumed identical.
>>> In regards to the ES specification comments, the current document
>>> pending
>>> ratification is available below along with older versions with change
>>> history:
>>> http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft
>
>That is not a very official looking URL. I'm afraid it could change.
ISTM clear that it will not change while that working draft exists; and
likely that if it does they'll add a redirector - as in <URL:http://www
.merlyn.demon.co.uk/gravity.htm>. Your regular links checks using
<http://www.elsop.com/quick/quick.cgi> or similar will detect removal.
>> Thanks, noted. <FAQENTRY> That link should be in the FAQ.
>
>The FAQ links to ecmascript.org. From there, the draft is easily found.
For those that know that it exists, as a wiki. A link in a FAQ provides
not only a route but also an announcement.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 7.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
I find MiniTrue useful for viewing/searching/altering files, at a DOS prompt;
free, DOS/Win/UNIX, <URL:http://www.idiotsdelight.net/minitrue/> unsupported.
Dr J R Stockton
rlyn.invalid>, Wed, 2 Dec 2009 23:37:25, Dr J R Stockton
<repl...@merlyn.demon.co.uk> posted:
>In comp.lang.javascript message <e8143d7a-1ac7-4987-b76d-d6f4431176ef@j4
>g2000yqe.googlegroups.com>, Mon, 30 Nov 2009 21:32:00, "Michael Haufe
>(\"TNO\")" <t...@thenewobjective.com> posted:
>>On Nov 30, 11:21 am, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
>>wrote:
>>> ...
>>> ASIDE: Has anyone got dashed-line code for canvas?
>>
>>I just wrote one for you here as an example:
>>http://thenewobjective.com/temp/dashLine.html
>>
>>No doubt it could be improved, but it was a bit off the cuff and my
>>high school math is rusty.
>
>Interesting. But ISTM that one does not need the trig functions - one
>can probably use something like Bresenham's algorithm adapted to omit
>some pixels in accordance with the pattern. My actual present need is
>to draw dashed segments approximating to a smooth curve - a 7-day
>running average - so it will be necessary to start each section at the
>phase at which the previous ended.
FYI - page <URL:http://www.merlyn.demon.co.uk/sitedata.htm> now includes
such a routine - function Dashes(X2, Y2, Ptrn) - (with moveTo LineTo,
not Bresenham), but without using trig functions. It's dotting &
dashing is weak, but the lines themselves are in the right places.
And function DashTo(X2, Y2, Ptrn) is better; it translates to the
beginning of a segment, rotates to get the X-axis along the line, and
dots & dashes X-wards. That simplifies the dotting & dashing.
The page includes demonstration data.
>But canvas needs a dash-pattern stroke style for all lines, including
>tot its curves.
???
Routine canvas.rotate takes an angle for its argument. ISTM that, in
adjusting the current transformation matrix, it will need sine and
cosine of that angle. Commonly, the angle will have been determined
outside the routine with Math.atan2(y, x). Therefore, ISTM that it
would be nice to allow two arguments, x & y or /vice versa/, to describe
a rotation, which could well make internal use of trig functions
unnecessary.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7)
Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)