ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: Immutability
Date Tue, 11 Dec 2001 02:02:26 GMT
----- Original Message -----
From: "Stefan Bodewig" <>
> > 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?

Why wouldn't you use a different property name for the concatenated path?

> 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.

Agreed.  This got tightened somewhat with my patches that copy the
properties returned by getProperties and getUserProperties though, so you
can't modify via a reference there anymore.

Well, lets not say "nothing prevents" you.... we could always make "mock"
objects when returning richer objects that take advantage of some of the
reflection API that deals with Proxy and InvocationHandler and restrict all
method calls to an object once we hand it out.  :))

I could hand you a "FileSet" that would ignore a call to setDir, for
example.  Ain't Java cool like that?

> 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.

Well, I'm with Jose on this one.... keep doors closed and things as tight
and restricted as possible until there is a need to open it up.  I've still
yet to see a compelling example for mutable properties except for what seems
to be common-sense to me with allowing <available> and <condition> to
override properties (yet duplicate property names are not recommended, and
perhaps there is a good argument for allowing a -D property to take
precedence on those).


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

View raw message