1. the recent bugrep was about IDE visibility, not true public/private
2. I think the <import> mechanism will soon raise needs about scoping, but dont want to rush into doing something for 1.6 that has to be retained.
Gus Heck wrote:
In fact I would be even more interested to hear the opinons of both commiters and non-commiters :).
-Gus
Gus Heck wrote:
Antoine Levy-Lambert wrote:
What you would like would be useful to prevent the "wrong" targets fromThe default (atribute omitted) state should behave as always. This is necessary for back compatability, and to keep the learning curve from getting too steep. The import task gives me the same sort of worry about complexity, but I keep reiminding myself... You don't have to use it if you don't want it ;). So at least from the user side, there is no obligatory complexity increase. The addition of another atribute in the documentation for target would be the only brain drain :)...
being called. But I wonder whether this change would not make ant
unnecessary complex.
As for the development side, it may lead to increased complexity if we add access modifiers with more complex meanings. As it is now, however the only meaning of public/private is "do we reject it when invoked from the command line" and the only time we need to check that is already included in the patch.
I too would be interested to hear what other commiters think.
- Gus
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
