Here's what this would look like when genericized into an imaginary
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"
(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
(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.
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
> > I investigated a bit more re the typos you mentioned. It happens to be
> > an issue with gist which... escaped some of the strings.
> 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.
> -- 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@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at