[Mono-list] Re: IEnumerators

Garrett Rooney rooneg@electricjellyfish.net
Tue, 17 Jul 2001 07:51:39 -0400

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.