commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: [collections] [VOTE] Bug 33190...
Date Thu, 24 Mar 2005 14:16:26 GMT
Ok, then I'm a +0.  I wouldn't want to veto it.  I guess I should read up on
the voting rules.  I didn't realize that a -1 was so powerful.  Then again,
I'm not an official committer yet, so my vote doesn't count anyway. :-)

Could we try to come up with a more valid use case, then?  I don't see
including something if we can't even fathom a reasonable use case for it.
Off the top of my head, I can't think of a use for this technique.  That
doesn't mean there isn't one.  Maybe I've just never encountered a situation
where it would apply.  It seems quite dangerous, though, to rely upon the
exhaustion of an iterator to release or clean up resources.  What happens if
an exception is thrown while iterating?  The Closure will never be called.

James

-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
Sent: Thursday, March 24, 2005 9:04 AM
To: Jakarta Commons Developers List
Subject: Re: [collections] [VOTE] Bug 33190...


--- James Carman <james@carmanconsulting.com> wrote:
> Could we come to some consensus on this item in
> Bugzilla?  I have already
> put my $0.02 in as a comment.  But, this one is
> somewhat easy either way we
> go with it.  If the decision is to not include it,
> then that's a no-brainer.
> If we decide to include it, then it's not much
> effort to do that either.
> But, a decision has to be made.  I'm -1 on including
> it, as I don't think
> it's a valid approach or all that common.

Actually, I think it could be useful as a technique,
if we put out of our minds the validness of the given
use case.

If we did include it, it would essentially be a
CallClosureWhenCompleteIterator.

So, I'm +0.5. However on coding matters, any -1 is a
veto, so it won't happen if you -1.

Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message