Return statement and whitespace
Gabriel Gilini
that, at least in Firefox 3.0.4, the whitespace(s) between the return
statement and the expression that succeeds it is optional.
Meaning that -
function foo(){
return'bar';
}
foo();
- is a valid JavaScript program.
I looked at the specifications (The return Statement - session 12.9)
and couldn't find anything specific on this subject.
So, is this true for every other modern browser? And if yes, it's kind
of a quirk, isn't it?
[1] http://www.xorax.info/labs/jsxs/
Regards
--
Gabriel Gilini
kangax
> I've just realized, looking at this "JavaScript compressor"[1] output,
> that, at least in Firefox 3.0.4, the whitespace(s) between the return
> statement and the expression that succeeds it is optional.
>
> Meaning that -
>
> function foo(){
> return'bar';
> }
> foo();
>
> - is a valid JavaScript program.
>
> I looked at the specifications (The return Statement - session 12.9)
> and couldn't find anything specific on this subject.
"The return Statement" doesn't say anything about required whitespace;
It only disallows /LineTerminator/ in between `return` keyword and
following expression.
From what I can see, a whitespace can be omited from return statement
as long as overall production is unambiguous.
For example, look at `return1` and `return'foo'`. Former production
becomes a plain identifier (`return1`) and would result in
ReferenceError (unless `return1` is declared before), while latter one
can be unambiguously parsed as return keyword, followed by string
literal. I think the latter one is parsed due to "'" character (that's
immediately after "return") not being able to be part of a keyword or
identifier.
Other examples of unambiguous productions with no whitespace are:
return(1);
return/**/1;
return/1/;
return.1;
return-1;
return+1;
var x = 2;
(function(){ return--x; })(); // 1
(function(){ return++x; })(); // 3
I probably missed something else.
>
> So, is this true for every other modern browser? And if yes, it's kind
> of a quirk, isn't it?
I don't think it's a quirk, but I'm not completely sure myself about the
rules for these productions.
--
kangax
Gabriel Gilini
> Gabriel Gilini wrote:
> > I've just realized, looking at this "JavaScript compressor"[1] output,
> > that, at least in Firefox 3.0.4, the whitespace(s) between the return
> > statement and the expression that succeeds it is optional.
>
> > Meaning that -
>
> > function foo(){
> > return'bar';
> > }
> > foo();
>
> > - is a valid JavaScript program.
>
> > I looked at the specifications (The return Statement - session 12.9)
> > and couldn't find anything specific on this subject.
>
> "The return Statement" doesn't say anything about required whitespace;
> It only disallows /LineTerminator/ in between `return` keyword and
> following expression.
QED
> From what I can see, a whitespace can be omited from return statement
> as long as overall production is unambiguous.
>
> For example, look at `return1` and `return'foo'`. Former production
> becomes a plain identifier (`return1`) and would result in
> ReferenceError (unless `return1` is declared before), while latter one
> can be unambiguously parsed as return keyword, followed by string
> literal. I think the latter one is parsed due to "'" character (that's
> immediately after "return") not being able to be part of a keyword or
> identifier.
So, as I see, anything that is not part of an identifier or keyword
could be 'trimmed' by a compressor to save some bytes.
> Other examples of unambiguous productions with no whitespace are:
>
> return(1);
> return/**/1;
> return/1/;
> return.1;
> return-1;
> return+1;
>
> var x = 2;
> (function(){ return--x; })(); // 1
> (function(){ return++x; })(); // 3
>
> I probably missed something else.
Irrelevant, you made your point.
> > So, is this true for every other modern browser? And if yes, it's kind
> > of a quirk, isn't it?
>
> I don't think it's a quirk, but I'm not completely sure myself about the
> rules for these productions.
Sure, because they aren't really defined.
Personally, I'd rather not trust anything as dubious as this.
--
Gabriel Gilini
Gabriel Gilini
> > For example, look at `return1` and `return'foo'`. Former production
> > becomes a plain identifier (`return1`) and would result in
> > ReferenceError (unless `return1` is declared before), while latter one
> > can be unambiguously parsed as return keyword, followed by string
> > literal. I think the latter one is parsed due to "'" character (that's
> > immediately after "return") not being able to be part of a keyword or
> > identifier.
>
> So, as I see, anything that is not part of an identifier or keyword
> could be 'trimmed' by a compressor to save some bytes.
I probably wasn't as clear as I wanted, so let me rephrase that.
It looks like that anything that comes right after a return Statement
(an Expression) can be trimmed, as long as it doesn't start with an
identifier-valid character. Although, as I said earlier, I'd rather
not trust it, as it's not explicitly mentioned in the specification.
--
Gabriel Gilini
NickFitz
They are very clearly defined in the ECMA-262 ECMAScript Language
Specification, which can be downloaded from:
<http://www.ecma-international.org/publications/standards/
Ecma-262.htm>
Understand that document in its entirety, and you will realise that
there is nothing "dubious" about those productions. They are
syntactically well-formed code (although not conducive to legibility).
Regards,
Nick.
Richard Cornford
A particularly pertinent part of the specification may be the opening
paragraph of section 7, which reads:-
| The source text of an ECMAScript program is first converted into
| a sequence of input elements, which are either tokens, line
| terminators, comments, or white space. The source text is scanned
| from left to right, repeatedly taking the longest possible
| sequence of characters as the next input element.
It is the requirement to take "the longest possible sequence of
characters" that means that:-
returnX
- will always be a single Identifier token and never a ReservedWord
token followed by an Identifier token (as defined in section 7.5).
Richard.
Thomas 'PointedEars' Lahn
> I've just realized, looking at this "JavaScript compressor"[1] output,
> that, at least in Firefox 3.0.4, the whitespace(s) between the return
> statement and the expression that succeeds it is optional.
>
> Meaning that -
>
> function foo(){ return'bar'; } foo();
>
> - is a valid JavaScript program.
>
> I looked at the specifications (The return Statement - session 12.9) and
> couldn't find anything specific on this subject.
Obviously you have not searched for "white space":
| 7.2 White Space
|
| White space characters are used to improve source text
| readability and to separate tokens (indivisible lexical units)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| from each other, but are otherwise insignificant. White space
| may occur between any two tokens, and may occur within strings
^^^
| (where they are considered significant characters forming part
| of the literal string value), but cannot appear within any
| other kind of token.
|
| The following characters are considered to be white space:
| [...]
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Dr J R Stockton
5g2000yqm.googlegroups.com>, Thu, 23 Jul 2009 18:25:44, Gabriel Gilini
<gab...@usosim.com.br> posted:
>I've just realized, looking at this "JavaScript compressor"[1] output,
>that, at least in Firefox 3.0.4, the whitespace(s) between the return
>statement and the expression that succeeds it is optional.
Consider the following, and what it does in Firefox 3.0.11 and other
systems -
function A() alert(1) ; alert(2)
A() ; A()
That, to my mind, rather proves that (as you implicitly acknowledge) a
single browser cannot be used to determine reliably whether any
particular code is correct for all browsers.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
John G Harris
wrote:
>I've just realized, looking at this "JavaScript compressor"[1] output,
>that, at least in Firefox 3.0.4, the whitespace(s) between the return
>statement and the expression that succeeds it is optional.
>
>Meaning that -
>
>function foo(){
> return'bar';
>}
>foo();
>
>- is a valid JavaScript program.
Have you never wondered about
v=a+b;
as opposed to
v = a + b;
John
--
John Harris
John G Harris
Stockton wrote:
<snip>
>Consider the following, and what it does in Firefox 3.0.11 and other
>systems -
>
> function A() alert(1) ; alert(2)
> A() ; A()
>
>That, to my mind, rather proves that (as you implicitly acknowledge) a
>single browser cannot be used to determine reliably whether any
>particular code is correct for all browsers.
In an ideal universe every javascript parser would say syntax error. In
practice, programmers get pay rises and promotion for not handling cases
that don't happen very often, so there may be browsers that do something
with this code. To guess what they will do you would have to consult the
browser documentation (big laugh) as it's outside the agreed common
standards.
John
--
John Harris
Lasse Reichstein Nielsen
> I've just realized, looking at this "JavaScript compressor"[1] output,
> that, at least in Firefox 3.0.4, the whitespace(s) between the return
> statement and the expression that succeeds it is optional.
Whitespace has no intrinsic meaning, all it does is to separate tokens
(except newline in the case of semicolon-insertion). The parser
ignores whitespace.
> Meaning that -
>
> function foo(){
> return'bar';
> }
> foo();
>
> - is a valid JavaScript program.
Correct.
> I looked at the specifications (The return Statement - session 12.9)
> and couldn't find anything specific on this subject.
Whitespace is removed during tokenization, i.e. when "return" is
recognized as a keyword and "'bar'" as a string literal. Any whitespace
between the two is discarded there and the parser only sees the return
keyword and the string literal.
> So, is this true for every other modern browser?
It should be. It's what the specification requires.
> And if yes, it's kind of a quirk, isn't it?
No.
No more than the whitespace in "x + 2" is optional, and "x+2" means
the same thing.
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'
Dr J R Stockton
8924D9443D28E23ED5CD>, Sat, 25 Jul 2009 17:34:11, John G Harris
<jo...@nospam.demon.co.uk> posted:
Browser documentation tells at best what the documenter thought the
browser would or should do. It is no substitute for actual test. To
illustrate that point, compare what the JScript documentation says about
0.007.toFixed(2) and what IE does.
<FAQENTRY> ISTM that Section 5.1 paragraph 4 needs
correction : for 0.07 read 0.007. </FAQENTRY>
Firefox 3.0.11 & 3.0.12 give three alerts, 2 1 1. Other browsers don't
like the syntax.
--
(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 <sMVBKiFD...@J.A830F0FF37FB96852AD0
>8924D9443D28E23ED5CD>, Sat, 25 Jul 2009 17:34:11, John G Harris
><jo...@nospam.demon.co.uk> posted:
>>On Fri, 24 Jul 2009 at 22:34:42, in comp.lang.javascript, Dr J R
>>Stockton wrote:
>>
>> <snip>
>>>Consider the following, and what it does in Firefox 3.0.11 and other
>>>systems -
>>>
>>> function A() alert(1) ; alert(2)
>>> A() ; A()
>>>
>>>That, to my mind, rather proves that (as you implicitly acknowledge) a
>>>single browser cannot be used to determine reliably whether any
>>>particular code is correct for all browsers.
>>
>>In an ideal universe every javascript parser would say syntax error. In
>>practice, programmers get pay rises and promotion for not handling cases
>>that don't happen very often, so there may be browsers that do something
>>with this code. To guess what they will do you would have to consult the
>>browser documentation (big laugh) as it's outside the agreed common
>>standards.
>
>Browser documentation tells at best what the documenter thought the
>browser would or should do. It is no substitute for actual test.
A programmer who relies on any particular non-standard behaviour is
taking a risk, and if the product gets into trouble because of it the
programmer should be sacked for being too expensive.
>To
>illustrate that point, compare what the JScript documentation says about
>0.007.toFixed(2) and what IE does.
>
> <FAQENTRY> ISTM that Section 5.1 paragraph 4 needs
> correction : for 0.07 read 0.007. </FAQENTRY>
>Firefox 3.0.11 & 3.0.12 give three alerts, 2 1 1.
Firefox is obviously treating the function body as a statement. To be
consistent it shouldn't implement local variables inside functions as
they aren't allowed inside statements. Perhaps they are in Firefox ?
>Other browsers don't
>like the syntax.
Three cheers for other browsers!
But there's a syntax error that IE8 doesn't spot. I'll not publish it in
case some idiot starts using it.
John
--
John Harris
-TNO-
> Firefox 3.0.11 & 3.0.12 give three alerts, 2 1 1. Other browsers don't
> like the syntax.
Which is no doubt because those other browsers don't support
JavaScript 1.8
https://developer.mozilla.org/en/New_in_JavaScript_1.8#Expression_closures
Garrett Smith
> In comp.lang.javascript message <sMVBKiFD...@J.A830F0FF37FB96852AD0
> 8924D9443D28E23ED5CD>, Sat, 25 Jul 2009 17:34:11, John G Harris
> <jo...@nospam.demon.co.uk> posted:
>> On Fri, 24 Jul 2009 at 22:34:42, in comp.lang.javascript, Dr J R
>> Stockton wrote:
>>
>> <snip>
>>> Consider the following, and what it does in Firefox 3.0.11 and other
>>> systems -
>>>
>>> function A() alert(1) ; alert(2)
>>> A() ; A()
>>>
>>> That, to my mind, rather proves that (as you implicitly acknowledge) a
>>> single browser cannot be used to determine reliably whether any
>>> particular code is correct for all browsers.
>> In an ideal universe every javascript parser would say syntax error. In
>> practice, programmers get pay rises and promotion for not handling cases
>> that don't happen very often, so there may be browsers that do something
>> with this code. To guess what they will do you would have to consult the
>> browser documentation (big laugh) as it's outside the agreed common
>> standards.
>
> Browser documentation tells at best what the documenter thought the
> browser would or should do. It is no substitute for actual test. To
> illustrate that point, compare what the JScript documentation says about
> 0.007.toFixed(2) and what IE does.
>
I searched around for the JScript documentation you mentioned and found:
http://msdn.microsoft.com/en-us/library/sstyff0z(VS.85).aspx
| The toFixed method returns a string representation of a number in
| fixed-point notation. The string contains one digit before the
| significand's decimal point, and must contain fractionDigits digits
| after it.
Is that the documentation you were referring to?
Testing that number 0.007 in IE:
javascript:alert( 0.007.toFixed(2) )
Returns a string representation that contains one digit before the
significand's decimal point ("0"), a decimal point, and fractionDigits
after it ("00").
The result in IE is "0.00".
According to JScript documentation, I am not sure how to prove that that
is technically incorrect.
> <FAQENTRY> ISTM that Section 5.1 paragraph 4 needs
> correction : for 0.07 read 0.007. </FAQENTRY>
>
Why? IE 7 has incorrect result with 0.07.
You said so yourself:
http://www.merlyn.demon.co.uk/js-rndg1.htm#toF
Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
John G Harris
Where did 'closure' come from ? Did some marketing type grab hold of a
word that sounds posh and technical ?
Luckily it's not currently scheduled to go in ES5.
John
--
John Harris
-TNO-
> Luckily it's not currently scheduled to go in ES5.
Why luckily? Not having to type the extra boilerplate would be
beneficial I would think in a few situations. For example:
function Y(X)
(function(procedure)
X(function(arg) procedure(procedure)(arg)))
(function(procedure)
X(function(arg) procedure(procedure)(arg)))
Gabriel Gilini
wrote:
[snip]
> | The source text of an ECMAScript program is first converted into
> | a sequence of input elements, which are either tokens, line
> | terminators, comments, or white space. The source text is scanned
> | from left to right, repeatedly taking the longest possible
> | sequence of characters as the next input element.
>
> It is the requirement to take "the longest possible sequence of
> characters" that means that:-
>
> returnX
>
> - will always be a single Identifier token and never a ReservedWord
> token followed by an Identifier token (as defined in section 7.5).
Well, that explains it.
Thanks to everyone that took the time to answer, I really should have
looked closer at that.
--
Gabriel Gilini
John G Harris
It's not very readable, is it ?
Crockford enthusiasts will notice that leaving out the curly brackets in
this way is a bad part of JavaScript and hence will not be permitted by
JSLint.
John
--
John Harris
Dr J R Stockton
8924D9443D28E23ED5CD>, Mon, 27 Jul 2009 16:21:32, John G Harris
Certainly. But one should also not rely on standard behaviour unless
that has been confirmed by test. However, if the browser documentation
indicates non-standard behaviour and the browser itself conforms, like
other browsers, with the standard, then it should be safe enough to
assume that the documentation is wrong; though the really cautious would
avoid using that construct.
>>To
>>illustrate that point, compare what the JScript documentation says about
>>0.007.toFixed(2) and what IE does.
>>
>> <FAQENTRY> ISTM that Section 5.1 paragraph 4 needs
>> correction : for 0.07 read 0.007. </FAQENTRY>
>
>
>
>>Firefox 3.0.11 & 3.0.12 give three alerts, 2 1 1.
>
>Firefox is obviously treating the function body as a statement. To be
>consistent it shouldn't implement local variables inside functions as
>they aren't allowed inside statements. Perhaps they are in Firefox ?
ISTM otherwise. It is treating the "function A()" as needing a
following compound statement, and allowing a simple statement "alert(1)"
where a compound one is expected. The combination is wrong.
>>Other browsers don't
>>like the syntax.
>
>Three cheers for other browsers!
>
>But there's a syntax error that IE8 doesn't spot. I'll not publish it in
>case some idiot starts using it.
Would it not be better to publish it? Firstly, you could be wrong; and
secondly, publication might prevent others using it. There is a
hypothetical thirdly : that publication might lead to MS correcting it.
That has not worked with 0.7.toFixed(), and not with VBScript DatePart
ISO WeekNumber either.
Dr J R Stockton
september.org>, Mon, 27 Jul 2009 09:57:29, Garrett Smith
<dhtmlk...@gmail.com> posted:
>Dr J R Stockton wrote:
>> Browser documentation tells at best what the documenter thought the
>> browser would or should do. It is no substitute for actual test. To
>> illustrate that point, compare what the JScript documentation says about
>> 0.007.toFixed(2) and what IE does.
>>
>
>I searched around for the JScript documentation you mentioned and found:
>http://msdn.microsoft.com/en-us/library/sstyff0z(VS.85).aspx
>
>| The toFixed method returns a string representation of a number in
>| fixed-point notation. The string contains one digit before the
>| significand's decimal point, and must contain fractionDigits digits
>| after it.
>
>Is that the documentation you were referring to?
They have so much - it might be - it is equivalent. The URL that I had
is no longer good.
>Testing that number 0.007 in IE:
>
>javascript:alert( 0.007.toFixed(2) )
>
>Returns a string representation that contains one digit before the
>significand's decimal point ("0"), a decimal point, and fractionDigits
>after it ("00").
>
>The result in IE is "0.00".
>
>According to JScript documentation, I am not sure how to prove that
>that is technically incorrect.
Elementary arithmetic knowledge; what other browsers do; 16262 15.7.4.5
step 10. The documentation is not good; it is compatible with always
returning zero, to the required number of places; the error with that
will never exceed 100%.
>> <FAQENTRY> ISTM that Section 5.1 paragraph 4 needs
>> correction : for 0.07 read 0.007. </FAQENTRY>
>>
>
>Why? IE 7 has incorrect result with 0.07.
The FAQ section Subject includes "as a String with exactly 2 decimal
places?". IE gets 0.07 to 2 places correct. Therefore, an unqualified
0.07 is not a good example; 0.07 only errs with toFixed(1).
Consider : the expression (0.007).toFixed(2) gives 0.00 in JScript.
QUERY : is it now reasonably safe to call toFixed unconditionally, it is
an existence test needed still?
-TNO-
> >function Y(X)
> > (function(procedure)
> > X(function(arg) procedure(procedure)(arg)))
> > (function(procedure)
> > X(function(arg) procedure(procedure)(arg)))
>
> It's not very readable, is it ?
Its much more readable than its braced counterpart IMO:
function Y (X) {
return (function(procedure) {
return X(function(arg) {
return procedure(procedure)(arg);
});
})(function(procedure) {
return X(function(arg) {
return procedure(procedure)(arg);
});
});
}
Not to mention significantly smaller.
> Crockford enthusiasts will notice that leaving out the curly brackets in
> this way is a bad part of JavaScript and hence will not be permitted by
> JSLint.
It's not just about bracing, but about the return statement as well.
Not everyone practices or agrees with Douglas Crockford's Code
Convention choices, so I think it's a moot point. 1TBS has a popular
precedent, but is seen by a number of developers to be wasteful in as
well, especially in a web context.
Thomas 'PointedEars' Lahn
> On Jul 28, 12:21 pm, John G Harris <j...@nospam.demon.co.uk> wrote:
>>> function Y(X)
>>> (function(procedure)
>>> X(function(arg) procedure(procedure)(arg)))
>>> (function(procedure)
>>> X(function(arg) procedure(procedure)(arg)))
>> It's not very readable, is it ?
>
> Its much more readable than its braced counterpart IMO:
>
> function Y (X) {
> return (function(procedure) {
> return X(function(arg) {
> return procedure(procedure)(arg);
> });
> })(function(procedure) {
> return X(function(arg) {
> return procedure(procedure)(arg);
> });
> });
> }
I find both snippets as badly readable because of the unnecessary inline
expressions, i.e. the lack of use of variables; unnecessary, confusing reuse
of argument identifiers; and the whitespace after the `Y'. But if I ignore
that, I find the braced version better readable. The braces do help to
distinguish subroutine parts from argument lists, which are delimited by
parentheses.
> Not to mention significantly smaller.
Size is heavily overrated.
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.)
-TNO-
wrote:
> I find both snippets as badly readable because of the unnecessary inline
> expressions, i.e. the lack of use of variables; unnecessary, confusing reuse
> of argument identifiers; and the whitespace after the `Y'. But if I ignore
> that, I find the braced version better readable. The braces do help to
> distinguish subroutine parts from argument lists, which are delimited by
> parentheses.
Use of extra variables would be unnecessary since the argument names
serve this purpose well enough.
On the other points though, I'll admit the preference for I-
Expressions over M-Expressions is a matter of opinion.
>Size is heavily overrated.
Maybe. Most code I've seen on the web though err's on the side of
waste and abuse of network resources (ex: The usage and/or
implementation of many Ajax libraries).
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> I find both snippets as badly readable because of the unnecessary inline
>> expressions, i.e. the lack of use of variables; unnecessary, confusing reuse
>> of argument identifiers; and the whitespace after the `Y'. But if I ignore
>> that, I find the braced version better readable. The braces do help to
>> distinguish subroutine parts from argument lists, which are delimited by
>> parentheses.
>
> Use of extra variables would be unnecessary since the argument names
> serve this purpose well enough.
It would be easier readable if local variables would be assigned the
function expressions or expression closures (here: the former):
function y(x)
{
var f = function(procedure) {
return x(function(arg) {
return procedure(procedure)(arg);
});
};
var g = function(procedure) {
return x(function(arg) {
return procedure(procedure)(arg);
});
};
return f(g);
}
Indeed, this example shows that code reuse, which is more efficient, is
possible with variables, as f and g are equivalent. However, I was never in
need of any such pattern in about 12 years of ECMAScript scripting now, so
this discussion is rather academic to me.
> On the other points though, I'll admit the preference for I-
> Expressions over M-Expressions is a matter of opinion.
Sorry, my Web search did not yield results for `I-Expressions'.
Please elaborate.
>> Size is heavily overrated.
>
> Maybe. Most code I've seen on the web though err's on the side of
> waste and abuse of network resources (ex: The usage and/or
> implementation of many Ajax libraries).
True, however a few bytes more, as here, clearly do not count with any
reasonable Internet connection today (and even less on the local
filesystem). And the code will undoubtedly be in need of change more often
than being originally written or downloaded (thus the "do more, write less"
jQuery mantra is complete nonsense).
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
-TNO-
wrote:
> Sorry, my Web search did not yield results for `I-Expressions'.
> Please elaborate.
Very roughly speaking, an I-Expression is the use of indentation to
implicitly represent parenthesis/braces. It's not quite correct for me
to refer to a JavaScript expression closure as an I-Expression, but I
figured it was the quickest way to express the syntactic style
difference. I apologize for not being clearer, I was feeling lazy.
Ultimately, I just didn't see John G Harris's argument against
expression closures. People don't seem to complain too much about an
inline conditional:
if(foo){
bar
} else {
baz
}
vs.
foo ? bar : baz;
Maybe my choice of an example could have been better than the Y-
Combinator:
var factorial = function(n) (n == 0 || n == 1) ? 1 : n * factorial
(n-1);
Of course, I'm probably just a sucker for succinct code.
John G Harris
Stockton wrote:
>>>> <snip>
>>>>>Consider the following, and what it does in Firefox 3.0.11 and other
>>>>>systems -
>>>>>
>>>>> function A() alert(1) ; alert(2)
>>>>> A() ; A()
<snip>
>>>Firefox 3.0.11 & 3.0.12 give three alerts, 2 1 1.
>>
>>Firefox is obviously treating the function body as a statement. To be
>>consistent it shouldn't implement local variables inside functions as
>>they aren't allowed inside statements. Perhaps they are in Firefox ?
>
>ISTM otherwise. It is treating the "function A()" as needing a
>following compound statement, and allowing a simple statement "alert(1)"
>where a compound one is expected. The combination is wrong.
<snip>
On second thoughts it's more likely that the function body is replaced
by
expression ;
After all, it's supposed to represent the operand of a return statement.
I had a crawl round the Mozilla web site but couldn't find any
definition of this new function construct. Why am I not surprised ?
John
--
John Harris
John G Harris
<snip>
>Not everyone practices or agrees with Douglas Crockford's Code
>Convention choices,
<snip>
Beware! That will upset Jorge.
John
--
John Harris
-TNO-
> I had a crawl round the Mozilla web site but couldn't find any
> definition of this new function construct. Why am I not surprised ?
Your search-Fu needs more cowbell. I posted this link earlier in the
discussion:
https://developer.mozilla.org/en/New_in_JavaScript_1.8#Expression_closures
Dr J R Stockton
rlyn.invalid>, Tue, 28 Jul 2009 17:43:56, Dr J R Stockton
<repl...@merlyn.demon.co.uk> posted:
>
>Consider : the expression (0.007).toFixed(2) gives 0.00 in JScript.
>
>QUERY : is it now reasonably safe to call toFixed unconditionally, it is
>an existence test needed still?
Q ?
Furthermore, the range of number magnitudes for which JScript
X.toFixed(0) wr0ngly gives 0 is not 0.50 to 0.94 as previously stated,
but 0.50 t0 0.95. Those numbers scale by /10 as the argument is
incremented.
JScript +(X.toFixed(0)) also differs from Math.round(X) for the negative
half-integers (as required by the standards).
Page <URL:http://www.merlyn.demon.co.uk/js-rndg1.htm> is updated in that
part, with demonstrations.
It occurs to me that, while it would be too long for the FAQ itself, it
might be useful to have in the Notes one or more pages which demonstrate
by code such variations between browsers, as in that page and in
<URL:http://www.merlyn.demon.co.uk/js-datex.htm>. With code showing the
effect in the user's current browser, such a document can support all
browsers ; and, if differences are reported, one knows what the tests
were.
John G Harris
And I looked in the Mozilla 'Core JavaScript 1.5 Reference' to see that
function f() { return 42; }
is legal, but nowhere could I find out if
function f() return 42;
is legal, least of all in the 'New in JavaScript 1.8' page you point us
towards.
Worse, I can't even find out if shorthand function declarations are
allowed.
John
--
John Harris
-TNO-
> And I looked in the Mozilla 'Core JavaScript 1.5 Reference' to see that
>
> function f() { return 42; }
>
> is legal, but nowhere could I find out if
>
> function f() return 42;
>
> is legal, least of all in the 'New in JavaScript 1.8' page you point us
> towards.
>
> Worse, I can't even find out if shorthand function declarations are
> allowed.
Quoted from the page I referenced:
"This syntax allows you to leave off the braces and 'return' statement
- making them implicit. There is no added benefit to writing code in
this manner, other than having it be syntactically shorter."
Which reads to me to mean that the following are equivalent:
function f(){return 42};
function f() 42;
Typing these into the Fx browser console will show you that both are
valid syntax. Typing the following though into the browsers console
though will throw a syntax error:
function f() return 42;
We should be able to see some more in depth documentation on this
soon: http://wiki.ecmascript.org/doku.php?id=strawman:strawman
With trivial code like this, its much faster to run it through a
command line, then to dig around in often outdated documentation.
John G Harris
wrote:
Nor can I find out if
function f() ;
is legal, and if it is then nor can I find out if
function f()
alert (42)
has one implied semicolon or two. If it has two then Crockford will
surely classify it as being one of the 'awful parts' of JavaScript.
John
--
John Harris
John G Harris
<snip>
>With trivial code like this, its much faster to run it through a
>command line, then to dig around in often outdated documentation.
Never say that at a job interview.
John
--
John Harris
-TNO-
>
> Nor can I find out if
>
> function f() ;
>
> is legal, and if it is then nor can I find out if
>
> function f()
> alert (42)
>
> has one implied semicolon or two. If it has two then Crockford will
> surely classify it as being one of the 'awful parts' of JavaScript.
Testing this in the browser command line would have been faster than
asking the question
function f();
Will return a syntax error, as it is expecting an expression following
the parenthesis.
function f()
alert (42)
This is the same as writing:
function f() alert (42);
So its valid. I posted a code example that used this very same pattern
earlier. (The Y-Combinator).
-TNO-
Why not? If you don't claim to have knowledge you really don't have at
that interview, I bet it would be a moot point.
John G Harris
>On Aug 2, 4:02�am, John G Harris <j...@nospam.demon.co.uk> wrote:
<snip>
>function f();
>
>Will return a syntax error, as it is expecting an expression following
>the parenthesis.
<snip>
Says who ? What if you want to return undefined ?
John
--
John Harris
-TNO-
> Says who ?
The implementation says who.
> What if you want to return undefined?
function f() undefined;
Garrett Smith
> rlyn.invalid>, Tue, 28 Jul 2009 17:43:56, Dr J R Stockton
> <repl...@merlyn.demon.co.uk> posted:
>> Consider : the expression (0.007).toFixed(2) gives 0.00 in JScript.
>>
>> QUERY : is it now reasonably safe to call toFixed unconditionally, it is
>> an existence test needed still?
>
> Q ?
>
I'm not sure that toFixed is all that useful, due to rounding issues. I
mean, it is not something that could be used for money, right?
1.1255.toFixed(3);
IE7, some Safari versions:
1.126
Others:
1.125
> Furthermore, the range of number magnitudes for which JScript
> X.toFixed(0) wr0ngly gives 0 is not 0.50 to 0.94 as previously stated,
Is it? I see 0.95.toFixed(0)
IE7: 1
> but 0.50 t0 0.95. Those numbers scale by /10 as the argument is
> incremented.
>
> JScript +(X.toFixed(0)) also differs from Math.round(X) for the negative
> half-integers (as required by the standards).
JScript only, or implementations in general?
>
> Page <URL:http://www.merlyn.demon.co.uk/js-rndg1.htm> is updated in that
> part, with demonstrations.
>
>
> It occurs to me that, while it would be too long for the FAQ itself, it
> might be useful to have in the Notes one or more pages which demonstrate
> by code such variations between browsers, as in that page and in
> <URL:http://www.merlyn.demon.co.uk/js-datex.htm>. With code showing the
> effect in the user's current browser, such a document can support all
> browsers ; and, if differences are reported, one knows what the tests
> were.
>
Automated Unit Tests for standards are something I've wanted to do but
have not done. This could be done for ECMAScript and would be very
useful for the DOM.
It came up a w3c mailing list, but didn't get much follow up.
http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0035.html
My hesitations to setting up testing for the w3c is that it takes
effort. I don't want to abet those w3c members who would write tests for
what I think are very bad ideas. I think they would do this, and that it
could result in those bad ideas going into the latest build of whatever
browser, just to get a higher "compatibility rank" of passing more
tests. I do not endorse HTML 5. I don't want w3c members to use their
position to win arguments and write tests for bad ideas.
So, it is still a good idea, and I think it should be something that
members of this NG could start. That still takes effort, but instead of
testing the what wishlist, it can focus on existing w3c TRs and ECMAScript.
RobG
<sarcasm>
Which is clearly shorter, more readable and easily maintained than:
function f(){}
</sarcasm>
For the sake of two curly braces, the loss of clarity is simply not
worth it, even if it is shorter. Who thinks up this crap? Do they sit
around all day thinking "what obscure traps can we make for
programmers today"?
Don't these guys have editors with auto-complete?
--
Rob
Thomas 'PointedEars' Lahn
I do not think expression closures are a bad thing per se (they remind me
of Python's lambda expressions, which are quite useful and readable¹).
But as with all things, use them wisely.
> Don't these guys have editors with auto-complete?
Non sequitur. It is better for the programming language to provide
syntactic sugar than for developers needing to invent it.
PointedEars
___________
¹ as in map(lambda foo: foo['bar'], list_of_dicts)
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
John G Harris
The Mozilla 'New in JavaScript 1.8' web page says that
"This syntax allows you to leave off the braces and 'return'
statement - making them implicit."
Now
function f() { return ; }
is legal, so according to that web page
function f() ;
should also be legal as all I have done is to leave off the curly
brackets and 'return' keyword.
Face it, there's a bug in Firefox. Someone should report it.
Someone should also tell the Mozilla people that there's a not so subtle
difference between a keyword and a statement.
John
--
John Harris
-TNO-
> The Mozilla 'New in JavaScript 1.8' web page says that
>
> "This syntax allows you to leave off the braces and 'return'
> statement - making them implicit."
>
> Now
>
> function f() { return ; }
>
> is legal, so according to that web page
>
> function f() ;
>
> should also be legal as all I have done is to leave off the curly
> brackets and 'return' keyword.
>
> Face it, there's a bug in Firefox. Someone should report it.
>
> Someone should also tell the Mozilla people that there's a not so subtle
> difference between a keyword and a statement.
I forwarded the question to es-discuss, and Brendan Eich privileged me
with a response:
https://mail.mozilla.org/pipermail/es-discuss/2009-August/009692.html
Dr J R Stockton
8924D9443D28E23ED5CD>, Sun, 2 Aug 2009 20:08:44, John G Harris
<jo...@nospam.demon.co.uk> posted:
Try function f() {} ;
John G Harris
Interesting. They've written the code, released the product, now they're
asking for volunteers to work out what they should have done. Sheesh!
John
--
John Harris
-TNO-
> Interesting. They've written the code, released the product, now they're
> asking for volunteers to work out what they should have done. Sheesh!
There is no shame in innovation and experimentation on the advancement
of the language. You can't build everything perfect the first time.
Sometimes these things have to released in the wild to see what real
world code does with it. Take for example: https://bugzilla.mozilla.org/show_bug.cgi?id=366941
Dr J R Stockton
september.org>, Sun, 2 Aug 2009 23:27:06, Garrett Smith
<dhtmlk...@gmail.com> posted:
>Dr J R Stockton wrote:
>> In comp.lang.javascript message <TMnDRLMM...@invalid.uk.co.demon.me
>> rlyn.invalid>, Tue, 28 Jul 2009 17:43:56, Dr J R Stockton
>> <repl...@merlyn.demon.co.uk> posted:
>>> Consider : the expression (0.007).toFixed(2) gives 0.00 in JScript.
>>>
>>> QUERY : is it now reasonably safe to call toFixed unconditionally, it is
>>> an existence test needed still?
>> Q ?
You have not answered the explicit question - is it safe to call
toFixed? I expressed no interest in whether it is safe to believe the
result of the call. I was only interested in whether any reasonably
current browsers would in effect say "toFixed? never heard of it".
>I'm not sure that toFixed is all that useful, due to rounding issues. I
>mean, it is not something that could be used for money, right?
Money is not the only application in the world.
Money calculations should be done in integer arithmetic; cents for
ordinary work, M€ for eurocrats. <FAQENTRY> The FAQ should be modified
to say that.
Jibbering seems down.
A mirror is needed.
>1.1255.toFixed(3);
>
>IE7, some Safari versions:
>1.126
>
>Others:
>1.125
1.1255 cannot be represented exactly in a Double. There is no certainty
that +"1.1255" gives the same IEEE Double in all browsers, whatever the
Standard may say. And there is likewise no certainty that each of those
IEEE Doubles will, even in a carefully-written browser, will give the
same result on any conversion to string.
On the same lines : It was settled that one euro would be equal to
exactly 0.787564 punts. That did not mean that the Bank could take Tim
O'Shea & Co's balance of, say, IEP 1234567.89, as an IEEE Double, divide
it by 0.787564, and rewrite it as EUR 1567577.86; the required
arithmetic was expressed exactly, including rounding, in decimal. I
suspect they'd have ended up with EUR 1567580, but that is a guess.
>> Furthermore, the range of number magnitudes for which JScript
>> X.toFixed(0) wr0ngly gives 0 is not 0.50 to 0.94 as previously stated,
>
>Is it? I see 0.95.toFixed(0)
>
>IE7: 1
>
>> but 0.50 t0 0.95.
I wrote 0.50 to 0.95, carefully without saying whether the ends of the
range were to be included. In fact, as you must know, 0.95 cannot be
represented exactly by an IEEE Double.
JScript :
0.94999999999999990.toFixed(0) -> 0
0.94999999999999991.toFixed(0) -> 1
Since the limit is 0.95 not 0.94, I suspect that the effect is not a bug
as such but a foolishly-incorporated "feature".
>> Those numbers scale by /10 as the argument is
>> incremented.
>> JScript +(X.toFixed(0)) also differs from Math.round(X) for the
>>negative
>> half-integers (as required by the standards).
>JScript only, or implementations in general?
I was not then saying. I now say that is browser-dependent; there seems
to be a misinterpretation of the standard in at least one case. Work is
in hand.
>> Page <URL:http://www.merlyn.demon.co.uk/js-rndg1.htm> is updated in
>>that
>> part, with demonstrations.
and is more updated.
Tests comparing the numerical values of the strings given by
toExponential & toPrecision with the results of my own conversions in 5
browsers, for random inputs have shown no problems. Testing the same
values with toFixed in 4 browsers showed no problems. There was one
case where the input was very close to half-way between the two adjacent
possible output values obtained.
Those tests need to be run for longer.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Dr J R Stockton
september.org>, Sun, 2 Aug 2009 23:27:06, Garrett Smith
<dhtmlk...@gmail.com> posted:
>> In comp.lang.javascript message <TMnDRLMM...@invalid.uk.co.demon.me
>> rlyn.invalid>, Tue, 28 Jul 2009 17:43:56, Dr J R Stockton
>> <repl...@merlyn.demon.co.uk> posted:
>>> Consider : the expression (0.007).toFixed(2) gives 0.00 in JScript.
>>>
>>> QUERY : is it now reasonably safe to call toFixed unconditionally, it is
>>> an existence test needed still?
>> Q ?
You have not answered the explicit question - is it safe to call
toFixed? I expressed no interest in whether it is safe to believe the
result of the call. I was only interested in whether any reasonably
current browsers would in effect say "toFixed? never heard of it".
>I'm not sure that toFixed is all that useful, due to rounding issues. I
>mean, it is not something that could be used for money, right?
Money is not the only application in the world.
Money calculations should be done in integer arithmetic; cents for
ordinary work, M€ for eurocrats. <FAQENTRY> The FAQ should be modified
to say that.
Jibbering seems down.
A mirror is needed.
>1.1255.toFixed(3);
>
>IE7, some Safari versions:
>1.126
>
>Others:
>1.125
1.1255 cannot be represented exactly in a Double. There is no certainty
that +"1.1255" gives the same IEEE Double in all browsers, whatever the
Standard may say. And there is likewise no certainty that each of those
IEEE Doubles will, even in a carefully-written browser, will give the
same result on any conversion to string.
On the same lines : It was settled that one euro would be equal to
exactly 0.787564 punts. That did not mean that the Bank could take Tim
O'Shea & Co's balance of, say, IEP 1234567.89, as an IEEE Double, divide
it by 0.787564, and rewrite it as EUR 1567577.86; the required
arithmetic was expressed exactly, including rounding, in decimal. I
suspect they'd have ended up with EUR 1567580, but that is a guess.
>> Furthermore, the range of number magnitudes for which JScript
>> X.toFixed(0) wr0ngly gives 0 is not 0.50 to 0.94 as previously stated,
>
>Is it? I see 0.95.toFixed(0)
>
>IE7: 1
>
>> but 0.50 t0 0.95.
I wrote 0.50 to 0.95, carefully without saying whether the ends of the
range were to be included. In fact, as you must know, 0.95 cannot be
represented exactly by an IEEE Double.
JScript :
0.94999999999999990.toFixed(0) -> 0
0.94999999999999991.toFixed(0) -> 1
>> Those numbers scale by /10 as the argument is
>> incremented.
>> JScript +(X.toFixed(0)) also differs from Math.round(X) for the
>>negative
>> half-integers (as required by the standards).
>JScript only, or implementations in general?
I was not then saying. I now say that is browser-dependent; there seems
to be a misinterpretation of the standard in at least one case. Work is
in hand. ... For X.toFixed(0), where X is a half-integer, Opera 9.64
does Banker's Rounding, contrary to ISO/IEC 16262 15.7.4.5 #10.
Reported. Other browsers correctly round away from zero.
>> Page <URL:http://www.merlyn.demon.co.uk/js-rndg1.htm> is updated in
>>that
>> part, with demonstrations.
and is more updated.
John G Harris
How the hell can anyone try it out if they aren't told what they've been
given to try ?
John
--
John Harris
-TNO-
> How the hell can anyone try it out if they aren't told what they've been
> given to try ?
I'm not sure what you're specifically referring to here. Can you
define "it"?
John G Harris
Why, 'it' is any feature that's new in Firefox, of course. Did your 'it'
mean anything different ?
John
--
John Harris
-TNO-
> Why, 'it' is any feature that's new in Firefox, of course. Did your 'it'
> mean anything different ?
I was being specific, which is why your generic statement confused me.
So now that I know what you meant:
> How the hell can anyone try it out if they aren't told what they've been
> given to try ?
Every time you upgrade the browser you're told:
http://www.mozilla.com/en-US/firefox/releases/
Not to mention the variety of Mozilla blogs available.:
http://hacks.mozilla.org/
http://weblogs.mozillazine.org/
John G Harris
Were we told if
function f() ;
is legal or not, or that the syntax rule is not
function Identifier|opt ( FormalParameterList|opt ) expression ;
John
--
John Harris
-TNO-
> Were we told if
>
> function f() ;
>
> is legal or not, or that the syntax rule is not
>
> function Identifier|opt ( FormalParameterList|opt ) expression ;
Brendan Eich's explanation was clear. This is the rule that defines
what is and is not legal:
ExpressionClosure:
function Identifier[opt] ( FormalParameterList[opt] )
AssignmentExpression
John G Harris
This rule was revealed on Mon Aug 3 10:09:48 PDT 2009 as a byproduct of
this thread. Expressions closures were announced to be in Firefox in Oct
2008 or earlier.
What explanation was 'clear' last October ?
Also Eich says "The production is essentially" ... . How 'clear' is that
supposed to be ?
John
--
John Harris
-TNO-
> This rule was revealed on Mon Aug 3 10:09:48 PDT 2009 as a byproduct of
> this thread.
Absence of evidence is not evidence of absence. Just because I
happened to ask the question directly in relationship to your edge
case code earlier, does not mean no one else has in some other
discussion.
> Expressions closures were announced to be in Firefox in Oct 2008 or earlier. What explanation was 'clear' last October ?
I've found documentation for this construct going back to 2006 (For
example: http://wiki.ecmascript.org/doku.php?id=proposals:expression_closures,
and its related implementation bug in Fx: https://bugzilla.mozilla.org/show_bug.cgi?id=381113).
Are you questioning why John/Jane Doe of the open source community
didn't update the Wiki with a grammar production back in Oct 2008,
maybe you should ask him/her? This line of thinking is hardly
productive anbd I don't see the point. What is it you're still
confused about? It's starting to sound like you're looking for
something to complain about now.
> Also Eich says "The production is essentially" ... . How 'clear' is that
> supposed to be ?
What are you still confused about?
John G Harris
>On Aug 7, 1:39 pm, John G Harris <j...@nospam.demon.co.uk> wrote:
<snip>
>Are you questioning why John/Jane Doe of the open source community
>didn't update the Wiki with a grammar production back in Oct 2008,
>maybe you should ask him/her? This line of thinking is hardly
>productive anbd I don't see the point. What is it you're still
>confused about? It's starting to sound like you're looking for
>something to complain about now.
I'm not confused. You keep telling us to find out the rule by trying
various bits of code and seeing if it works. That's well known to be a
recipe for future problems and isn't appropriate in professional design
work.
Then you say the information is available, first by pointing to
something that's an incomplete outline, then to something that's just
been written, then to something that is an inconclusive series of
ramblings. I'm pointing out that the information isn't easy to find, and
maybe hasn't been published yet.
By implication, I'm also saying that it's a pretty poor show.
>> Also Eich says "The production is essentially" ... . How 'clear' is that
>> supposed to be ?
>
>What are you still confused about?
'essentially' means 'like, but not exactly like'. I'm not confused. I'm
just pointing out that we haven't been told the truth yet. At least, not
via the Firefox web site.
John
--
John Harris
-TNO-
> I'm not confused. You keep telling us to find out the rule by trying
> various bits of code and seeing if it works.
And yet you'll waste countless amount of time asking for the answer to
a problem that you could have discovered in seconds in a command line.
It's trivial code snippets.
> That's well known to be a
> recipe for future problems and isn't appropriate in professional design
> work.
This is an experimental, non-standardized language extension . Are
you building a professional application using relying upon it? Sounds
quite hypocritical.
> Then you say the information is available, first by pointing to
> something that's an incomplete outline
Incomplete in relationship to an edge case you presented
> then to something that's just
> been written,
To clarify your edge case....
> then to something that is an inconclusive series of
> ramblings.
I'm sorry if the production grammar is above your head, I don't have
the patience to explain further.
> I'm pointing out that the information isn't easy to find, and
> maybe hasn't been published yet.
The references I gave you from the standards sight are the most up to
date you will find. Anything beyond that is better asked from the
language designers as I had done for you.
> By implication, I'm also saying that it's a pretty poor show.
And yet you'll complain about it to everyone but the right people? Not
very productive
> >> Also Eich says "The production is essentially" ... . How 'clear' is that
> >> supposed to be ?
It's an experimental language extension, and has a good probability of
being a moving target before implementation. I clear enough to answer
your question, and clear enough to implement it yourself.
> 'essentially' means 'like, but not exactly like'. I'm not confused. I'm
> just pointing out that we haven't been told the truth yet. At least, not
> via the Firefox web site.
You're implying someone is lying and/or intentionally keeping you in
the dark, which they clearly are not.
-TNO-
> The references I gave you from the standards sight are the most up to
> date you will find. Anything beyond that is better asked from the
> language designers as I had done for you.
s/sight/site
John G Harris
<snip>
>It's an experimental language extension, and has a good probability of
>being a moving target before implementation.
<snip>
Something for John Stockton to ponder upon.
John
--
John Harris
Dr J R Stockton
8924D9443D28E23ED5CD>, Sat, 8 Aug 2009 19:13:39, John G Harris
<jo...@nospam.demon.co.uk> posted:
>I'm not confused. You keep telling us to find out the rule by trying
>various bits of code and seeing if it works. That's well known to be a
>recipe for future problems and isn't appropriate in professional design
>work.
Finding out what happens on actual systems seems essential for
professional implementation.
One should use only that which *both* ought to work *and* actually does
work.
If something does not work in one of, say, IE & FF, then it's not
appropriate for Web use, even if one thinks the standard says that it
should work.
And I can test, say, for (J=1 ; J<9) J++ in the current browser
in less time than it takes to open the ECMA PDF, let alone find the
right part of it.
John G Harris
Stockton wrote:
>In comp.lang.javascript message <h3t9R+GT...@J.A830F0FF37FB96852AD0
>8924D9443D28E23ED5CD>, Sat, 8 Aug 2009 19:13:39, John G Harris
><jo...@nospam.demon.co.uk> posted:
>
>>I'm not confused. You keep telling us to find out the rule by trying
>>various bits of code and seeing if it works. That's well known to be a
>>recipe for future problems and isn't appropriate in professional design
>>work.
>
>Finding out what happens on actual systems seems essential for
>professional implementation.
>
>One should use only that which *both* ought to work *and* actually does
>work.
>
>If something does not work in one of, say, IE & FF, then it's not
>appropriate for Web use, even if one thinks the standard says that it
>should work.
We're talking about different quadrants of the true/false
positive/negative diagram. I'm talking about code that appears to do
something but isn't described by any public standard. You're talking
about something that is described in a public standard but doesn't work
in some browsers. The second case is annoying, but at least it can be
proved by running a piece of code and noting what happens (or doesn't).
>And I can test, say, for (J=1 ; J<9) J++ in the current browser
>in less time than it takes to open the ECMA PDF, let alone find the
>right part of it.
If it fails you know not to use it, though you don't know whether it was
supposed to work or not.
If it doesn't fail you have a problem working out what it's safe to
assume.
John
--
John Harris