On Nov 13, 2:25 pm, Andrew Dupont <[EMAIL PROTECTED]> wrote:
> Here's what this would look like when genericized into an imaginary
> API:http://gist.github.com/24571
>
> A couple of things:
>
> (1) I'm altogether in favor of this new approach, but it will result
> in less "implicit" organization of code. A reader of the code will
> likely find it harder to scan for the specific method they're looking
> for. We'll probably have to address this by marking code "sections"
> with comments.
I would be in favor of having every non-trivial method declaration in
a separate "wrapper" function. This would make it easier to
distinguish methods and keep all the implementation details in one
scope (avoiding accidental name clashes, etc.). In other words, keep
only one method declaration (together with all the supplementary tests/
methods) in one anonymous function. If we do that, it also becomes
possible to get rid of `Object.extend` and a returning object:
NativeObject.prototype.method = (function(){
var isBugPresent = (function(){
// feature test something...
})();
function original(){};
function workaround(){};
if (isBugPresent) {
return workaround;
}
return original;
})();
On the other hand, there are so many possibilities here that I think
we should do what makes more sense. E.g. if two methods need to use
one helper function or one test, they should probably be combined
under one "wrapper":
(function(){
var isBuggy = (function(){
// ...
})();
function originalEscape(){};
function originalUnescape(){};
function workaroundEscape(){};
function workaroundUnescape(){};
if (isBuggy) {
String.prototype.escapeHTML = workaroundEscape;
String.prototype.unescapeHTML = workaroundUnescape;
}
// ...
})();
My only concern about this pattern is memory usage. There are many
functions created during branching process, yet only one is returned/
assigned (and is then used throughout the rest of the application
life). Those alternative functions are stored in a closure (e.g. in a
closure of "final" function) and so consume memory; every method has a
burden of its "branching environment" (memory-wise). This wouldn't
happen if we were to use function expressions (rather than function
declarations), but then our methods wouldn't have identifiers:
var someMethod = (function(){
if (doTest()) {
return function(){
// original function
}
}
else return function(){
// alternative version
}
})();
I've never found this to be a problem (i.e. lack of function "names")
but Tobie says that having those is useful for debugging. I'm still
not sure if such clarity/convenience worth memory loss. Perhaps this
"loss" is a non-issue and I'm just being overly paranoid : ) I
definitely like how clean and maintainable such pattern looks, though.
[snip PDoc section]
>
> (3) Simple capability/quirk checks, as in the String#escapeHTML
> example, can go directly into the conditional. More complex checks,
> like the kind kangax has been working on, will need to be wrapped in
> anonymous functions and distilled into booleans. I'd prefer these
> booleans to have the naming conventions of constants (e.g.,
> TREATS_ATTRIBUTES_AS_EXPANDO_PROPERTIES) so that they can be
> recognized easily in the code.
Agreed about capital names. I'm not sure where we should keep feature
tests, though. On one hand, it makes sense to keep them all under
`Prototype.BrowserFeatures`. On the other - it might be a bit
disturbing not to see the actual test implementation in the
appropriate method declaration (where all the branching occurs).
>
> Cheers,
> Andrew
[...]
--
kangax
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
