Costin Manolache wrote, On 07/08/2003 4.43:
Thanks for the overview, Nicola !
Just to get you up to speed, the current issue is about multiple inheritance, and how the current system allows cross-import (unwanted?) side-effects, as Conor has brilliantly shown.
What I'm not sure I understand is what import has to do with multiple inheritance :-)
Because we can import two targets with the same name from different files. Making them work together is conceptually similar.
Most of the problems with cross-import and side effects could be resolved by
just using qualified names ( or namespaces ) - like java does to
disambiguate imports.
Really? ;-P
A brief recap of decisions taken IIUC:
- add an attribute to project: @importable=true, false, only
I hope it is not required, and if it is missing it defaults to true.
Sorry, I was not clear. Should have written:
- add an optional attribute to project: @importable=true, false, only if missing, it works as [EMAIL PROTECTED] but issues a warning (warning level to be decided)
- add possibility of prefix in import declaration <import file="xxx" prefix="xxy"/>
This would work as a "qualified name" ?
I think basically yes, but
What's the syntax for the prefixed targets/properties ?
prefix+targetname
example: prefix="a" name="b" result="ab"
Any consideration on using XML namespaces for this ?
Not in this particular discussion. They had been proposed in earlier iterations. IMO it would make sense if we fully encapsulate imported buildfiles, which is not the case with import.
- all paths are resolved resolved to the importing file basedir
The top-level importing file, or the imediate parent ?
Per transitive property, to top-level importing file.
- keep projectname.ant.file property for relative path resolutions
Good.
- add <include/> task, like entity includes - add <override-target/> task to override targets
Is this "override-target" a substitute for <extends> and OO use of ant ( i.e. a buildfile == class, target==method ) ?
In a sense yes, but not quite. Import does not fully encapsulate the calling buildfile. @see XSLT include and import for a more similar concept.
If so, wouldn't be more intuitive to just use the real concept - i.e. extends and inheritance ?
Dunno.
I know python has a very nice namespacing mechanism where you can replace
or add methods dynamically to an object, but I don't know if this is
desirable for ant.
KISS. Personally I don't need that (yet) I guess.
Threads about import (in order): 1 - ImportTask ant 1.6 2 - ant 1.5.4 : Import 3 - override
From thread 2 I wrote: " multi-import(import a,b) target test depends=a.test, b.test
a target critical target test depends=critical
b target critical target test depends=critical
Here "critical" means a.critical to a and b.critical to b, but since they reference a generic "critical", they get the only one that remains after being redefined. The problem is that I did not redefine it in the main buildfile! "
Can this be resolved by making all targets qualified after the build file is
read ?
This is what Conor seems to propose IIUC, and what others are not keen on, and instead talk more about the xslt-type import.
Just remember that we are not talking about renaming properties, or resolving basedirs, so it's not full encapsulation, but just dependency-shielding.
I have not yet made up my mind, but it seems that ATM there is a reason favor some kind of "namespacing" because I see more harm than good in side-effects that come out of not doing it. How this can still solve my usecase is yet to be seen.
That would mean ant will see:
top:
target top.test depends=a.test, b.test
a target a.critical target a.test depdends a.critical
b
target b.critical target b.test depends=b.critical
After reading any build.xml file, ant will just look at all targets and add the project name as a prefix if they don't have one already ( we just
need to agree on the separator syntax ).
Or simply use the proposed prefix when importing.
When you look at a build.xml, all targets that don't have prefix are
resolved to the current build file - it's pretty easy to understand.
That mean you won't be able to use import for crazy overrding of some targets from one file with targets from other file - but if there is a
real need for that i have no problem with a python-like mechanism where you can add/replace methods in an object at runtime. As long as it's not disguised as <import> :-)
Well, IMHO I personally don't see a real, strong, compelling reason to have targets have crosstalk between themselves, but I do have an equally strong need to import dependencies.
As I have outlined before, imagine I import a file that has a compile and test targets.
target compile target test depends=compile
I want to be able to do "ant compile" and have it compile. Thus the compile target should not be renamed.
Then when I want to insert a pre-condition to the compile target, I want to be able to redefine the compile target.
Reusing it in a differently-renamed target is not ok, as when I call "test", it will not have a dependency to the new version of the target.
So target compile target newcompile (call:prestuff, compile, poststuff) target test depends=compile
If I call newcompile, it works but calling test will not call the new one, thus making it impossible for me to *decorate* the compile target, thus specializing the template.
So I should have: target compile -> original compile override-target compile (call:prestuff, original.compile, poststuff) target test depends=compile
Till I import *one* compile target instance, all is well. As soon as I have more of them, I start having problems.
The question is: after a multiple import, which compile target becomes the "default" one, ie the one without renaming?
Second question: how do we deal with the fact that targets that are not even used have crosstalk between themselves?
And most of all: how to solve the last two points while keeping it possible for me to retain the use-cases?
As you see, for this usecase, <include> is not strong enough, as I cannot override, and complete namespacing prevents me from overriding the dependency chain.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
------------------------------------------------------------------------------------------------------------------------------------------ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
