R
Richard Cornford
Peter said:
True, and it is a very useful facility to have. But it is only very
occasionally a useful facility to have.
Take the last version of Prototype.js that I looked at (1.6.0.2).
Internally there are 28 calls to its - bind - method and precisely zero
of those pass more than one argument to the method. The method's code
is:-
| bind: function() {
| if (arguments.length < 2 && Object.isUndefined(arguments[0]))
| return this;
| var __method = this, args = $A(arguments), object = args.shift();
| return function() {
| return __method.apply(object, args.concat($A(arguments)));
| }
| },
- so each of those calls to - bind - test the length of arguments and
finds that it is 1 and so calls Object.isUndefined. If the first
argument is not undefined (and in 9 of those calls the argument passed
is - this -, which can never be undefined by detention) it goes on to
call - $A - in order to make an array of the arguments object, it then
renders that array empty by - shift-ing the one argument out of it, and
later it concatenates that empty array onto the array resulting form
another call to - $A -. The availability of a more efficient alternative
seems like a good idea, even if that alternative were only made
available internally. That alternative could be as simple as:-
simpleBind: function(obj) {
var fnc = this;
return (function() {
return fnc.apply(obj, arguments);
});
}
- and still fully satisfy all of the internal uses of bind that appear
in Prototype.js.
But it is the very fact that Prototype.js uses - bind - so much and yet
in using it never exploits its full capabilities that demonstrates that
the need for all of those capabilities is not that great. Even in code
as general as Prototype.js the ratio of common cases that don't need
'outer' arguments to cases that do is at least 28 to 1. It might be
argued that the real need is so infrequent that it should be handled
externally by the code that needs it. Or that a two stage process where
any 'outer' set of arguments is associated with one function object and
then it is that function that is passed into a much simplified - bind -
method, would provide a better interface. Something like:-
simpleBind: function(obj) {
var fnc = this;
return (function() {
return fnc.apply(obj, arguments);
});
}
complexBind:function(obj){
var fnc = this;
var args = $A(arguments);
args.shift();
return (function(){
return fnc.apply(this. args.concat($A(arguments)))
}.simpleBind(obj));
}
(untested) - where the common case enters at one point and the much less
common case enters at another. That uncommon case suffers for its
increased demands but usually, and certainly in Prototype.js's internal
use, the benefit outweighs the losses. And if a particular application
can be seen to employ the (normally) uncommon case extensively it can
employ the original process. Except that it cannot because it is in the
nature of these large-scale internally interdependent general-purpose
libraries that people using them cannot play with the APR safely
(maintenance and upgrade headaches follow form the attempt) and the
libraries themselves cannot change their external API without breaking
existing code that uses them.
So, yes 'clunky'. Certainly far short of being well-thought-out or
elegant. Indeed so far so that their only way out is to petition for a
new - bind - method in the new language versions so that faster native
code can rescue their authors from the consequences of original designs.
Which assumes that there would be a performance boost. Probably the
calling of event listeners is so fast that measuring a difference would
be difficult. But the extra function call overhead in the -
attachEvent - branch is unlikely to help in that regard.
Not just, size and the internal complexity that manifests itself in size
have consequences for understandably and so maintainability.
No, it has not yet been an issue for me. But Safari browsers expose many
'odd' properties in their DOMs so I would bet that an object inference
test could be devised even if a direct feature test could not, and the
result would still be fare superior to the UA sniffing that seems to go
on at present.
Talking (even arguing) about them is better way of testing the veracity
of ideas than not.
Matt's position has tended to be that someone else (someone other than
him) should write it.
But it is not general. The only dimension in which it is general is the
browser support dimension (though it should not be too bad in the
programmer understanding dimension). It does not even cover the general
case of wanting to find the degree to which a document has been scrolled
because it has no facility for reporting on any document other than the
one containing the SCRIPT element that contained/loaded its code. Add
support for multi-frame object models and you have something else again.
I am not drawing a line. I am expression the direction of movement that
results form a cause and effect relationship. Understanding the
relationship allows people to draw their own lines at the points which
suite their situations/contexts/applications.
Certainly if performance followed size.
In that hypothetical situation, I probably would use the code as well.
You are not seeing the question of how 'general' is "general". An event
library, no matter how large/capable is not 'general' in every sense. It
should have no element retrieve methods, no retrieval using CSS
selectors, no built-in GUI widgets, etc. It is (potentially) a task
specific component, even if it comprehensively addresses its task.
Given the number of dimension to 'general' it has not yet been
demonstrated that truly general code can be created so any "when general
code ..." statement is irrelevant. Certainly if you can get away with a
single implementation of a task-specific component then there is no need
for an alternative.
Of a component that only needs one good implementation? I doubt that, in
Aaron's code to date we have not even discussed the possibilities opened
up by having multiple frames (where normalising the event to -
window.event - is not necessarily the right thing to do). I would not
like the idea of importing a large-ish single document component into
every individual frame when a slightly larger multi frame system could
do the whole job, or of using that larger multiple frame version in a
single page application.
But the position reporting problem also demonstrates that the fact that
actual applications of javascript (web sites/applications, etc) are
specific can be exploited to facilitate problem solving. That is,
because at least some of the possible permutations of applications will
not be present in any specific application those excluded permutations
do not need to be handled by code that will never see them. It is not
just speed, there is also the possibility of getting to cut the Gordian
knot rather then untying it. There is also an advantage in the speed
with which re-useable code can be created, because you do not have to
spend time writing code for situations that you know will not apply. And
there is also a testing advantage, because excluded permutations do not
need to be tested.
It is not just optimisation. It is not solving problems that are
currently not your problems, it is not spending time writing code that
is not needed, and it is not spending time testing code that will not be
executed in the context of its use.
Richard.
