IE caching previous property positions for deleted properties

[John G Harris]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Sun, 29 Nov 2009 17:43:42, John G Harris


Correct. But not *as* the next edition.

I never claimed it was, as you would know if you understood English.

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 :-(

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".

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?


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

 

[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]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Tue, 1 Dec 2009 20:21:34, John G Harris

I never claimed it was, as you would know if you understood English.

A specification is invariably by default a formally-specified one; until
then it can only be a draft or proposal.

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?".

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]

In comp.lang.javascript message <e8143d7a-1ac7-4987-b76d-d6f4431176ef@j4
g2000yqe.googlegroups.com>, Mon, 30 Nov 2009 21:32:00, "Michael Haufe

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.

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),

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.

 

[Garrett Smith]

In comp.lang.javascript message <e8143d7a-1ac7-4987-b76d-d6f4431176ef@j4
g2000yqe.googlegroups.com>, Mon, 30 Nov 2009 21:32:00, "Michael Haufe

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]

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

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Wed, 2 Dec 2009 19:59:24, Garrett Smith

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

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.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Wed, 2 Dec 2009 23:37:25, Dr J R Stockton

In comp.lang.javascript message <e8143d7a-1ac7-4987-b76d-d6f4431176ef@j4
g2000yqe.googlegroups.com>, Mon, 30 Nov 2009 21:32:00, "Michael Haufe


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.