Augmenting Types

[Jorge]

You truly are a student of Crockford.

Yes I am.

For about the millionth time,
that method doesn't work in "ancient" browsers like Safari 2.

And who cares ? If Safari 2 is broken it's not your/my problem (as
developers).

"If a web browser is defective, causing errors in the display or
performance of the page, should the page developer struggle to hide
the browser's defects, or should the defects be revealed in hope of
creating market pressure to force the browser maker to make good? By
which approach is humanity better served ?"

I see
it used without proper feature detection and wonder if the authors
realize their scripts will suddenly halt at that spot.  Does that seem
a sound degradation strategy to you?

Yes it is. People should (learn to) not expect a broken browser (e.g.
IEs) to work as if it weren't broken.

And of all the miserable JS libraries out there, how many actually
filter for-in loops in any form?

In the first place, why are these miserable libraries in *your* page ?

Does it seem to you that I've "ditched" ".prototype inheritance".

Sort of. Because that's the sole mechanism to extend built-ins /
"augmenting types" (this thread's subject), and you've said:

<quote>

Dear God.  That's another step towards the abyss.  (...)


No.

(...)
Lucid as always.  

You're welcome.

 

[Jorge]

No, it isn't, even in case you know exactly what you're doing.

Dear God ! Another step towards the abyss ?

 

[David Mark]

Yes I am.


And who cares ? If Safari 2 is broken it's not your/my problem (as
developers).

Here we go again. Lacking the hasOwnProperty method does not indicate
that the browser is broken. Do the words "progressive
enhancement" (or even "graceful degradation") mean _anything_ to you?

"If a web browser is defective, causing errors in the display or
performance of the page, should the page developer struggle to hide
the browser's defects, or should the defects be revealed in hope of
creating market pressure to force the browser maker to make good? By
which approach is humanity better served ?"

That's the stupidest thing you've parroted yet. As mentioned, missing
features are not defects. The end-users, who sometimes have no
control over what browser they use (and sometimes no idea of what a
browser is) are hardly going to appreciate such a crusade. If your
script(s) break documents, it indicates that your design is
defective. How can you not see that?

Yes it is. People should (learn to) not expect a broken browser (e.g.
IEs) to work as if it weren't broken.

LOL. So you should just screw all IE users and figure they will be
grateful for the tough love? Are you insane?

In the first place, why are these miserable libraries in *your* page ?

They certainly aren't, but if you distribute a script for other Web
developers to use, you can hardly predict what will be mashed up with
it. Some go so far as to combine jQuery, Prototype, Mootools, [insert
broken Flash script here], etc. in one document. That's the current
reality. Get with it or go home.

