At 01:06 11/12/00 -0600, [EMAIL PROTECTED] wrote: > >doh! I'd reimplemented the xml parsing to try out a few new things and >hadn't notice that the original source handled this now... > >FWIW, one of the other things I was trying out was a more java-beanish way >of handling child elements. In particular, I tried using indexed properties >instead of the createFoo methods. For example, the current version of >MatchingTask has a method: > >PatternSet createPatternSet() > >which is how you have to do things when you're creating the tasks as you >parse the xml. But it you're creating the task later, you can have a method >like: > >void setPatternSet(PatternSet[] patterns) > >which would make the task class more usable in other tools, since it >follows the javabean spec. Do most people agree that this is the way to go?
That way is fine but I don't like the idea of task developers having to implement the "setPatternSet( int index, PatternSet patternSet );" - too much uneeded complexity. However there are some cases where even this wouldn't work. In many of current tasks the tasks have to be responsible for creating the object. (they may need to pass in parameters to constructor). While this could be fixed it would require a considerable effort (Thou I think it may be worth it ?). Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
