ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evan Easton <>
Subject Re: [Bug 28444] - Import: Target Handling Bug
Date Fri, 13 May 2005 13:02:26 GMT
Anyone consider:

<target name="sometarget" depends="super.sometarget">

Nicola Ken Barozzi wrote:

> Jose Alberto Fernandez wrote:
>> Going to the old discussions in how to approach this issues,
>> the thing that bother me most, is that in order to get access
>> to an imported target I need to know the name given to the project
>> on the file that did the import.
>> This in my opinion contradicts the hidding rules of OO programming.
>> I should not need to know about the internals of an imported object.
>> It also means that I have to coordinate all the files I may directly
>> or indirectly import so that there is no project name clashes.
You could make the argument that the name isn't really an internal.  
It's just an alias to reference the project since using the filename 
might not be desirable.  Java and some other languages base the name of 
a class or module on the file or require the two to be the same.  But 
what about C++, and probably others.  You can declare whatever classes 
you want in a .h file with any name and yet you still expect the user to 
include some "file name" (e.g. <sstream>) and then use classes defined 
inside that file which may hve difference names (e.g. stringbuf, 

Some of the information defined inside the imported build file has to be 
accessible to the outside.  It seems reasonable that, just like the 
target names, macro, presets, tasks, selectors, properties, .... the 
project name could be one more piece of useful information.  You just 
now have to be careful not to rename the project if others might be 
importing your build file....just like any resource, in any 
imported/included file, is virtually any language.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message