Stephane Bailliez wrote:
>> > I cannot see any reason why they could not. Except enforcing data types >> > definition outside for style. >> >> +1. > > > For what is your +1 here ? > I was understanding in your previous mail that you wanted data types to be > possible in the container. Is that correct or should I take fresh air and > reread your mail ? It is correct. I would like the distinction between data types and tasks to be removed. > [...] >> If a majority of ant committers don't feel it's a good idea or worth >> the pain - then it shouldn't be done. > > It's not the problem. > I agree we can spend our time vetoing and see them flying around but this > is the way I see things. I'd rather let people move on. I'm just pointing > out that raising 'backward compatibility' flag only when it suits is no > good. "Backward compatibility" is one important issue to consider - but not the only one. In this case - I don't think anyone would be affected. For javac default debugging - I think the benefits of changing the default justifies the backward incompatibility. In all cases - a PROPOSAL is the best way to move forward. Not sure how the 'veto' is related with this discussion - a proposal is not a code change, so a vote against is not a veto. > I would like you to explain me how you could possibly take the > responsability of enforcing data types 'outside' the container knowing > that it would break build files and at the same time not agreeing to > change the javac debug flag back to normal ? > ok, this is a bad example for you since you agree on both sides but I > think you get the idea. :) I don't get the idea, sorry. My point is that for any change that is important enough ( and breaking backward compat is important, as well as changing the build.xml semantics ) it is best to have a formal proposal and a majority vote first. It's not a waste of time. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
