Hiya,

> > 2. FWIW, it seems to me that calling an accessor on a list should
> > return a list of the accessor results for each list element.  Always.
...
>
> This is tricky : )
> On one hand, having accessor act on all elements seems most intuitive
> and consistent with the current API. On the other hand, I can clearly
> see a case when getting "first value" is much more convenient.
> Considering that NodeList items can not be accessed via brackets,
> wouldn't we end up with a somewhat verbose syntax?
>
> $$('#sidebar #expandAll')[0].observe('click', function(){});
>
> becomes:
>
> $W('#sidebar #expandAll').source[0].observe('click', function(){});

Maybe I'm not understanding the example; I'm not a CSS guru by any
means.  To me that looks like you're selecting an element with the ID
'expandAll' if and only if it exists within an element with the ID
'sidebar'.  If so, that seems like quite an edge case to me (wouldn't
you know whether it was inside the sidebar?), but again, I think I
probably just don't get it.

> Perhaps, if we give NodeList a `first` method, it will make things a
> little less cryptic:

That sounds good.  But separately, if we think it's common to need to
select a single element on the basis of a CSS selector, I'd suggest an
explicit means of doing that (e.g., a separate function -- $$First()
comes to mind) that returns a NodeWrapper (or undefined, of course)
and is optimized for that operation -- specifically, it stops as soon
as it's found one.  More readable, perhaps slightly faster.

> > 3. Still don't like "source".  That word is just way too overloaded,
...
>
> I really like `source` but let's keep the naming aside for now : )

No problem.  But you know I'll come back to it. :-)

> > 4. get() and set() methods:  Great to have them, but I think it's
> > important that we not expect/require that people _use_ them.
...
> Sure. We should recommend using them wisely and whenever it makes
> sense.

Good good, just checking.

> > 5. How will the list wrapper handle indexing into the list?  E.g.:
>
> >     var items;
> >     var n;
> >     items = $$('div.item');
> >     for (n = 0; n < items.length; ++n)
> >     {
> >         items[n].update('This is item ' + n);
> >     }
...
>
> "each" always passes index as a second argument to iterator function:

I don't use each() unless I have a really good reason for the added
overhead or I know I'm dealing with so few elements that the added
overhead (dramatic, in IE's case) doesn't matter.  I don't want people
to think I'm dissing each() and I don't want to start an each()
conversation.  But it seems like people get so caught up in the
coolness of this stuff they they forget that function calls have a
cost, inline closures have an even higher cost.  each() is really cool
and I love it, love the idea of it, love the expressiveness of it.
And implementations are making progress.  But for now my default mode
will continue to be boring old-fashioned for/next loops (backward if
it doesn't matter and time is *really* of the essence) barring a
strong reason to do something else.

> > 6. Question on $$():  I think the idea so far is that it returns a
> > NodeListWrapper.  I'm guessing that that's a list of NodeWrappers
> > around the results of the query, right?
...
> Yep, `source` of NodeList is an array of `Node`s.

Nodes?  Or NodeWrappers?
--
T.J. Crowder
tj / crowder software / com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to