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 :-)
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.
> 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.
> - add possibility of prefix in import declaration
> <import file="xxx" prefix="xxy"/>
This would work as a "qualified name" ? What's the syntax for the
prefixed targets/properties ? Any consideration on using XML namespaces
for this ?
> - all paths are resolved resolved to the importing file basedir
The top-level importing file, or the imediate parent ?
> - 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 ) ?
If so, wouldn't be more intuitive to just use the real concept - i.e.
extends and inheritance ?
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.
> 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 ?
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 ).
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> :-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
