ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: Immutability
Date Sat, 08 Dec 2001 10:28:26 GMT
From: "Steve Loughran" <>

> till last week's setNewProperty() method, all tasks or scripts which set a
> property had to use setProperty. This doesnt mean that they (we!) were going
> out of our way to overwrite stuff, just that the sole entry point didnt
> implement immutability.
> New tasks can now choose whether to use the mutable or the immutable entry
> points. but what about the existing ones? We cant tell from setProperty()
> whether any overwrite is an accident or deliberate.

Sad to say, but the reality is that we have done a proper job on Properties.
There is no proper datastructure and no proper abstraction for them.
We allowed the details of the implementation (two Hashtables), to be visible
in the API. Even worst as Steve has pointed out, anyone even without
knowing can mess up things because everything has been exposed.

> Really we want everyone who used setProperty() in a task without knowing of
> its side effect to move to setNewProperty(). So keeping a warning in there
> would seem to work. If somebody really, really wants to set a property with
> overwriting and no warning, then they can use the #3 method, the one that
> isnt written yet, setPropertyMutably(name,value) which will also unset a
> property if the value is null.

I am all with you on this (although I would have to think about the name for
that new method) :^/ . What we need is to go to a drawing board and come up
with a proper datastructure for storing Property values, and all those nagging 
other things that we want to be able to store and move arround.

Once we have a decent storage implementation, we can move the code to the new
and deprecate or give facades to ALL this awfull APIs we have today.

> I was happy with the warning message, but I understand why Stefan pulled it.
> However, it permits people to write tasks (and articles about them) such as
> this little bunny here:
> In this article the author (a) doesnt know when init() is called versus
> properties assigned and then writes an input task which explicitly
> overwrites properties assigned in advance

I wonder how many others are promoting writing tasks like that.

> Finally, some scoping could ultimately sort things out. local immutable
> properties would substitute for global mutables, which is effectively what
> antcall provides today.

My thoughts exactly. Lets define something proper.

Jose Alberto

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message