On Sat, 20 Jul 2002, Nicola Ken Barozzi wrote: > I said "deprecate", not "remove".
And why do you think 'deprecating' something that many people like and use is ok ? > > I see no problem with adding a 'destroy' tag - as new functionality. > > Good :-) > > > For 'init' - there is already a way to do what you want. > > In 1.5? I can run *any* top-level task? As I repeted several times, all I'm doing at the moment will work with 1.5 if you install ant-sax2.jar in lib. I'll be proposed for ant1.6 and the main branch - but I want to be able to use it and to get feedback from users - and not many people are using the main branch. BTW, your 'destroy' and 'init' will be reasonably easy to add ( as 'special' tasks like import, implementing TaskContainer and using a hook to detect the end ). > > I'm more confused here - extend and import are very different > > things. I don't mind an 'extend' ( especially if you can extend > > only one class ), but for 'import' you may have multiple > > imports - and most people would be confused if import would > > behave as extend ( I am ). > > Well, XSL works like this. > With import, you don't extend a project, but override targets/templates. > In Java you cannot without extending the class, please look at the XSL > spec for <include> and <import> to understand what I mean. I did - in XSL the 'main' class, doing the import/include, has priority. If you have multiple imports you can call the overriden targets - but calling them super.super.super with the number of super depending on how many imports were made before is inpractical. > >>But the imported file can import and override the same target from a > >>third file... > > > > And you can import 2 files defining the same target. > > > > Which will be 'super' in this case ? > > The firt one, as per XSL spec on imports. And what about the second import, or the one imported from the first import ? Which one will be 'super.super' ? Using XSLT as guide, it'll be the one imported from the first import, and the second import from main will be 'super.super.super'. If the first imported build will change and no longer has an import - then the second import from main will become super.super. Doesn't seem very clean. My proposal was IMHO simpler: use the project name to qualify. > > Mixing 'import' with 'extend' is very dangerous. > > ? > XSL spec, that's what I follow. That doesn't mention 'super' and is not using and 'extend' semantic. It's the 'super.super' naming I have a problem with. > Say I have a master buildfile, that does all I need, *except* that I > want to add a task at the end of a target it uses. > I need "extend", or rewrite all targets that call the imported ones, > which is a PITA. What I'm proposing is allowing you do do that, except that instead of using super. constructs you need to call the target using the name of the master buildfile . target. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
