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, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
