Hi Stefan, Let me start by saying that the roles proposal had not in mind solving the polimorphism issue (which I think is what is at the bottom of your points here). I have no problem on arriving to a solution that covers this aspect, but I do not want it to be the stumbling block on the whole thing.
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > On Mon, 28 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote: > > > > - addComponent( MyRole ) or addMyRole( MyRole ) or both ? > > I assume you are taking MyRole as the name of the interface here, as > I'm not convinced that we need formal roles at all. > I agree with you here, the main problem I see with adding a "MyRole" name to the name of the method is that it will hardcode this name in the code of everyone. Moreover this will be a global name which will complicate any handling of 3rd party roles and implementations. I think this would be a name administration nightmare. In the antlib proposal the name of the role (or as I would like to call it the alias for the role is only to help on declarations but with respect to the code of programmers such names are irrelevant, the only thing they care is Java types. > > Let's take DependSet as an example. It has two kinds of nested > FileSets, srcfileset and destfileset. For the sake of discussion lets > assume that placing ClassFileSet or ZipFileSet for either "kind" of > FileSet was useful - I think it is at least for ZipFileSet. > > <dependset ...> > <zipfileset src="some.zip"/> > </dependset> > > with the approach you describe, > > If we follow the "name determines implementation" route you've > described here, both addSrcfileset(FileSet) and > addDestfileset(FileSet) would be candidates for methods to call. We > need a way to resolve this - probably via an extra attribute that > explicitly says "I'm a srcfileset". Something like > > <dependset ...> > <zipfileset src="some.zip" element="srcfileset"/> > </dependset> > > The alternative approach (taken by Mutant IIRC) would look like this > > <dependset> > <srcfileset src="some.zip" type="zipfileset"/> > </depenset> > > Here the approach is to look up the expected interface by the method > name. > > I feel this second approach is easier in the (rare?) cases where > things are ambiguous, but it also forces people to always explicitly > state the type. I'm not sure that the later is a drawback, though. > As I said at the begining roles where not design for doing this. There are several things we need to consider, first is whether the task uses "create" or "add[Configured]", certaintly the use of "create" will disallow we passing a different object. But if you look at ANT today you will see that in both cases we allow passing a different instance via refids (actually is upto the data-type to support this). Now if the datatype where to allow specifying something equivalent to a refid but in place, we could get the desired effect without major changes. So lets assume we add to the FileSet class a new method addConfigured(FileSet inplaceref){ // do something similar to what setRefid() does. } now we can write the above as follows: <dependset> <srcfileset> <zipfileset src="some.zip"/> </srcfileset> </depenset> which it does not look too bad, and does not need special attributes. > With this approach the parent completely determines which element > names are supported as nested elements and at the same time clearly > states which interface is expected from the child element. > > This makes documenting stuff a lot easier. Imagine the nested > elements of copy. <copy> accepts nested <fileset>s or any element > whose name maps to a class that extends > org.apache.tools.ant.types.FileSet? > > I think the learning curve for beginners to grok > > <copy ...> > <classfileset .../> > <zipfileset .../> > </copy> > This is what you would get with the current roles as long as <copy> has something like: addConfigured(Fileset fs){...} > is steeper than the alternative > > <copy ...> > <fileset type="classfileset" .../> > <fileset type="zipfileset" .../> > </copy> > > I'm not really sure myself, I've argued the first approach myself when > we discussed it the last time around (because the non-ambiguos case > requires less typing 8-) I do not like the "type" attribute, type is already use on several places like <available> an I really think the buildfiles from the first one are more easy to understand and write (once you know how to use it). It means that we would need to do a better job describing how things work genericaly and explain better the concept of generic nested elements. But we had always had this problem of explaining how nested things work. Jose Alberto
