I still like it. It solves big problems like mine -> loads of data. It can
save a lot of resources.
Look:
1 - The programmer implementing the Iterator and placing it in the Context,
MUST know what an Iterator is. And he can implement a reset method
usable in the template anyway - it will still be an Iterator
implementation. What you point out is an Application issue, not a
library one;
=:o)
2 - It is _major_ pain to implement a Map or a Collection, but so easy to
implement an Iterator;
3 - Some Iterators (like over some performant forward only ResultSets)
naturally can not be reset. They are still damn useful.
Maybe I really need plugable introspection.
=:o)
Have fun,
Paulo
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Geir Magnusson Jr.
>
> Paulo Gaspar wrote:
>
> > Yes, you get Iterator's from object arrays, Collection's and Map's ...
> > ...but what happens if the object to iterate trough in the #foreach is
> > _already_ an Iterator???
>
> Thinking about this, allowing an Iterator will lead to trouble -
>
> code (vec is a Vector) :
>
> context.put("iterator", vec.iterator() );
>
> template :
>
> #foreach($i in $iterator)
> $i
> #end
>
> #foreach($j in $iterator)
> $j
> #end
>
>
> Will result in a surprise... there's no way to 'reset' the Iterator, so
> the second foreach loop wouldn't output anything.
>
> This is a problem.
>
> I think we shouldn't allow using Iterator's directly in the context, as
> this will simply lead to trouble - no matter how well documented, this
> kind of statefulness w.o. the ability to reset will lead to problems for
> people.
>
> I can put a message in the log if we come across an Iterator with a
> warning, because it *is* sort of a natural thing to do, but we should
> probably try to dissuade people from using this.
>
> Comments, anyone?
>
> geir
>
