Here is my take, I'm also altogether with this incoming pattern. PDoc blocks could indeed demarcate those sections, and be used to provide (browser|feature)-specific technical documentation. My proposal is the following (http://gist.github.com/25421), where by method appear : - classical implementation, with "real" name. - alternative implementations (with meaningful suffixes: "UsingThis", "FixingThat") - complex tests in named functions, suffixed by "ShouldUseThis", "ShouldFixThat" as convention ? - branching, i.e. replacing function referenced by final name, depending on the return value of complex tests and inline trivial tests. It also shows an imaginary "implementation of:" PDoc tag.
About "complex shared tests", what are actual real cases ? Are such tests shared among parts (say files in rewrite branch) or pretty much isolated ? A solution might be to declare all common tests first, not really consistent with my previous proposition though... Another interresting point is usage of "early or late binding" when calling methods from other methods within the same closure (i.e. http://gist.github.com/25430) Early binding makes Prototype methods sort of frozen, but it looses some dynamism. Another better example is Enumerable, when all methods are written in term of `each` or an higher-level iterator. Should we write `this.each(...)` in `collect` code, or `each.call (this, ...)` ? `_each` being the only method that really has to be late-bound. Best, Samuel Lebeau On 13 nov, 20:25, 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. > > (2) Also, it now becomes less clear where a PDoc block would go. > Technically, it would go at the bottom, where the external API is > created, but that'd separate it from the "logic" of the function and > would therefore make it more likely for the code and the docs to get > out of sync. > > (Perhaps PDoc blocks can be used to demarcate, thereby solving both of > these problems.) > > (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. > > Cheers, > Andrew > > On Nov 13, 6:28 am, "T.J. Crowder" <[EMAIL PROTECTED]> wrote: > > > Hi Tobie, > > > > I'm actually interested in the pattern, not in the actual code. > > > Yeah, just wanted to make sure we were looking at the right code > > first. > > > > I investigated a bit more re the typos you mentioned. It happens to be > > > an issue with gist which... escaped some of the strings. > > > Lovely. > > > So stating the obvious: The basics are: > > > 1. Use named functions for each variant. > > > 2. Define the functions up front. > > > 3. Test proactive, in an appropriate order, and use the first one that > > works correctly. > > > Right? > > > -- T.J. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
