Tuesday 18 February 2048

The hunt for the dangling Iterator (part 2)

Our quest was: how to be sure that a client code using an Iterator is calling a close code when the interaction with the implementing code is finished?
This code popped up:
public class ExitIterator<X> implements Iterator<X> {
    // if requested: create weak map SURVIVORS

    private {=> void } exit ;
    private Iterator<X> iterator ;
    private AtomicBoolean exited = new AtomicBoolean(false) ;

    public boolean hasNext(){
        boolean ok = false ;
        try {
            ok = iterator.hasNext();
        }finally {
            if( ! ok) {
                this.theEnd() ;
            }
        }
        return ok ;
    }
    
    public X next() {
        boolean ok = false ;
        X res = null ;
        try {
            res = iterator.next() ;
            ok = true ;
        }finally {
            if( ! ok) {
                this.theEnd() ;
            }
        }
        return res ;
    }
    
    public void remove() {
        iterator.remove() ;
    }
    
    private  void theEnd() {
        if( ! exited.getAndSet(true)) {
           if(exit != null) exit.invoke() ;
        }
    }
    
    public ExitIterator(Iterator<X> it,  {=> void} exitCode) {
 // should check if iterator is null !
        this.iterator = it ;
        this.exit = exitCode ;
        // SURVIVORS.put(this,exitCode);
    }

    protected void finalize() {
        this.theEnd() ;
    }
}
This code may exist in different flavours
  • "as is" if you reasonnably want the close operation to be invoked when the application is running
  • with a SURVIVORS WeakHashMap (see previous blog entry) if you want to be damn sure the close operation is invoked
  • a "belt and suspenders" option with a timeout that calls the exit code if the Iterator has not been used for a certain amount of time
Now :
  • what qualifies this code for being considered a "solution" ?
  • what can we say about the path that lead us here?

A solution ?

Well there is a moment where you'll have to stop searching for an even better solution. So what qualifies this code for being landmarked so we can deal with other problems?
I feel that it nicely fits into existing code:
  • A client code that already uses an Iterator is not to be modified: it's up to the implementing code to act
  • An implementing code that already produces an Iterator is to be only slightly modified since we need to slip an ExitIterator with proper exit code in between. So code modifications are minimal.
The code is not perfect and may need further refinements ... but this is for further versions:
  • Why is there a WeakHashMap<Iterator<?>, {=> void}> in the first place? (overkill?)
  • Could we quantify the performance penalty for using this new Iterator? (probably not that big an issue)
  • ... (please add your own critics here)
The goal of this discussion is to deal with methods: when do you think you should stop/suspend your design errands?

The path

One may wonder why I didn't come with the ExitIterator solution directly since constraints such as not meddling with client code could have been guessed in the first place!!!
Well ladies and gentlemen let me state this: almost everything is obvious .... AFTER! (the Magnus Ridolph principle)
I would even say that trying to focus on a limited set of hypothesis and reinjecting prerequisites later is stuff for an efficient search for a solution! This looks like a paradox but in practice it IS a practical behaviour
I'll have to confess: I am not a genius! I need strategies to deal with complex problems and come with palatable solutions. My experience with different design activities (remember: I have been an architect!) is that they share a similar look and feel: we start an errand on different paths and the complex solutions are the first to come. We need to be stubborn and not to stop too hastily and we need an attitude to try to distill (slowly!) new structures and solutions.... This goes through sharing (brainstorming) and structural esthetical sense (?)
Looking for a design and freezing the state of our quest is the stuff about "fuzzy" inductive design methods (as opposed to "hard" deductive methods)
More about this later ....

No comments:

About Me

My photo
to graduate at my architecture's school I wrote a thesis on "fuzzy" methods (that was in 1974). afterwards I turned software engineer (and later to java evangelist) but this just strenghtened my views on methods ... I'll try to share (though it is hard to write precisely on fuzzy topics). ...