[Mono-list] Re: IEnumerators

[Garrett Rooney]

On Tue, Jul 17, 2001 at 12:19:49PM +0400, Serge wrote:
> Hello there,
> 
> > The best way I can think of
> > is to have the original object
> > keep a change count.
> 
> Exactly, this is how it's implemented in Java, and I really believe it's
> done like this in MS implementation. This is so-called "fail-fast
> iterators". You may check my implementation of Hashtable for example of
> this, which is available still at http://primates.ximian.com/~miguel/tmp/
> 
> Also regarding Garrett's Stack implemetation. I think that the Stack's
> Enumerator should be implemented this way too.
> Garrett, currently you're making the clone of the base stack array. I think
> it's a kind of overkill - making the copy to just look at the content. I
> believe when specs are talking about snapshots, they actually mean the
> version-stamped references, not copys.

I will change this for the next version of Stack I submit.  I already have a
fair number of changes from comments recieved yesterday.

> Also, I see no reason why synched collection should return synched
> enumerator. Maybe I missed some point though. Also, if we assume that we
> won't make copys of the content for each Enumerator, and Enumerators are
> fail-fast, there is no point to synchronize Enumerator on itself (lock
> (this)). Since Enumerators are read-only, this will only add unneeded
> overhead.
> On the other hand, to provide thread safety for Enumerator, it is imperative
> that the client code synchronize iteration loop with the corresponding
> _synchorized_ collection returned by Collection.Synchronized(Collection)
> method. That is, you obtaining synched collection, then its Enumerator, then
> the use of the Enumerator is synchronized on that collection.

That's what it's doing (IIRC, I don't have source in front of me right now).
If you call GetEnumerator() on a SyncStack instance, it's returning an
Enumerator that is synchronized (on itself at the moment i think, but when I
change it to use a reference to the stack, it'll synchronize on the stack).

> Well, re-reading my explanation, I think it's quite unclear :-) Hence,
> better refer to the source code. Also looking at JDK docs will help, they
> have very detailed description of this, arguably better than that from the
> specs/Beta2 docs, notably the terminology there is less confusing.
> 
> Also, I think, there ought to be the sort of "skeleton" for all collections
> classes, because they share a great deal of functionality and behaviour,
> Enumerators for example. Not necessary some code snippet but a set of rules,
> like these for Enumerators and corresponding tests-cases to check the
> implementation. Any ideas?

I think this will be less of a problem when there are more Collections classes
in the repository to use as a reference, but having a list of guidelines would
still be helpful.  At the very least we should be sure all the classes that
are there are consistent.

-- 
garrett rooney                     Unix was not designed to stop you from 
rooneg@electricjellyfish.net       doing stupid things, because that would  
http://electricjellyfish.net/      stop you from doing clever things.