Thomas said:
Garrett said:
Thomas said:
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.
Callability, to the extent this can be detected. The method `method' here
is supposed to add only *methods* after all.
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.
With no evidence that there is benefit.
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.
When I see:-
Function.method(
(looks to see method signature again)..
When I see Base.method("foo", fooFunc), it is not as instantly
recognizable as Base.prototype.foo = fooFunc; The latter, I can know
exactly what it does, whereas with the former, I have to remember what
Base.method does.
Again with the packaging of software, if a constructor depends on a 20k
file of Function.prototype.method plus other things, just so it can get
that 20k file's Function.prototype.method, it becomes less attractive.
Ifthat 20k file contains a myriad of other things such as typechecking,
String.prototype.supplant, or other such junk, then the prospect of
using that particular dependency becomes even less attractive.
The same exact argument applies to namespacing, too. I don't want a
namespace function when I have to take a bunch of other crapola along
with it. If the thing that I am interested in has a large dependency, it
is less appealing.
That, to me, is why the js libraries are at huge disadvantage. To use
something of Dojo or YUI or Ext requires a very large core dependency. A
lot of that core is code that is both unnecessary and in many cases
(especially for Ext and Dojo) buggy.
Small tweaks for performance matter but the architecture and design of a
framework can have more significant impacts on performance.
Possible, but that does not preclude abstractions from being not misleading
in general.
Impossible to say without seeing the called code. In any case, your proof-
by-example is fallacious.
No, it is within the aggregation that comes with this "namespacing" which
forces more evaluation. Local aliasing cannot prevent that, only alleviate
it.
You miss the point: `foo.bar.baz' is always less efficient than `baz'.
No, I don't miss your point. I got it. You wrote that foo.bar.baz is
less efficient that just `foo`. You're right; it is. But that is hardly
a consideration because the efficiency of lookup for user-defined
objects is fast.
(function(){
var foo = { bar : {baz :0 } };
var d = new Date;
for(var i = 0; i < 10000; i++)
foo.bar.baz = foo.bar.baz+1;
return new Date-d;
})();
Ten thousand iterations and it is running in under 10ms.
Performance with DOM operations is a different matter. For DOM ops,
[[Get]] is going to often perform not just a property lookup, but
something else more expensive.
(function(){
var foo = document.body;
var d = new Date;
for(var i = 0; i < 10000; i++)
foo.firstChild.nextSibling
return new Date-d;
})();
Bumps it up to 200ms in IE.
Then there is the issue of evaluating the call to the namespace
function. That will happen at load time, not runtime. A heavy
application might use up to 50 calls to create a namespace. That would
not be measurable in milliseconds (maybe 1 millisecond on a 2ghz machine).
If I bump the number of calls up to 1000, and declare 1000 unique
"packages" off a "base" package, with two sub-packages, there should be
a total of 3001 packages d.b0, d.b0.c, d.b0.c.d, d.b1...
(function(){
var APE= window.APE;
var d = new Date;
for(var i = 0; i < 1000; i++)
APE.namespace("d" + ".b" + i + ".c.d");
return new Date-d;
})();
IE7
121
Firefox:
36
Opera
12
That's up to 121ms in IE7. That is measurable. It is a lot of packages,
though.
Now notice in the example that "d" is the "base" "package". If I instead
use a unique base package, say, "d" + i, the performance decreases
measurably. This is because a the base object has a longer chain.
If I use a unique "base" "package" and shorten the chain, then
performance is still decreased in IE7. This is because I am now creating
4000 unique packages, and I am accessing properties off the global
object (999 more than before).
Accessing properties off the global object is slower than accessing
properties off a user defined object.
Access property off global object:
(function(){
var p = window;
var d = new Date;
for(var i = 0; i < 10000; i++)
p["d" + ".b" + i + ".c.d"] = i;
return new Date-d;
}())
IE7:
129
FF:
33
Opera:
28
Access property off user-defined object:
(function(){
var p = {};
var d = new Date;
for(var i = 0; i < 10000; i++)
p["d" + ".b" + i + ".c.d"] = i;
return new Date-d;
}())
IE7:
97
FF3.5:
25
Opera:
27
The namespace function creating 3000 namespaces in IE is measurable.
Creating maybe 100 namespaces seems like a big stretch of practicality
in an application. Probably 10 namespaces is more like a reality. The
overhead for that would be nanoseconds.
