If a feature test ends up being used in various sections (dom, event,
string..) deciding on proper placement could become a problem. I think
it's easier to keep feature tests in one place.
Prototype.BrowserFeatures doesn't seem like the right place for those
tests since both features and bugs are tested for. The content of
Prototype.BrowserFeatures is currently camelcase, that wouldn't play
well with the uppercase names.
How about not having to run every single one of those tests upfront?
If tests are defined in let's say Feature.tests they can be run only
when required instead of upfront. That would prevent running complex
tests you don't end up using.
Here's a possible implementation using some of kangax' tests:
http://gist.github.com/24895
With this approach, running a feature test would look like this and
the result will be cached for future use.
Feature.test('TREATS_ATTRIBUTES_AS_EXPANDO_PROPERTIES');
---
Nick
On 13 nov, 23:59, kangax [EMAIL PROTECTED] wrote:
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 prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options,
