Dominique Devienne wrote: > Oh boy, that didn't sound like I'll be able to put a <path> inside an > <if>/<switch> any time soon, didn't it... --DD
My +1 was for "eliminate the distinction between task and type, there's no reason to not be able to put <path> inside if" And my opinion was that if you want it to happen, all you need to do is send a [PROPOSAL] to be voted by ant committers. If it gets more +1 than -1 and at least 3 +1 - then the proposal can be implemented. At least in [embed] I tried to eliminate most of the differences between task and type - so if you don't make the proposal now, I'll make it later. But the only way to move forward ( IMO ) is to have a proposal. Same thing for the javac defaults. Costin > > -----Original Message----- > From: Costin Manolache [mailto:[EMAIL PROTECTED] > Sent: Friday, November 08, 2002 1:30 PM > To: [EMAIL PROTECTED] > Subject: Re: TaskContainer and nested data-types > > Stephane Bailliez wrote: > >> ----- Original Message ----- >> From: "Stefan Bodewig" <[EMAIL PROTECTED]> >> >> [...] >>> Should data-types be allowed inside TaskContainer? >> >> I cannot see any reason why they could not. Except enforcing data types >> definition outside for style. > > +1. > > >>> If so, UnknownElement needs to get fixed. >> >> Houston, we have a problem. >> >> Recent history shows that we cannot fix something that is possibly wrong >> even though it is are plain incorrect/invalid/counterintituive. Which >> means that if someone is shooting in his foot right now she must continue >> and we must give them unlimited ammos to fulfill her action for the sake >> of backward compatibility. Amen. > > I don't agree with this. > > History shows that backward compatibility is extremely important, and > any change should take that into consideration. But we _can_ fix or > change anything. > > A majority vote can decide what happens - make a proposal, add enough > arguments - and if a majority of ant committers believe it's worth > it - then it'll be done. > > Reminder: a code change can be vetoed, and if backward compatibility is > broken I may be the first to veto ( unless I'm making the commit :-) > But if a proposal for a change is voted and gets majority vote - and > the commit just implements the group decision - I don't think a veto > can be valid ( unless it provides a different/better implementation > for what the community has decided ). > > In other words - if Stefan makes this change and committs - anyone can > veto. If a proposal is made and a majority decides this is the best > for ant - than a veto can only propose a better implementation for > what was decided. > > If a majority of ant committers don't feel it's a good idea or worth > the pain - then it shouldn't be done. > > > Costin > >> >> I don't think that myself, and I think nothing is black nor white, what >> is wrong should be fixed to avoid further problems in the future, you'd >> better catch it now than 6 months later. But this is a typical example. >> >> I know, I'm a PITA :) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
