My example was incorrect (well it was pure nonsense)
I would agree that your approach is more complete and
in most cases more correct. So I think it should
be implemented.
I would still like to keep the add(Type) and addConfigured(Type)
methods for container like objects. For example scriptfilter for filterchain
and tokenfilter in Ant CVS makes use of this pattern. Also it follows
the pattern of adding script defined tasks to ant, i.e.
<task type="if" ...> would be the logical consequence of your pattern.
Your pattern also makes script defined user types stand out like a sore
thumb. (this may be desirable).
In any case, the main issue of removing param(name="", value="") pattern
is removed by your approach.
On Tuesday 29 April 2003 13:52, Stefan Bodewig wrote:
> On Tue, 29 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > This is debatable
>
> I said I wasn't sure 8-)
>
> > I think we should allow both approaches.
>
> The main difference between them is that in approach 1 the child
> determines the name of the element while it is the parent who does so
> in the second approach. This makes the second approach consistent
> with existing functionality.
>
> "allow both" doesn't sound like a good idea to me, sounds like a foul
> compromise because we couldn't get to a decision ;-)
Like I said, there are different cases were one or the other is more
desirable, however your approach is more complete.
>
> > Rather than (to take a perverse example)
> > <condition>
> > <os type="outofdate">
This would not happen an addOs() takes an Os class, and outofdate
would have to extend it to be used here. So this is a valid use.
> > <targetfiles...
> > </condition>
>
> Ouch. I'd rather envision
>
> <condition>
> <condition type="outofdate" ...
>
> with a new public addCondition(Condition) method. The duplication of
> Condition is pure incidence, the one in the method name determines the
> element name, the argument the acceptable types.
If the add() pattern is not implemented, this is an acceptable alternative.
>
> > This could be stopped by having two new introspection rules:
>
> One new rule should be enough, and will be enough no matter which
> route we are going to take.
>
> > But this does mean changing public methods
>
> No way. 8-)
Very true.
We are still left the problem of the Type create<Name>() pattern.
I think we should provide default constructors to Path (and some other
classes) (Introspection will setProject() automatily on them) or allow
objects that have a Project constructor to be used in add<Name>(Type)
pattern.
And allow both create<Name>() and add<Name>() methods of javac for
example., then the scripts can be consistent.
<javac>
<sourcepath type="urlpath" ..>
</javac>
Peter.
