Re: [Sooc-devel] Iterator retain/release policy

[Daniel R. <sta...@gm...>]

My initial impression was that the idea was a bit odd in that it  
causes Iterators to behave differently from other standard sooc  
objects.  Upon further reflection, it may not be that different after  
all.  I forget exactly how garbage collection works internally, but  
from the user's perspective, a non-retained object will disappear  
"unpredictably."  I use quotes since a little knowledge of the  
systemcan give you an idea of whether you really need to retain  
something.  So, in this case, you can still retain an SIter if you  
feel you need to; otherwise, it sticks around "at least" until the end  
of the loop (in fact, that's exactly what it does).  That seems fairly  
intuitive: an SIter would be quite useless if it didn't last past the  
first iteration, say.

So, to me, it does feel natural.  It definitely cleans up the code.

Regarding the C89/C99 thing, I lost you a little bit.  Will the new  
code behave properly in both implementations?

As for potential problems, I was unable to think of something other  
than what you already described.  So, let's see if I understand that  
correctly.  Suppose someone wants to use an SIter after the loop has  
completed.  Consequently, they make sure to retain it in the  
declaration.  The loop ends when s_iter_is_end() returns TRUE.   
Internally, this causes s_release(), which cancels the internal  
retain.  The retain count is now 1.  I don't know why they would do  
this, but if the programmer continues to call s_iter_is_end(), they  
could end up with I guess a segfault because eventually the object  
will disappear.  It's conceivable that this could occur because on the  
surface, s_iter_is_end() appears to simply be an informational  
accessor-like method rather than one that performs some sort of  
complex task, like releasing the iterator.  If one really needed to  
use the iterator multiple times and repeatedly check whether it is at  
the end, one would have to call s_retain() each time.

I agree with you that generally speaking, an iterator is a one-use  
object for dealing with one loop sequence.  The question may be  
whether there are any logical uses of iterators beyond the one-use  
scenario.  Also, even if there are not any logical uses, the fact  
remains that one *can* use an iterator beyond the loop.  Does the mere  
fact that an iterator may persist beyond the loop (if properly  
retained) mean this needs to be taken into account?  I'm wondering if  
this may indeed be so, simply because checking if the iterator has  
reached its end doesn't seem at first like it should be a destructive  
activity.  So it seems like it's a question of accounting for  
something somebody might actually want to do for some reason vs.  
assuming that it will never happen.

Two thoughts to add to the discussion: (1) Could this be solved  
somehow using autorelease; and (2) would it be overkill to create a  
special type of iterator (maybe SPersistentIter) for iterators that  
don't want to die?


On Jul 18, 2008, at 7:53 PM, Mike Richman wrote:

> In C++, for loops typically have the loop variable declared in the
> first part of the for().  For ordinary loops over integers and the
> like, this can be done in standard C as well -- that is, not C89, but
> in C99.  However, until now, C99 could not simplify SIter loops; the
> SIter could be declared and retained inside the loop but there is no
> straightforward way of releasing it when the loop is over.
>
> For this reason, I am tentatively changing SIter retain/release
> policy.  s_iterable_get_iter(), s_iterable_get_const_iter(), etc. will
> retain the new iterator before returning it.  Then, when
> s_iter_is_end() or s_const_iter_is_end() is called and returns TRUE,
> it will release the iterator.  A loop will go from this:
>
>
> SIter* i;
> for (i = s_retain (s_iterable_get_iter (some_list));
>     !s_iter_is_end (i); s_iter_advance (i)) {
> 	...
> }
> s_release (i);
>
>
> to this:
>
>
> for (SIter* i = s_iterable_get_iter (some_list);
>     !s_iter_is_end (i); s_iter_advance (i)) {
> 	...
> }
>
>
> Even if C99 is not available (after all, Sooc tries to assume C89 with
> few extensions), the iterator need not be retained inside or released
> outside the loop.  If you need the iterator to last, you can retain it
> and release it on your own terms.  The only time this would be awkward
> is if the iterator needs to be used even after s_iter_is_end() has
> been called and has returned TRUE.  However, in practice, this
> shouldn't be an issue -- that is, an iterator is normally a
> one-time-use device for iterating over a collection.
>
> What are some possible reasons why this may not be a good idea?  Do
> you think it is a good idea?
>
> -Mike
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Sooc-devel mailing list
> Soo...@li...
> https://lists.sourceforge.net/lists/listinfo/sooc-devel