Gabe said: > I am not trying to create a generic tool management BUT generic tools! You > think too far. All I propose are some minor changes to (hopefully) allow > widest possible reuse of tools and make sure that tool handling is safe > and efficient.
it's already very easy to create a generic tool! just write a class with a public default constructor. if you haven't been talking about making tool management more generic, then i'm very confused. (and in my experience, that's a distinct possibility :-) > In addition I want to get the naming right so that working > with tools is intuitive. +1 > In your current proposal you have a contract between tool classes and the > toolbox manager that is defined in the documentation. I'd like to define > this as part of a Java interface because this allows checks that everything > is well and right i'd rather not hard-code this stuff into an interface. at least not any more than i already did in my submitted code. i really don't think that's necessary, and i strongly dislike hard-coding things that aren't necessary. > (You have some checks in your proposal but there are still > situations where things can go wrong. Ugly things can happen if a tool ends > up in the wrong scope. It will load and work nicely but return wrong > results because it operates on old data). yep. that's the way it goes. if they do something wrong, then things break. > Implemenation-wise it's a minor > change to what you propose. I'll write that code and then we can go from > there. ok. i look forward to seeing it! Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
