> On the other hand, if we have a common property for accessing "origin"
> of both `Node` and `NodeList` wrappers, shouldn't it be of the same
> type?

I don't see any reason it does, no.  My reason for suggesting a
unified term was mostly for the convenience of users of the API, not
primarily so the same code could be used on multiple wrappers.  E.g.,
so users don't have to remember that to get the underlying Element
from a WrappedElement it's "wrapper.element" but to get the underlying
Event from a WrappedEvent it's "wrapper.event" and to get the
underlying NodeList from a WrappedNodeList it's
"wrapper.nodeList" (not "wrapper.list" or "wrapper.nodelist" -- you
see where I'm going with this).  Instead, if you have a wrapper, you
know you can get at the raw object via the ".raw" property regardless
of what kind of wrapper it is.  Sure, people _can_ remember the
various properties, I'm just saying it's easier to remember one.

Separately, my reason for suggesting something short is that we'll use
it a *lot*, so it should be short as reasonably possible.
--
T.J. Crowder
tj / crowder software / com

On Aug 19, 3:56 pm, kangax <[EMAIL PROTECTED]> wrote:
> On Aug 19, 2:34 am, "T.J. Crowder" <[EMAIL PROTECTED]> wrote:
>
>
>
> > > > var el = new Prototype.Element(element);
> > > > el.raw, or el.obj, or el.wrapped, or el.source.
> > > > I kinda dig el.source
>
> > > `source` sounds good.
>
> > It's not very important, but I can't say "source" appeals.  I think it
> > will be confusing in discussion.  The underlying element is as much a
> > target as a source, and source is already an overloaded word.  When
> > you call item.update(), the target (not source) of the update is the
> > underlying element.  In terms of it being overloaded, suppose you have
> > a container element and you use select() to get an 'item' element from
> > somewhere within it.  At that point, it's easy (but wrong) to read
> > "item.source" as meaning the container, since you got the item "from"
> > the container.
>
> > "raw" has grown on me.  It's not overloaded, and it's pretty clear in
> > conversation: "Q. How do I get the tag name of a wrapped element?   A.
> > From the raw element it's wrapping.  Q. How do I get the real nodelist
> > from a wrapper?  A. Use the 'raw' property to get the raw nodelist."
> > It's also short (we'll be using this a lot).  The biggest negative I
> > see to it is that it's typed entirely with the left hand (if you're a
> > touch typist).
>
> I was thinking of `node`/`nodeList` or `element`/`elements` but those
> wouldn't make for a unified interface. `raw`, `source` and `target`
> all sound intuitive, imo, though `row` seems a little weird : )
> On the other hand, if we have a common property for accessing "origin"
> of both `Node` and `NodeList` wrappers, shouldn't it be of the same
> type? Having same-named property, and not knowing (easily) what it is,
> doesn't seem convenient:
>
> function doStuff(wrapper){
>   // exit if not a wrapper
>   if (!wrapper || (wrapper && !wrapper.raw)) return;
>   // we can try `length` to make sure it's a NodeList, but what if
> some DOMElement exposes length property?
>   if (wrapper.raw.length) {
>     // do something with the entire collection
>   } else { // assume it's a Node
>     // do something with it
>   }
>
> };
>
> vs:
>
> function doStuff(wrapper) {
>   if (!wrapper) return;
>   if (wrapper.__node) {
>     // definitely a Node - `__node` property is present and is not
> falsy
>   } else if (wrapper.__nodeList) {
>     // definitely a NodeList - `__nodeList` property is present and is
> not falsy
>   }
>   // ignore anything else
>
> }
>
> Thoughts?
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to