On Mon, Sep 02, 2002 at 01:33:45PM +0200, Aldo Calpini wrote: > INTVAL iterator_sizeof() > void iterator_reset() > void iterator_set(void *data) > void iterator_get(void *data) > PMC* iterator_get_current() > void iterator_next();
What is the advantage of having the aggregate ever hold onto the iteration state? What do you think of the following interface: INTVAL iterator_sizeof() void iterator_reset(void *data) PMC* iterator_get_current(void *data) void iterator_next(void *data); int iterator_has_next(void *data); In other words, state allocation happens the same way you have it now, but the aggregate never holds onto any state between calls; it is always passed in the state object when it needs to do anything. This would remove any thread-related headaches, and just seems safer in general (less potential for bugs resulting from calling the API functions in the wrong order.) But perhaps I'm missing some advantage in having the aggregate hold onto the state? Also, with garbage collection it seems safe to have the aggregate return its own state object rather than having the Iterator do the allocation. The Iterator wouldn't even need to know how big the object was. When the owning Iterator got collected, it would just pass the pointer to mem_sys_free(). (In other words, the memory allocation system already maintains metadata like the size of allocations; why duplicate it?)