Sort of. Because that's the sole mechanism to extend built-ins /
"augmenting types" (this thread's subject), and you've said:

Think again. Or just try reading before posting obvious falsehoods.

<quote>



</quote>

Augmenting built-in types is not the only way to leverage prototypal
inheritance.

You're welcome.

Beat it, Jorge.

 

[David Mark]

Dear God ! Another step towards the abyss ?

Jorge wanna cracker?

 

[JR]

Dear God ! Another step towards the abyss ?

The guy asked our opinion. Mine was stated: I'm against type
augmentation although I know it's possible and can increase
expressiveness of JS. That's just an opinion and I can't see how being
prudent would be a step towards the abyss? I believe in "If it isn't
broken, don't fix it.", and "If something can go wrong, it will."

 

[Jorge]

Here we go again.  Lacking the hasOwnProperty method does not indicate
that the browser is broken.(...)

Safari 2.0.4 does have .hasOwnProperty()...

 

[David Mark]

Safari 2.0.4 does have .hasOwnProperty()...

That's as maybe. Now check 2.0.3, then 2.02... Or, simply wake up
and realize it isn't necessary to worry about such trivia.

if (Object.prototype.hasOwnProperty) {
// Your enhancement here
}

 

[Jorge]

LOL.  So you should just screw all IE users and figure they will be
grateful for the tough love?  Are you insane?

Don't know where you've been lately, but the days when you had to use
IE, yes or yes, are gone.

 

[David Mark]

Don't know where you've been lately, but the days when you had to use
IE, yes or yes, are gone.

Huh? I don't know where _you_ have been lately, but many large
corporations have endless seas of cubes stocked with IE users. Some
even have ActiveX and/or JS disabled _for them_ when using the public
Internet. Try that combo (both off) and notice that 90% of the Web
falls apart (100% of jQuery-enhanced sites). One thing about
corporate users, they all have jobs (and the disposable income that
comes with them). And they are known to surf the Internet on
occasion.

Then there is the Little Old Lady from Pasadena who doesn't know what
IE is, let alone FF or the rest. These sites that throw up
admonitions to "upgrade" to FF (it's free!) are simply displaying a
thorough misunderstanding of their medium.

I know you are one of those "JS or die" proponents as well. There are
laws you know. Many handicapped people have JS disabled by necessity
(and some may even use IE). Does the Little Blind Old Lady from
Pasadena want to hear you babble about how her browser sucks? Oddly
enough, many little old ladies (even blind ones) have money (and time)
to spend on the Internet too.

And consider the somewhat similar medium of television. Do you think
for a second that broadcasters would knowingly cripple their
programming for people with "defective" televisions? Why do you think
it took so long for them to pull the plug on over-the-air analog
broadcasts? By your way of thinking, who in the world doesn't have
cable and/or satellite? Now, what would advertisers think of such
thinking?

 

[David Mark]

Huh?  I don't know where _you_ have been lately, but many large
corporations have endless seas of cubes stocked with IE users.  Some
even have ActiveX and/or JS disabled _for them_ when using the public
Internet.  Try that combo (both off) and notice that 90% of the Web
falls apart (100% of jQuery-enhanced sites).

Correction. I meant to say that 100% of jQuery-enhanced sites will
fail with ActiveX off (at least if they try to use Ajax). With both
off, perhaps 50% (just a guess). That is the only sort of
"progressive" enhancement that jQuery and the like allow for (on or
off).

 

[Jorge]

That's as maybe.  Now check 2.0.3, then 2.02...

So you admit that you really don't know what you were talking about ?

 

[David Mark]

So you admit that you really don't know what you were talking about ?

Not sure how you figure that, but then you are obviously mad.

 

[Garrett Smith]

Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
Augmenting Types, e.g.

Function.prototype.method = function(name, func) {
this.prototype[name] = func;
return this;
};

This is not a good thing.

The `method` method is not related to all Functions; only constructors.

Non sequitur. All Function instances may be used as constructor.

No, none of the built in functions may be used as a constructor.

Only that this is not equivalent (note the `return'), and if feature-tests
were added as they should be, there would probably be the clutter that you
are talking of below, in the main code.

Feature tests for what?

No.

No *what*?

True, it would only qualify as `method' if it checked for method references
for the second argument, and the property name misses a verb (e.g.
setMethod).

Right.


Any abstraction does. That is not a good reason for not doing it.

Yes, actually it is. There is no benefit to that method being there.

Define: clutter.

Useless code that takes more time to comprehend (by machines or humans).

Another example of useless code:-

| if(goog.isDef( node.nextSibling )) {
|
| }

Method goog.isDef is potentially misleading to someone who is less
familiar with the Google closure library. The abstraction doesn't really
add any value.

Whereas `namespace' should be understood as syntactic sugar created by
aggregation, not (yet) as a language feature. One should therefore be
aware that the less probability of name collision that this "namespacing"
provides comes with a performance penalty.

The greater performance penalty is not in the runtime overhead of
calling `namespace`; it's with the management of the `namespace` code
itself.

The file where `namespace` is defined should be looked at before
including it in the application. If that file contains a bunch of junk,
then the prospect of using that file, and consequently the thing that
uses it, becomes less appealing.

 

[Thomas 'PointedEars' Lahn]

Ryan Chan wrote:
Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
Augmenting Types, e.g.

Function.prototype.method = function(name, func) {
this.prototype[name] = func;
return this;
};

This is not a good thing.
The `method` method is not related to all Functions; only constructors.

Non sequitur. All Function instances may be used as constructor.

No, none of the built in functions may be used as a constructor.

That is obviously wrong. RTFM.

Feature tests for what?

Callability, to the extent this can be detected. The method `method' here
is supposed to add only *methods* after all.

No *what*?

No, it is not unnecessary.

Yes, actually it is. There is no benefit to that method being there.

There is apparently no benefit that you can see, but there is one.

Useless code that takes more time to comprehend (by machines or humans).

But it is not useless, and if the method was named properly, the resulting
code would not be considerably harder to understand for humans. As to what
machines could understand, we should not argue about that as long as
machines have not achieved intelligence.

Another example of useless code:-

| if(goog.isDef( node.nextSibling )) {
|
| }

Method goog.isDef is potentially misleading to someone who is less
familiar with the Google closure library.

Possible, but that does not preclude abstractions from being not misleading
in general.

The abstraction doesn't really add any value.

Impossible to say without seeing the called code. In any case, your proof-
by-example is fallacious.

The greater performance penalty is not in the runtime overhead of
calling `namespace`; it's with the management of the `namespace` code
itself.

No, it is within the aggregation that comes with this "namespacing" which
forces more evaluation. Local aliasing cannot prevent that, only alleviate
it.

The file where `namespace` is defined should be looked at before
including it in the application. If that file contains a bunch of junk,
then the prospect of using that file, and consequently the thing that
uses it, becomes less appealing.

You miss the point: `foo.bar.baz' is always less efficient than `baz'.


PointedEars

 

[David Mark]

They won't _just fail_.

Last time I checked IE would actually propose to disable scripts as soon
as "automation server can't create object ..." error (the one that's
thrown when initializing ActiveXObject with disabled ActiveX controls)
happened.

Propose? I've never seen it do anything but throw that obscure error
message at the user. What version/configuration are you talking
about?

And assume if it did. Put yourself in the end-user's chair. You see
a dialog asking if you want to disable scripts on this page. The back
button is the next move for most.

User can choose to disable scripts and proceed with a fully functional
page/app (that is, if things work without scripting,

And that's a big if, of course. Most users will panic and flee
anyway.

of course ). I
don't know if this popup appears in IE consistently. There's probably
also a chance of popup being disabled (e.g. by administrator); or user
not understanding what popup message means and choosing to leave script
running, ending up with defunct application.

Yep. There's no right answer for the user. Most will have no clue
which to choose anyway.

But obviously there's really no reason to let errors like this happen. I
think the problem is that not many developers are aware of a possibility
for ActiveX to be disabled, and what to do about all this.

And that's very odd as it has been over a decade since IE6 came out
(and these issues were present IE < 6 as well). Why should such
developers endeavor to shield neophytes from the rigors of cross-
browser scripting (translates to dealing with IE for most
applications) when they can't figure out IE. They had a decade of
relative calm on that front and then...

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
Garrett Smith wrote:
Ryan Chan wrote:
Function.prototype.method = function(name, func) {
this.prototype[name] = func;
return this;
};

This is not a good thing.
The `method` method is not related to all Functions; only
constructors.
Non sequitur. All Function instances may be used as constructor.

No, none of the built in functions may be used as a constructor.

That is obviously wrong. RTFM.

Wrong? Hardly. Incomplete, yes.

A more correct rephrasing would probably be:

None of the built-in functions may be used as a constructor, as none of
them shall implement internal [[Construct]] method (unless specified
explicitly in a corresponding section of specification).

How can something be "more correct" (there is no comparison of "correct")
when it is still obviously wrong?


PointedEars

 

[Garrett Smith]

Thomas 'PointedEars' Lahn wrote:
Garrett Smith wrote:
Ryan Chan wrote:
Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
Augmenting Types, e.g.

Function.prototype.method = function(name, func) {
this.prototype[name] = func;
return this;
};

This is not a good thing.
The `method` method is not related to all Functions; only
constructors.
Non sequitur. All Function instances may be used as constructor.

No, none of the built in functions may be used as a constructor.

That is obviously wrong. RTFM.

LOL. YOU read the fucking manual.

Wrong? Hardly. Incomplete, yes.

A more correct rephrasing would probably be:

None of the built-in functions may be used as a constructor, as none of
them shall implement internal [[Construct]] method (unless specified
explicitly in a corresponding section of specification).

You are far too kind.

 

[David Mark]

IE7 shows error popup and asks if I want to continue running scripts on
this page.

That may depend on the configuration. I know that some versions of IE
spew out the "automation server" message, which is going to scare the
hell out of most users.

Something like this �
<http://chadsanswers.com/wp-content/uploads/2009/04/toaster.jpg>, but
different error of course.

Yep, that's a failure alright.

[...]

And that's very odd as it has been over a decade since IE6 came out
(and these issues were present IE<  6 as well).  Why should such
developers endeavor to shield neophytes from the rigors of cross-
browser scripting (translates to dealing with IE for most
applications) when they can't figure out IE.  They had a decade of
relative calm on that front and then...  

I've been meaning to write about it for some time now. Will do whenever
I get a chance. Perhaps someone will listen.

Perhaps.

 

[David Mark]

That may depend on the configuration.  I know that some versions of IE
spew out the "automation server" message, which is going to scare the
hell out of most users.




Yep, that's a failure alright.  

And I think it bears pointing out that there is no recovery from such
an exception. It is highly unlikely that subsequent executions on the
page will be successful after such a flame-out.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
Garrett Smith wrote:
Thomas 'PointedEars' Lahn wrote:
Garrett Smith wrote:
Ryan Chan wrote:
Function.prototype.method = function(name, func) {
this.prototype[name] = func;
return this;
};

This is not a good thing.
The `method` method is not related to all Functions; only
constructors.
Non sequitur. All Function instances may be used as constructor.
No, none of the built in functions may be used as a constructor.
That is obviously wrong. RTFM.
Wrong? Hardly. Incomplete, yes.

A more correct rephrasing would probably be:

None of the built-in functions may be used as a constructor, as none of
them shall implement internal [[Construct]] method (unless specified
explicitly in a corresponding section of specification).

How can something be "more correct" (there is no comparison of
"correct") when it is still obviously wrong?

You can't be serious...

I am dead serious.

I'm sure you can find relevant section in specs on your own.

The question is: Can you? For the Specification is _not_ clear there, and
implementations vary.

ECMAScript Edition 5 states:

| 15 Standard Built-in ECMAScript Objects
|
| [...]
| None of the built-in functions described in this clause that are not
| constructors shall implement the [[Construct]] internal method unless
| otherwise specified in the description of a particular function. [...]

Mark the wording: "built-in functions that are not constructors". Now,
what *is* a "constructor"?

| 4.3.4
| constructor
| Function object that creates and initialises objects.

But the Specification defines that a "built-in function" is a "built-in
object that is a function." (ES5, 4.3.23), and that a "function (object)"
is a "member of the Object type that is an instance of the standard built-
in Function constructor and that may be invoked as a subroutine." (4.3.22)

There is *nothing* in the Specification that says that Function instances
are not [[Construct]]able by default. In fact, function instances/objects
do have by default an internal [[Construct]] property. (13.2)

But yes, I concur that section 15 casts doubt about whether built-in
methods should be used as constructor; to do that is probably error-prone.

However, in any case the statement "None of the built in functions may be
used as a constructor." is not only incomplete; it is obviously _wrong_.
As the statement is an existential negation, to prove it wrong I need only
one counter-example:

var o = new Object();


HTH

Pointed"new Array.prototype.join()"Ears