Fwd: [dojo-contributors] [feedback wanted] Preferred Iteration forms

Tom Trenka ttrenka at gmail.com
Wed Apr 12 13:44:20 EDT 2006


I hate to resurrect this, but...

Aside from "iterator wars", this is what I'm going to go with:

var it=col.getIterator();

while(!it.atEnd()){
    var item=it.current();
    // do stuff
}

The idea here is that current() not only returns the current item, but also
advances the internal cursor to the next item in the collection.  atEnd()
should be obvious. I will also provide an "item" property, which will be the
current item in the collection. Hopefully this is the best comprimise I can
think of.  It should also be able to support a for form...

for(it.current();!it.atEnd(); it.current()){
   // do stuff.
}

(still thinking about that one but it should work as long as the initializer
is called)

...and I will try to write it so that calling current() past the end of the
collection returns null, so the do...while form should work as well:

do{
   // something
} while (it.current())

(only issue with this form is that there has to be something in the
collection for it to work, but internally you will be able to test if item
== null).

Would that cover all the bases?  If I have time, I might try to add
functional iteration to the iterators as well, but that's low on the
priority list (fix the imperative first, then look at the functional).
Also, does anyone see any holes with this?  I haven't coded anything yet
(slamming on a project right now) but I thought I would throw this out in
time for the meeting (without getting into another holy war).

trt

On 4/4/06, Alex Russell <alex at dojotoolkit.org> wrote:
>
> On Tuesday 04 April 2006 7:03 am, Tom Trenka wrote:
> > > But since there are a number of people that seem to want the
> > > functional iteration, don't be too surprised if someone adds that
> > > into the collections code (at some point in the future).
> >
> > As administrative "owner" of that code, I *might* consider pulling
> > any addition like that out.  If it saved even 4 to 5 lines of code on
> > the part of the owner, that'd be one story.  But to add something
> > like that (either duplicating or including the dependency) is a bit
> > ridiculous when you can do it, on your own, in one to two lines of
> > code yourself.
> >
> > You might think everyone wants the functional iterator, but I'd
> > submit to you the majority of the people who would use the
> > Collections code over working with an array directly will prefer the
> > imperative, because that's what they know--which translates directly
> > to shorter dev time.
>
> Bogus. If that was a workable argument our code would all look like C#
> or Java. I, for one, thank my chosen diety that it doesn't.
>
> > Yes, its a cool feature.  But it's just as easy for you to do it in
> > your app as it is for me to create the dependency.
>
> Didn't we go through this? Just add an iteratorInstance.forEach() method
> w/ the same signature as the dojo.lang.forEach() (sans iterated
> object). I'm seriously cofounded why we're still having this
> discussion.
>
> It's not that much code and it keeps us out of non-dynamic language
> hell. Add it, please, so that we can be done with this discussion.
>
> Regards
>
> --
> Alex Russell
> alex at jot.com
> alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
>
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060412/ff63c871/attachment.htm 


More information about the dojo-contributors mailing list