> You mean "return function someNamed() { ... }", right? That's fine by the
> specs
Love it.
> Let's not prematurely optimize.
My proposal isn't just an optimization but a different approach for
the more complex tests used throughout the library. You asked for
feedback on how to handle feature testing, I think we could do better
then simply wrapping everything in closures. Here's what is comes down
to:
// complex test upfront in 'foo' closure.
var foo = (function(){
var REUSED_COMPLEX_FEATURETEST = (function(){
// ...
})();
if (test == simple) {
return function simpleWorkaround() {
// ..
};
}
if (REUSED_COMPLEX_FEATURETEST) {
return function complexWorkaround() {
// ..
};
}
//..
})();
Compared to Feature proposal:
// Reused complex test outside 'foo' closure.
var foo = (function() {
if (test == simple) {
return function simpleWorkaround() {
// ..
};
}
if (Feature.test('REUSED_COMPLEX_FEATURETEST')) {
return function complexWorkaround() {
// ..
};
}
// ..
})();
The optimizations are just an added bonus.
> I actually don't think these should be made public.
What's the harm there? Like with Prototype.BrowserFeatures it would
only make things easier internally.
It seems like you favour placing everything inside the different
closures as in my first example. What about complex tests used in more
then one place (dom, selector, array, etc.)?
A namespace like Feature could solve that issue. Perhaps it's not even
an issue right now though but having complex feature tests in one
place with documentation seems more maintainable in the long run.
--
Nick
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
