On Tue, 27 Nov 2001 12:41, Erik Hatcher wrote: > I really was thinking that if <available> was checking for something, that > it should have the final say on whether the property gets set or unset - > and I still "almost" think that.
Thats like saying if you have <property/> task it should have the final say on whether the property gets set or unset. > But having it consistently *immutable* is > cool with me as long as there is consistency. Having the API prohibit > properties from changing is how it should be done, and that is how I will > implement my patches. kool. > But to maintain backwards compatibility with tasks > that rely on the property mutability, should we just keep > Project.setProperty as-is and let it change properties? Should we > deprecate it though? deprecate it and then add a check inside it. If you are breaking the immutability rules then print out a really really obnoxious deprecation/warning message saying "dont use me" possibly spanning 3 lines or so. It will get really annoying and hopefully users will "choose" to upgrade to use the supported approach. > Then we create another method: Project.setNewProperty (String name, String > value) - the name of this method is up for debate. I don't think we should > go with allowing the set/unset option that Steve proposed though - just > leave properties immutable. Once set, always set - nice and simple rule. > Calling setNewProperty will log the "cannot override" warning that > <property> displays - and we'll delegate <property>'s message up to Project > then. > > We should deprecate Project.unsetProperty also, right? I did a search and > none of Ant's code calls it. Should we axe it altogether? Or leave it, > and deprecate it? deprecate and print a realy obnoxious message ;) > Here are some things within Ant's core that rely on property mutability: Heres my opinion... > <tstamp> fix. > <condition> fix. > <available> leave but issue annoying warning > <checksum> fix. > <exec> fix. > <pathconvert> don't know (could someone give me an example use case). > <uptodate> > <junit> > <p4change> > <p4counter> leave but issue annoying warning > I can't promise I caught them all, but these all call Project.setProperty > directly without doing a check for the existence of the property first. > Only <property> does that (maybe something else checks, not 100% sure) - > but of course something as important as property immutability should be > under the control of the Project, not the task. I mostly agree. I have a feeling that this approach will break down in some cases but as of yet I can't think of any such case ;) > <property> - woah, I just discovered it has an undocumented userProperty > flag! It won't override a user property, but it will set one. Thats > interesting. Should this become documented? Or is it hidden to keep > casual users from fooling around with the power of user properties > (although that won't make much difference when properties truly become > immutable)? hide, deprecate, issue ugly warning > Actually, what will the difference between regular properties > and user properties be if regular properties truly become immutable? user properties will be propogated to sub-builds even if inheritall="false" ... I think (without actually looking at code or testing theory but just a gut feeling about how it *should* work). > Let me know if there are any issues with what I'm proposing above. I want > to be 100% sure of how this should be done if/when changes are made. works for me. -- Cheers, Pete --------------------------------- I think not; therefore I ain't... --------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
