> From: Peter Donald [mailto:[EMAIL PROTECTED] > > > > OK, I finally took a quick look at some of the interfaces of > Myrmidon and > > here is a more concrete proposal. So what I am saying is to allow Tasks > > to provide their own ObjectConfigurer to use by the DefaultConfigurer. > > > > Instead of passing the configuration to the object if the Task > implements > > Configurable, what you do is ask the Task to provide an ObjectConfigurer > > if the Task defines DynamiclyConfigurable (for example): > > > > interface DynamiclyConfigurable { > > ObjectConfigurer getConfigurer(); > > } > > > > For what I see of the the definition of ObjectConfigurable is should be > > quite easy for an object to define its own methods, and if we > provide a few > > predefined helper classes, the whole affair could be even more trivial. > > I don't see how this is any better or worse than what is already there ? > Whats to stop a programmer doing evil things with this? Why is this any > inherently better than the way it is currently done? >
It becomes better once you start adding meta-info discovery methods to ObjectConfigurer (and rename it TypeInfo, say). I'm not a big fan of Configurable, for two reasons: It's an all-or-nothing approach, where the object has to do all the work. Granted, there are helpers, but the object is responsible for doing the work. I think in almost every case, the task doesn't want to use a completely non-standard scheme for configuring itself. Instead the task simply wants to change how a particular element or attribute is handled, and use the standard scheme for everything else. The other reason is that Configurable is totally opaque. You lose meta-info about the object, and so can't do things like configure it in a GUI, or generate doco for it. Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
