ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Cohen" <>
Subject RE: Immutability
Date Sat, 08 Dec 2001 18:53:01 GMT

-----Original Message-----
From:	Jose Alberto Fernandez
Sent:	Sat 12/8/2001 7:14 AM
To:	Ant Developers List
Subject:	Re: Immutability
The first line of my comments bellow should have read:
  "the reality is that we have *not* done a proper job on Properties"

I had decided it was sarcasm.

----- Original Message ----- 
From: "Jose Alberto Fernandez" <>
To: "Ant Developers List" <>
Sent: Saturday, December 08, 2001 10:28 AM
Subject: Re: Immutability

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
> out of our way to overwrite stuff, just that the sole entry point
> implement immutability.
> New tasks can now choose whether to use the mutable or the immutable
> points. but what about the existing ones? We cant tell from
> whether any overwrite is an accident or deliberate.

Sad to say, but the reality is that we have done a proper job on
There is no proper datastructure and no proper abstraction for them.
We allowed the details of the implementation (two Hashtables), to be
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
> would seem to work. If somebody really, really wants to set a property
> overwriting and no warning, then they can use the #3 method, the one
> isnt written yet, setPropertyMutably(name,value) which will also unset
> property if the value is null.

I am all with you on this (although I would have to think about the name
that new method) :^/ . What we need is to go to a drawing board and come
with a proper datastructure for storing Property values, and all those
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
> 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
> properties would substitute for global mutables, which is effectively
> antcall provides today.

My thoughts exactly. Lets define something proper.

Jose Alberto

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

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

View raw message