[EMAIL PROTECTED] wrote:
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 ?
Eh? I'm not aware that any top-level task can be run in Ant 1.5.
>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.
Sure. But I don't see how this replies to the above point...
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 ).
Good.
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.
I guess there is a misunderstanding.
I have already said this in other mails: super.super.* is really not an issue, since I just proposed it for multiple "nested" imports and is not really needed.
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,
Ignored.
or the one imported from the first import ? Which one will be 'super.super' ?
this one.
But I'm starting to think it's not needed.
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'.
Err...
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.
Well, the way you put it it's really a mess.
Just the fact that you had problems in understanding what I was trying to explain says even more.
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.
NP then, it's not needed :-)
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.
What users lament is that if they "extend" a buildfile they don't want to write
ant extendedbuild:compile
but just
ant compile
If you do compulsory rewriting of the names this is what happens...
-oOo-
What about this, based also on your suggestions:
<include file="..."> includes one buildfile in another as-is, like xml entities.
It should be able to rewrite names to prefix-targetname is specified as <include prefix="prefix-" file="...">
Then the extension:
<project name="" extends="buildfietoextend"> ... </project>
This would work as import now does, but without the multiple inheritance that is giving us problems in the definition and usage.
Multiple inheritance can thus simply be done by making a buildfile that includes many, and extending that.
When extending, targets that are redefined can call the parent target via super.
Allowing calling super.super is not something I see important at all, we can ditch that easily.
What do you think? Does this make sense?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
