ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 22020] - [PATCH] addition of access atribute to <target..> task
Date Sat, 17 Apr 2004 20:45:06 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=22020>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=22020

[PATCH] addition of access atribute to <target..> task





------- Additional Comments From stevel@apache.org  2004-04-17 20:45 -------
Well, now that the big complexity in the access modifiers exists -<import>, what
are we going to do with access. 

Which of these three do we want:
1. the access modifiers control access from the command line
2. private targets cannot be called from <ant> calls from other build files than
(self)
3. private targets cannot be called from imported files.

(3) scares me. Big time. add that and people will want protected, maybe even
package private. And it complicates importing no end. Would it be an error to
redefine a target that was private in an import? It is in C++ after all. Would
it be allowable to depend on a private target you import? 

I am personally biased towards (1) -we just need to make explicit that
public/private only applies to command line access, not to anything else. 

Nb, assuming we say "-*" defaults to private, what is the semantics of 
<target name="-secret" access="public"> ?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message