Re: Adding new methods to existing classes

David Golightly wrote:
On Aug 28, 1:56 am, Thomas 'PointedEars' Lahn wrote:
David Golightly wrote:
1. Use [], not the Array constructor.
Given that the Array initializer `[...]' is not universally supported
(introduced in JavaScript 1.3, JScript 2.0, ECMAScript 3), but Array() can
be considered to be so (introduced in JavaScript 1.1, JScript 1.0,
ECMAScript 1), that is bad advice.

As always, I can learn from your dogmatic advice.

It is not dogmatic, it merely points out the flaws in your "argumentation".

BTW: It was you you who started giving dogmatic advice by recommending that
the Array constructor should not be used, without providing a reason for
that recommendation.

Though in this case it's baseless; it's folly to even start to think about
supporting browsers made (and abandoned by their makers) before 1999, unless
you have very specific reasons for doing so.

The very specific reason is backwards compatibility.

Preferring [] to - new Array(0) -

As I said, those two are *not* semantically identical.

is recommended by the standardistas I care about, such as Brendan Eich and
Douglas Crockford, so I'll ignore your suggestion here.

Logical fallacy: ipse dixit. <http://en.wikipedia.org/wiki/Appeal_to_authority>

See below.

2. Never, ever use the for .. in syntax to iterate through an Array,
*especially* if you're extending Array.prototype.
The reasoning is flawed. Because of the issue with the `in' operator, one
should have very good reasons before augmenting the Array.prototype object.
However, the `in' operator can still be used if used within a wrapper
method for the augmented prototype.

The reasoning is hardly flawed.

Yes, it is. It is implying that iterating through an array always has to
follow an order; it is also saying that for...in should not be used on Array
objects (no matter the reason), and it is implying that a valid reason for
not using for...in on Array objects is that their prototype object may be
augmented.

Unless you really know what you're doing, you don't have much reason to do
either thing.

If you do not really know what you are doing, you should not do anything
because the results would be ultimately fatal otherwise.

So this is a fine rule of thumb. Care to give an example of what you're talking
about here?

/**
* @see http://PointedEars.de/scripts/types.js
*/
function isMethodType(s)
{
return /\b(function|object)\b/i.test(s);
}

Array.prototype.forEach = function(callback)
{
if (isMethodType(typeof callback) && callback)
{
var h = isMethodType(typeof this.hasOwnProperty)
&& this.hasOwnProperty;
for (var i in this)
{
if ((h && this.hasOwnProperty(i))

// or implement a search for previously
// registered property names here
|| (!h && i != "forEach"))
{
callback(i, this);
}
}
}
};

Use a conventional for (var i=0, len=this.length; i<len; i++) loop instead.
That is correct when order is significant, however it is less efficient when
it is not. Also, if iteration in reverse order is acceptable,

for (var i = this.length; i--;)

is more efficient than the above.

Perhaps. Could you explain?

0 evaluates to `false', anything else evaluates to `true'.

3. Don't use parentheses with the "return" keyword.
There is nothing wrong with doing that. And given that some expressions do
not fit on one line if code style is observed, and that automatic semicolon
insertion exists, this is bad advice.

Nope again. A paren *might* be advisable to wrap a long expression,
but should not be used automatically with - return - as though it were
a function.

Whitespace between keyword and value suffices for the keyword not to be
misinterpreted by the human reader as a function/method. It is merely a
matter of code style.

See Crockford (ibid.) for justification.

Same fallacy here.

4. Always end lines in semicolons.
That ignores that a line does not need to end a statement, which turns it
into bad advice.

Nitpicking. Too often semicolons are left off where they're later
inserted by the compiler, which leads to bugs.

I did not debate that.

Run your code through JSLint (http://www.jslint.com/lint.html) for
some enlightening suggestions.
For you as well.

Hm, I don't see that my code produces any errors in JSLint. Give an
example. Also, JSLint exists to *enlighten*, not to enforce.

Enlightenment is man's leaving his self-caused immaturity. Immaturity is
the incapacity to use one's intelligence without the guidance of another.
-- Immanuel Kant, "What is Enlightenment?" (1784)

But a better technique would be to implement JS 1.6's
[...]
as it's already there on most every browser but IE.
It is implemented since JavaScript 1.6 in Gecko-based UAs, and is not
part of any standard. That is hardly "most every browser but IE".

Not quite. Webkit-based browsers (Safari/Konquereror) implement this
as well.

At least
http://developer.kde.org/documentation/library/3.4-api/kjs/html/array__object_8cpp-source.html
contains nothing of the kind.

And it's better to start with something that's at least
*partially* compatible with *some* browsers than invent your own
solution that's not compatible with *any* browser.

Flawed reasoning again. Any own (user-defined) solution would have to
be compatible with any browser, or it does not deserve its designation.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@xxxxxxxxxxxxxxxx>
.

Relevant Pages

  • Re: jQuerys latest stab at competence
    ... people are js gods - the creators and implementers of the language). ... specific javascript language/standard issues. ... HTML and CSS - the advice rendered by the knowledgeable on this group ... I can buy this - but not as a good reason. ...
    (comp.lang.javascript)
  • Re: jQuerys latest stab at competence
    ... enlightened by some of the advice, insight and discussion I see on ... specific javascript language/standard issues. ... HTML and CSS - the advice rendered by the knowledgeable on this group ... I can buy this - but not as a good reason. ...
    (comp.lang.javascript)
  • Re: Adding new methods to existing classes
    ... I can learn from your dogmatic advice. ... should have very good reasons before augmenting the Array.prototype object. ... It is implemented since JavaScript 1.6 in Gecko-based UAs, ... That is hardly "most every browser but IE". ...
    (comp.lang.javascript)
  • Re: FAQ Topic - How do I get my browser to report javascript errors?
    ... When a new browser version is released, ... When the javascript engine has reason to believe that the result cannot ... For the above reason, there should always be visible error indication. ...
    (comp.lang.javascript)
  • Re: gEBI wrapper (Code Worth Recommending Project)
    ... Would you test for the following old language features before you used ... No, that was introduced with JavaScript 1.0, and JScript 1.0. ... same reason as for Array.prototype.join. ... Anyone who slaps a 'this page is best viewed with Browser X' label on ...
    (comp.lang.javascript)
Loading