On Sat, 8 Dec 2001, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
> From: "Stefan Bodewig" <[EMAIL PROTECTED]> > >> Appending to an existing path reference? OK, this one just came to >> my mind after I've seen Conor's mail. >> > Now, today you can do the append, you just cannot call it with the > same name. But why would you want to use the same name? Because I want to append to something I've inherited? One point to note: I don't have to change the id at all. If you go and put the immutability policy into the core at the setProperty level, it will only make sure I cannot change the Object the property's name points to. In the presence of richer objects than String, nothing prevents me from changing the value of that Object via public APIs. >> * chosing the compiler on a task by task basis. > > This is a defect of the <javac> tasks that use a "magic property" as > oppose to an attribute to make that decision. Completely agreed. > Not a goodargument for inmutability. Don't get me wrong. I don't say that properties should be mutable by <property>, I say that we shouldn't enforce immutability in the core. Partly because I don't see any reason for that restriction. > This is a none sense example, sorry to say. In the current > implementation not even <antcall> can reuse the same Project object. See CruiseControl, it does. Stefan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
