The recent discussion about namespacing and native extensions in this
thread...
http://groups.google.com/group/prototype-core/browse_thread/thread/fd094b1301ba1f66?hl=en
... had me asking myself, "how would I build a namespaced version of
the Prototype library?
Here's my stab at an answer. As has already been noted, the challenge
is really in preserving the utility of the native extensions, so I'm
gonna limit my discussion to that aspect of things for now.
One of the first things I concluded is that having "Prototype" as the
name of the root node sucks. Nobody wants to have to type that 100
times a day. Nor is asking developers to create a local alias, ala
"var P = Prototype" or something like that, feasible. Sure, we
shouldn't do anything to prevent that, but there are some things a
library should dictate, one of which is the name of the root node that
99% of people are going to use. Thus, I would start by defining a new
root node with a short, reasonably unique name that's easy to type.
For now, let's call it "qip". (humor me.)
What's interesting about this is that it implies a new library
("Qip"?) that is distinct from Prototype, which ain't a half-bad idea:
A spinoff library that can be used by Prototype to provide it's native
API extensions, but that might also be used standalone in other
libraries. This would be consistent with the emerging trend in
javascript libs to play nice.
The design of the namespaced APIs is straight-forward: there are nodes
for qip.Array, qip.Object, qip.Function, etc., and methods hanging off
those. E.g. qip.String.endsWith() instead of String#endsWith(). I'll
assume implementation of this side of things is self-evident.
The biggest challenge lies in providing a way to optionally and
efficiently map the namespaced APIs onto native prototypes, if that's
what developers want. The problem is that the signatures have to
change because in a namespaced API there's always an explicit context
argument; an argument that has to go away and be replaced by 'this'
when assigned to a native prototype object. E.g. qip.String.endsWith
(aString, substring) has to become String#endsWith(substr).
While this method adaptation can be accomplished with
Function#methodize(), it's not practical due to the performance
problems that come from creating wrapped functions. These are core
extensions to native APIs - they need to have comparable performance,
which methodize() doesn't offer.
My proposed solution is pretty simple: it's fairly trivial to create a
modified clone of a namespaced function that can be assigned to a
prototype object. I've put together a code snippet illustrating the
technique:
http://pastie.org/425724
Obviously this is just a rough outline of how to go about doing this,
but I think it addresses the basic requirements of ease-of-use,
configurability, and performance. I'd love to hear what people think,
especially if there are requirements that I haven't thought of.
--~--~---------~--~----~------------~-------~--~----~
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
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
