DO NOT REPLY [Bug 7975] - Iterator warnings sometimes inappropriate

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7975>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7975

Iterator warnings sometimes inappropriate

geirm@optonline.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From geirm@optonline.net  2002-04-11 18:15 -------
Well...

Velocity will introspect the common iterative collections to find an iterator.  

i.e. if $list is a java.util.List

#foreach($item in $list)

works just fine.

It squawks a warning when it just has an iterator given to it, as it doesn't 
really know if you are doing something like

#foreach($item in $list.iterator())

which is cool, or if you did 

  context.put("iter", myList.iterator() );

in your code and thus 

#foreach($item in $iter)
  ...
#end

#foreach($item in $iter)
...
#end

will lead to problems that will be very unexpected for the designer and 
maybe the programmer.

So since Velocity' can't easily figure it out, it squawks. To me, it seems like 
the tradeoff of a little squawking for people who don't let Velocity figure it 
out (as they should :) is better than the complexity of analyzing if the 
iterator that it gets comes from a safe source.  Quite frankly, I can't tell if 
the example you gave is safe because I don't know the semantics of the 
method that returns the iterator.  For a list instanceof j.u.List, for example,  
I do because of the contract with j.u.List.


I am marking this as 'resolved - invalid'.  Sorry for the apparent rudeness 
of the 'invalid' reason, but it's the only one that vaguely applies in the list 
we have to choose from...

If you disagree with the reason, feel free to reopen.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>