You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2001/12/06 14:31:55 UTC
Immutability
Maybe I'm coming to late - have been too busy, sorry - but I'll try
anyway.
Has anybody of you (those of you pushing for property immutability in
the core) had a look at what we decided upon when we put together out
Ant2 requirements? I'm talking about
* make properties fully dynamic, i.e. allow their value to be reassigned
[will need more discussion because of vote by Glenn McAllister and
Conor MacNeill]
[finally ACCEPTED]
The actual votes her have been:
+1 by Peter Donald, Stefan Bodewig, Conor MacNeill (with some scoping
and command line override remarks), Nico Seessle, Glenn McAllister
(with some scoping remarks).
+2 Simeon Fitch
no other votes.
Can these votes all be invalidated by the patches that went in?
Erik, I really appreciate all the work that you have done and you've
cleanup up a lot of Ant's core classes a fair bit with it, but maybe
we are really going one or two steps too far?
We want to leave <property> as task the way it is, OK. We probably
also want to make all property setting core tasks behave the same way.
But do we really want to enforce property immutability as a core
feature? Our vote in April/May quite clearly says no, and at least
mine still stands.
Having said that, let's rework the last patches so that existing core
tasks don't override existing properties but there still is an API to
modify properties.
Consider this a -1 against the functionality of enforcing property
immutability in the core.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 6 Dec 2001, Jose Alberto Fernandez <j_...@yahoo.com>
wrote:
> The truth of the matter is that as the original vote below showed
> this issue has always been whishy-whashy in the minds of the
> committers, and they have change their minds over and over
> depending on the argument of the day.
I disagree here. I haven't seen anybody of the original voters except
Peter support the immutability of properties.
> Not to say the least that people that appear to have voted for
> mutability helped on fixing inmutability.
I have reworked a testcase that used property mutability for no good
reason, yes.
> Maybe after 6 months, we should go back to that list and revise
> if the opinions haven't change over time.
If we really want to: +1 on keeping properties mutable by a core API,
like they've always been. -1 on removing that functionality.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 17 Dec 2001, <cm...@yahoo.com> wrote:
> The only thing that matter to me is to preserve the current behavior
> for <property> and the existing tasks - changing all existing build
> files to work with modifiable property is not an option.
Nobody ever said that the behavior for <property> should be changed.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by cm...@yahoo.com.
On Thu, 6 Dec 2001, Jose Alberto Fernandez wrote:
> My vote does not count, as some of you have pointed out in the past,
> but I have to say that moving to having VARIABLES instead
> of declarative properties I think it is a big mistake.
+1
However it seems we're in minority, and there's little to do about this.
It has been discussed too many times, and the opinions are too solid for
any hope to change that.
The only thing that matter to me is to preserve the current behavior for
<property> and the existing tasks - changing all existing build files to
work with modifiable property is not an option.
What about maintaining 2 sets of properties, and maybe use a different
syntax for 'variables' ? <set> tag will work with vars, <property> with
'classic' immutables, and everyone can be happy. We can use $(var) or
%var% or something like that.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
My vote does not count, as some of you have pointed out in the past,
but I have to say that moving to having VARIABLES instead
of declarative properties I think it is a big mistake.
You probably knew olready what my opinion would be, since I have\
been quite vocal about it, but for the record. Here it is.
The truth of the matter is that as the original vote below showed
this issue has always been whishy-whashy in the minds of the
committers, and they have change their minds over and over
depending on the argument of the day. Not to say the least that
people that appear to have voted for mutability helped on
fixing inmutability.
Maybe after 6 months, we should go back to that list and revise
if the opinions haven't change over time.
Jose Alberto
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Thursday, December 06, 2001 1:31 PM
Subject: Immutability
> Maybe I'm coming to late - have been too busy, sorry - but I'll try
> anyway.
>
> Has anybody of you (those of you pushing for property immutability in
> the core) had a look at what we decided upon when we put together out
> Ant2 requirements? I'm talking about
>
> * make properties fully dynamic, i.e. allow their value to be reassigned
>
> [will need more discussion because of vote by Glenn McAllister and
> Conor MacNeill]
>
> [finally ACCEPTED]
>
> The actual votes her have been:
>
> +1 by Peter Donald, Stefan Bodewig, Conor MacNeill (with some scoping
> and command line override remarks), Nico Seessle, Glenn McAllister
> (with some scoping remarks).
>
> +2 Simeon Fitch
>
> no other votes.
>
> Can these votes all be invalidated by the patches that went in?
>
> Erik, I really appreciate all the work that you have done and you've
> cleanup up a lot of Ant's core classes a fair bit with it, but maybe
> we are really going one or two steps too far?
>
> We want to leave <property> as task the way it is, OK. We probably
> also want to make all property setting core tasks behave the same way.
> But do we really want to enforce property immutability as a core
> feature? Our vote in April/May quite clearly says no, and at least
> mine still stands.
>
> Having said that, let's rework the last patches so that existing core
> tasks don't override existing properties but there still is an API to
> modify properties.
>
> Consider this a -1 against the functionality of enforcing property
> immutability in the core.
>
> Stefan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 7 Dec 2001, Peter Donald <pe...@apache.org> wrote:
> On Fri, 7 Dec 2001 18:26, Stefan Bodewig wrote:
>
>> why should I assume they had changed their mind?
>
> Why should you assume they haven't?
Because my best estimate for someone's opinion is the one stated last
time he has expressed it.
Are you sure we need to continue this discussion?
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Peter Donald <pe...@apache.org>.
On Fri, 7 Dec 2001 18:26, Stefan Bodewig wrote:
> On Fri, 7 Dec 2001, Peter Donald <pe...@apache.org> wrote:
> > But you made a broad generalization, none the less.
>
> The list contains people who are still active committers now, why
> should I assume they had changed their mind?
Why should you assume they haven't? I know lots of issues that I have changed
my mind on and same with you - why should anyone else be any different ?
--
Cheers,
Pete
----------------------------------------------------
"The only way to discover the limits of the possible
is to go beyond them into the impossible."
-Arthur C. Clarke
----------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 7 Dec 2001, Peter Donald <pe...@apache.org> wrote:
> But you made a broad generalization, none the less.
The list contains people who are still active committers now, why
should I assume they had changed their mind?
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Peter Donald <pe...@apache.org>.
On Fri, 7 Dec 2001 18:04, Stefan Bodewig wrote:
> On Fri, 7 Dec 2001, Peter Donald <pe...@apache.org> wrote:
> > BTW waiting to this point in the discussion to announce your veto is
> > one of those things that I said make me sigh.
>
> This is what you get for being to busy to closely follow all threads -
> and then things are in. Better to veto it now than when we vote on a
> 1.5 relase, isn't it?
not really - no.
> >> The other statement I wanted to make is that not all people (and
> >> not all committers, quite the opposite)
> >
> > quite the opposite aye ?
>
> Judging from the vote of March/April, the list contains almost all
> active committers of that time.
of that time. Apache is a meritocracy and people who are currently active and
contributing are the ones that get to decide things.
> you and me show any opinion this time. Steve said:
> >> I think this one will have to be opened up for some consensual
> >> decision making.
>
> which didn't happen, and he didn't show what he'd prefer.
But you made a broad generalization, none the less.
--
Cheers,
Pete
---------------------------------------------------------
Clarke's Third Law: "Any technology distinguishable from
magic is insufficiently advanced".
---------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
Upsss!
The first line of my comments bellow should have read:
"the reality is that we have *not* done a proper job on Properties"
----- Original Message -----
From: "Jose Alberto Fernandez" <j_...@yahoo.com>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Saturday, December 08, 2001 10:28 AM
Subject: Re: Immutability
From: "Steve Loughran" <st...@iseran.com>
>
> 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:
>
> http://www-106.ibm.com/developerworks/library/j-antbuild/?n-j-1261
>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Steve Loughran" <st...@iseran.com>
>
> 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:
>
> http://www-106.ibm.com/developerworks/library/j-antbuild/?n-j-1261
>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Stefan Bodewig" <bo...@apache.org>
> On Fri, 7 Dec 2001, Steve Loughran <st...@iseran.com> wrote:
>
> All I want is to make sure that we don't remove the ability to change
> property values from the public API (and deprecating the only way to
> do so, says we are going to remove it).
>
Well, the fact that we deprecate the old API and put a new one in place
without mutability, does not mean that we cannot change our minds
in the future and add "setPropertyMutably" or "changeProperty"
or whatever in the future. It is not the first tme we *add* new APIs.
The problem I have with opening the door to mutability is that once
tasks start to appear using mutable behaviour (even if core does not use it)
people will have to think for each task whether is has side effects or not.
We can try to keep the core as consistent as possible, but can we be sure
that mutability will not sneak-in in a patch to fix something and the guy
just uses this API instead of the other? Once the door is there you will need a guard
at the door. So I prefer no door at all, until we have a case for having such door,
then yes, thake the wall down and open a door. :-)
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 7 Dec 2001, Steve Loughran <st...@iseran.com> wrote:
> 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.
This works well for me. Put in a warning that says, either use
setNewProperty (we recommend that) or setPropertyMutable, whatever is
closer to your original intent.
All I want is to make sure that we don't remove the ability to change
property values from the public API (and deprecating the only way to
do so, says we are going to remove it).
> http://www-106.ibm.com/developerworks/library/j-antbuild/?n-j-1261
>
> In this article the author (a) doesnt know when init() is called
> versus properties assigned
Looks as if he's using the Ant 1.1 model for this.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Steve Loughran <st...@iseran.com>.
> Judging from the vote of March/April, the list contains almost all
> active committers of that time. I haven't seen any committer except
> you and me show any opinion this time. Steve said:
>
> >> I think this one will have to be opened up for some consensual
> >> decision making.
>
> which didn't happen, and he didn't show what he'd prefer.
>
I prefer simplicity, consistency and not breaking other people's builds. I
like the 'always immutable' rule for its simplicity, but note that I am not
above using <antcall> to get around it, and have encountered one issue in a
build file where i had to run ant twice to get a change out (incrementing a
version number in an SCM controlled property file and using the same version
number in the build)
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.
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 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:
http://www-106.ibm.com/developerworks/library/j-antbuild/?n-j-1261
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
<project name="PropertyPromptExample" default="main" basedir=".">
<property name="promptTimeout" value="10"/>
<taskdef name="propertyprompt"
classname="com.ibm.samples.apache.tools.ant.taskdefs.optional.PropertyPrompt
"/>
<target name="main">
<property name="documentRoot" value="/usr/apache/htdocs/sample"/>
<echo>HTML/JSP pages installing to: ${documentRoot}</echo>
<echo>Servlet code installing to: ${servletDirectory}</echo>
<propertyprompt propertyname="documentRoot"
promptcharacter=":">Enter value for web application document root
</propertyprompt>
<propertyprompt propertyname="servletDirectory"
defaultvalue="/usr/servlets">Where should servlet classes install
</propertyprompt>
</target>
</project>
By leaving setProperty() as is we let tasks like this continue unrestricted,
as well as permit existing script code do what was deliberately written by
people who did know what they were doing.
Finally, some scoping could ultimately sort things out. local immutable
properties would substitute for global mutables, which is effectively what
antcall provides today.
-Steve
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 7 Dec 2001, Peter Donald <pe...@apache.org> wrote:
> BTW waiting to this point in the discussion to announce your veto is
> one of those things that I said make me sigh.
This is what you get for being to busy to closely follow all threads -
and then things are in. Better to veto it now than when we vote on a
1.5 relase, isn't it?
> On Fri, 7 Dec 2001 17:29, Stefan Bodewig wrote:
>
>> The other statement I wanted to make is that not all people (and
>> not all committers, quite the opposite)
>
> quite the opposite aye ?
Judging from the vote of March/April, the list contains almost all
active committers of that time. I haven't seen any committer except
you and me show any opinion this time. Steve said:
>> I think this one will have to be opened up for some consensual
>> decision making.
which didn't happen, and he didn't show what he'd prefer.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Peter Donald <pe...@apache.org>.
On Fri, 7 Dec 2001 17:29, Stefan Bodewig wrote:
> On Fri, 7 Dec 2001, Peter Donald <pe...@apache.org> wrote:
> > You know exactly what I think voting means don't you - ie nada :)
>
> Well, that's not the way things work here, sorry. I've -1ed a change
> to existing functionality of Ant 1.4, and this means a lot.
I wasn't talking about this vote I was talking aboute vote for Ant2. Lots of
people voted for various things and look where that got this.
> I'm going to commit a patch that addresses my issues and still keeps
> the tasks behaving the way they do right now.
if you feel like that. BTW waiting to this point in the discussion to
announce your veto is one of those things that I said make me sigh.
> The other statement I wanted to make is that not all people (and not
> all committers, quite the opposite) agree with the concept of
> properties being immutable, I for one don't.
quite the opposite aye ?
--
Cheers,
Pete
--------------------------------
My opinions may have changed,
but not the fact that I am right
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 7 Dec 2001, Peter Donald <pe...@apache.org> wrote:
> You know exactly what I think voting means don't you - ie nada :)
Well, that's not the way things work here, sorry. I've -1ed a change
to existing functionality of Ant 1.4, and this means a lot.
I'm going to commit a patch that addresses my issues and still keeps
the tasks behaving the way they do right now.
With this patch Project.setProperty will override existing properties
without the annoying warning - this will keep <script>s and custom
tasks working the way they did - and it will be undeprecated.
The other statement I wanted to make is that not all people (and not
all committers, quite the opposite) agree with the concept of
properties being immutable, I for one don't.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Peter Donald <pe...@apache.org>.
On Fri, 7 Dec 2001 00:31, Stefan Bodewig wrote:
> Maybe I'm coming to late - have been too busy, sorry - but I'll try
> anyway.
>
> Has anybody of you (those of you pushing for property immutability in
> the core) had a look at what we decided upon when we put together out
> Ant2 requirements? I'm talking about
You know exactly what I think voting means don't you - ie nada :) Things have
to be readdressed as they come up. That said you can still overide propertys
at the moment if you want.
--
Cheers,
Pete
*-----------------------------------------------------*
| Never argue with an idiot, they'll drag you down to |
| their level, and beat you with experience |
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
Sent: Friday, December 07, 2001 3:08 AM
> > Immutable properties are good because they free ant developers and
> > ant users from worrying about sequencing concerns in project
> > processing and it is a much simpler model for build file
> > writers.
>
> I think you are mixing properties being made immutable by the core and
> properties being immutable by the choice of the tasks.
>
> Look at what I've changed with my commit - log messages and comments
> and I removed a @deprecated tag. I'm not against modifying our
> current tasks so that they keep properties immutable, I just want to
> make sure that task writers have the choice to do different in their
> own tasks.
I'm "ok" with how you've modified things.... I'd be even happier if
<available>'s hole was closed so that truly the core tasks kept things
immutable, but for the sake of backwards compatibility I guess I'll just
have suffer through it. :)
> Build file writers won't have to worry about sequencing or anything
> else, as long as they don't use their own <change-property> task.
Or <available>.
> The built-in tasks we have are as consitent when it comes to treating
> properties as they've been two hours ago.
Agreed.
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 7 Dec 2001, Peter Donald <pe...@apache.org> wrote:
> Why don't we add the ability to evaluate perl scipts inside
> attributes?
Do we prevent people from writing tasks that do that? Not that I was
aware of it.
> Immutable properties are good because they free ant developers and
> ant users from worrying about sequencing concerns in project
> processing and it is a much simpler model for build file
> writers.
I think you are mixing properties being made immutable by the core and
properties being immutable by the choice of the tasks.
Look at what I've changed with my commit - log messages and comments
and I removed a @deprecated tag. I'm not against modifying our
current tasks so that they keep properties immutable, I just want to
make sure that task writers have the choice to do different in their
own tasks.
Build file writers won't have to worry about sequencing or anything
else, as long as they don't use their own <change-property> task.
> They don't have to worry about how different tasks handle
> assignment. So much for making things consistent.
The built-in tasks we have are as consitent when it comes to treating
properties as they've been two hours ago.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Peter Donald <pe...@apache.org>.
On Fri, 7 Dec 2001 17:43, Stefan Bodewig wrote:
> > Tasks shouldn't be allowed to override properties.
>
> Why not? Really, if people know what they are doing, why not?
Is this you being facetious? Couldn't this be said about any feature. Why
don't we add the ability to evaluate perl scipts inside attributes?
Really, if people know what they are doing, why not?
Immutable properties are good because they free ant developers and ant users
from worrying about sequencing concerns in project processing and it is a
much simpler model for build file writers. They don't have to worry about how
different tasks handle assignment. So much for making things consistent.
--
Cheers,
Pete
----------------------------------
"Don't play dumb with me.
I happen to be an expert at that"
- Maxwell Smart
----------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
MHO on immutability
-1 to immutability enforced by the core
+1 to immutability enforced by standard Ant tasks
My reasons:
I have always seen the core as a repository of values which may be
written as well as read. In Ant1 that means primarily string properties.
In Ant2, we intend to unify properties with other data types. Can we be
so sure that all such values will also be immutable. Maybe or maybe not.
I would rather keep the core simple and implement immutability at the
task level.
That allows the Ant tasks to make the decision about immutability
depending on the type of data they are manipulating. It also allows Task
writers to decide if they want to implement mutable data values (not
necessarily just string properties). I don't see why we want to force
immutability at the core level. It is an unecessary restriction.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Peter Donald <pe...@apache.org>.
On Sat, 8 Dec 2001 11:46, Erik Hatcher wrote:
> > Appending to an existing path reference? OK, this one just came to my
> > mind after I've seen Conor's mail.
>
> Why not just create a new path reference id with the two appended together?
that would be way too logical. Using a different name to refer to a different
object? Thats ludicrous ;)
> > For some other examples:
> >
> > * chosing the compiler on a task by task basis. There are projects
> > where you need to compile certain classes with a different compiler
> > than the rest of the project.
>
> How would you do that currently since properties were always somewhat
> immutable except with backdoor tricks? Use <available>?
You don't use properties but set attributes of task. So this need has already
been satisfied.
> > * reusing the same project instance in an "incremental" mode or under
> > GUI control without reconstructing it. Or even just building the
> > project instance from a build file and let the user use some wizard to
> > set property values in the GUI.
Yet why does that require properties to be mutable during the execution of
project? Wait ... it doesn't.
> Well, I can't really speak to this one, but there are many more issues
> with embedding Ant in IDE's and other systems than just property
> immutability I believe. Certainly such integration is crucial to Ant's
> long-term success though and the Ant team should build these needed hooks
> into future versions in better and better ways.
right.
> > * reacting to a change in environment - things become availbale or
> > unavailable.
>
> I can't even imagine why this is really needed, except for the case I saw
> posted recently with someone wanting to wait for a server to become
> available to deploy to it (or something like that) - and I believe that
> situation was handled with existing capabilities and didn't need to change
> property values - I think it was embedded in <condition>, IIRC.
Actually this is a need that we need to address. It has been brought several
times in the past. The classical example being fileset. Sometimes you want to
define the fileset at one point but not "evaluate" it till later. Is this a
real need? Not sure but it has been asked for lots in various guises (see the
recent live properties debate and the <tstamp/> discussion).
Last time we discussed this I think we decided that we would allow a
"resolution" step. However this has nothing to do whether a value can be
reassigned. The "resolution" step was agreed upon specifically because it did
not require that reassignment occur.
--
Cheers,
Pete
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Friday, December 07, 2001 10:13 AM
> Didn't mean to imply that (yes, I've seen the smiley 8-). "This is
> going to make Ant a procedural language" has been used to kill
> discussions all over the place (by my self as well), that's all.
> Effectively it can be used to end a thread, so it can be used for the
> same purpose as Godwin's Law, that's all.
Understood. I'm not trying to kill this thread... its actually dying down
on its own because decisions have been made on how it'll be for Ant 1.5 at
least. I'm cool with it as is, except for the <available> inconsistency.
> Appending to an existing path reference? OK, this one just came to my
> mind after I've seen Conor's mail.
Why not just create a new path reference id with the two appended together?
> > Struts has a <logic:iterate> tag that provides a scripting variable
> > within the scope of the begin and end tags.
>
> If you use a construct like a TaskContainer scoped variable, tasks
> that are supposed to access them must be aware that they are nested in
> this type of construct.
Taglibs have the ability to find their parent tags, getParent(), and even
find a specific ancestor tag by class, findAncestorWithClass.
A task that could do something similar could find out if its in a
container - getParent() instanceof TaskContainer - and default values or
error depending on its needs if not within a container.
> If you allow these containers to create a "normal" property, change it
> during iteration and then remove it from the project when they are
> done, you can use the ${} mechanism (if this one is fully dynamic) and
> no extra coding is required.
Rather than making it a "property" per se, it could just be a member
variable of the TaskContainer... getParent().getCurrentIteratorValue(). But
certainly communication via properties (aka attributes in JSP-speak) is one
of the powerful features of JSP, and they are scoped in several categories
(application, session, request, page, and scripting contexts). This analogy
falls apart a bit because anyone at anytime can change any values in any
scope it has access to - but maybe thats the key - "that it has access to".
> For some other examples:
>
> * chosing the compiler on a task by task basis. There are projects
> where you need to compile certain classes with a different compiler
> than the rest of the project.
How would you do that currently since properties were always somewhat
immutable except with backdoor tricks? Use <available>?
Even with the core enforcing immutability, <antcall> could be used, and this
seems like a good use of it actually since changing compilers is a pretty
non-standard thing to do I would think.
> * reusing the same project instance in an "incremental" mode or under
> GUI control without reconstructing it. Or even just building the
> project instance from a build file and let the user use some wizard to
> set property values in the GUI.
Well, I can't really speak to this one, but there are many more issues with
embedding Ant in IDE's and other systems than just property immutability I
believe. Certainly such integration is crucial to Ant's long-term success
though and the Ant team should build these needed hooks into future versions
in better and better ways.
> * reacting to a change in environment - things become availbale or
> unavailable.
I can't even imagine why this is really needed, except for the case I saw
posted recently with someone wanting to wait for a server to become
available to deploy to it (or something like that) - and I believe that
situation was handled with existing capabilities and didn't need to change
property values - I think it was embedded in <condition>, IIRC.
But I trust there are some use-cases out there for such situations.
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
> > 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).
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 8 Dec 2001, Jose Alberto Fernandez <j_...@yahoo.com>
wrote:
> From: "Stefan Bodewig" <bo...@apache.org>
>
>> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Stefan Bodewig" <bo...@apache.org>
> On Fri, 7 Dec 2001, Erik Hatcher <ja...@ehatchersolutions.com>
> wrote:
>
> > Could you provide an example just so I have something more tangible
> > to consider?
>
> 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?
> > Struts has a <logic:iterate> tag that provides a scripting variable
> > within the scope of the begin and end tags.
>
> If you use a construct like a TaskContainer scoped variable, tasks
> that are supposed to access them must be aware that they are nested in
> this type of construct.
>
> If you allow these containers to create a "normal" property, change it
> during iteration and then remove it from the project when they are
> done, you can use the ${} mechanism (if this one is fully dynamic) and
> no extra coding is required.
>
The problen here is that is not inmutability but the fact that, as I said before,
the current code has no concept of scoping, This would not be dificult to add
and can be done without affecting the behaviour (or coding) of tasks.
> For some other examples:
>
> * chosing the compiler on a task by task basis. There are projects
> where you need to compile certain classes with a different compiler
> than the rest of the project.
>
This is a defect of the <javac> tasks that use a "magic property"
as oppose to an attribute to make that decision. It can be easily fixed
by having a property like "compiler" which by default falls back
on the value of the "magic property".
Not a goodargument for inmutability.
> * reusing the same project instance in an "incremental" mode or under
> GUI control without reconstructing it. Or even just building the
> project instance from a build file and let the user use some wizard to
> set property values in the GUI.
>
This is a none sense example, sorry to say. In the current implementation
not even <antcall> can reuse the same Project object.
There are many other things that need to be changed before such reuse
of the Project structure can be done. So to blame inmutability
is just trying to pull a rabbit out os a hat.
> * reacting to a change in environment - things become availbale or
> unavailable.
>
This is also a false example. If this where a real situation then I could say
we need to be able to re-evaluate dependencies because the environement
in which the dependencies where evaluated can change and dependencies
can become out of date.
This are very contrived cases (in particular the GUI) that really do not seem
to be an argument for mutability.
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 7 Dec 2001, Erik Hatcher <ja...@ehatchersolutions.com>
wrote:
> I would argue that many of those need's that you mention are perhaps
> due to lack of understanding in how Ant works and how to do things
> without the need to overwrite properties.
Granted.
> No way am I bringing the "N" word into this discussion! :))
Didn't mean to imply that (yes, I've seen the smiley 8-). "This is
going to make Ant a procedural language" has been used to kill
discussions all over the place (by my self as well), that's all.
Effectively it can be used to end a thread, so it can be used for the
same purpose as Godwin's Law, that's all.
> Could you provide an example just so I have something more tangible
> to consider?
Appending to an existing path reference? OK, this one just came to my
mind after I've seen Conor's mail.
> Struts has a <logic:iterate> tag that provides a scripting variable
> within the scope of the begin and end tags.
If you use a construct like a TaskContainer scoped variable, tasks
that are supposed to access them must be aware that they are nested in
this type of construct.
If you allow these containers to create a "normal" property, change it
during iteration and then remove it from the project when they are
done, you can use the ${} mechanism (if this one is fully dynamic) and
no extra coding is required.
For some other examples:
* chosing the compiler on a task by task basis. There are projects
where you need to compile certain classes with a different compiler
than the rest of the project.
* reusing the same project instance in an "incremental" mode or under
GUI control without reconstructing it. Or even just building the
project instance from a build file and let the user use some wizard to
set property values in the GUI.
* reacting to a change in environment - things become availbale or
unavailable.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
--- Erik Hatcher <ja...@ehatchersolutions.com>
wrote:
> As far as the <iterate> goes, perhaps we the Taglib
> analogy makes sense....
> Struts has a <logic:iterate> tag that provides a
> scripting variable within
> the scope of the begin and end tags.
>
You took the words out of my mouth. I was just going
to say that for things like <iterate> or <foreach>
what we need is a better scoping of properties.
We really do not manage scopes today, what we do when
we invoke <ant> or <antcall> is to copy all the
<property>s from one Project to the next.
Once we have a well defined stack of scopes, it would
be easy to implement local scopes and all the rest.
Jose Alberto
________________________________________________________________
Nokia 5510 looks weird sounds great.
Go to http://uk.promotions.yahoo.com/nokia/ discover and win it!
The competition ends 16 th of December 2001.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Friday, December 07, 2001 5:42 AM
Subject: Re: Immutability
> I have no idea why anybody would want to alter the value of an
> existing property with any of the tasks we have. Except maybe, just
> because we provide no different way to do it. If people do it, it
> shows that they have a use-case where they need to change a property's
> value.
I would argue that many of those need's that you mention are perhaps due to
lack of understanding in how Ant works and how to do things without the need
to overwrite properties. But certainly I concur that it can be non-trivial
or confusing or ugly at best to accomplish some things because of working
around how Ant currently works.
> > Because it turns Ant into a procedural programming language rather
> > than a declarative one.
>
> This is the killall argument that gets us close to a an Ant version of
> Godwin's Law, I guess 8-)
I had to look this one up:
http://www.tuxedo.org/~esr/jargon/html/entry/Godwin's-Law.html
No way am I bringing the "N" word into this discussion! :))
> One can argue that building things *is* procedural in nature. Ant
> tries to move all the procedural bits into the tasks and lets you
> declare the relations between these tasks. My point is that enforcing
> property immutability makes some tasks that encapsulate procedural bits
> more or less unwritable.
Could you provide an example just so I have something more tangible to
consider?
As far as the <iterate> goes, perhaps we the Taglib analogy makes sense....
Struts has a <logic:iterate> tag that provides a scripting variable within
the scope of the begin and end tags.
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 7 Dec 2001, Erik Hatcher <ja...@ehatchersolutions.com>
wrote:
> From: "Stefan Bodewig" <bo...@apache.org>
>>
>> Neither that you or Jose Alberto are non-committers, nor that
>> anybody is causing trouble. I value your opinion and you know
>> that.
>
> Note the smiley above! :)
I've seen it, but it had to be said anyway.
> Disagreement is a good thing - and as I've stated when I first
> brought this issue up, I'm a bit on the fence regarding some cases
> of setting properties.
The whole discussion started with "is it OK that available can be used
to change a property's value", and right there I'm next to you on the
fence.
I have no idea why anybody would want to alter the value of an
existing property with any of the tasks we have. Except maybe, just
because we provide no different way to do it. If people do it, it
shows that they have a use-case where they need to change a property's
value.
I agree that abusing available or any other task for this purpose is
wrong and therefore I welcome the changes you've made to the tasks.
Then at some point the discussion switched to "we need to enforce the
concept of property immutability in the core". I didn't follow the
thread close enough to realize that in time and I'm sorry for this.
We don't have that concept, really, and I don't think we should have
it.
>> > Tasks shouldn't be allowed to override properties.
>>
>> Why not?
>
> Because it turns Ant into a procedural programming language rather
> than a declarative one.
This is the killall argument that gets us close to a an Ant version of
Godwin's Law, I guess 8-)
Ant is lacking some features of declarative languages that could make
up for mutable properties or other procedural features already
present in Ant (backtracking would be handy and allow us to get rid of
many use-cases for if/unless attributes of targets, for example).
One can argue that building things *is* procedural in nature. Ant
tries to move all the procedural bits into the tasks and lets you
declare the relations between these tasks. My point is that enforcing
property immutability makes some tasks that encapsulate procedural bits
more or less unwritable.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
Sent: Friday, December 07, 2001 1:43 AM
> > two non-committers causing trouble! :)
>
> That's not my point. Neither that you or Jose Alberto are
> non-committers, nor that anybody is causing trouble. I value your
> opinion and you know that. It's just that I disagree and that I had
> to point out that I'm not the only one.
Note the smiley above! :)
Disagreement is a good thing - and as I've stated when I first brought this
issue up, I'm a bit on the fence regarding some cases of setting properties.
> > Tasks shouldn't be allowed to override properties.
>
> Why not? Really, if people know what they are doing, why not?
Because it turns Ant into a procedural programming language rather than a
declarative one. That is the main reason I'd like to see immutability
enforced at the API level. I have not been following the scoping
discussions simply because I don't have the bandwidth right now to dig into
as deep as I'd like - and also I'm trying to stay away from too much Ant2
thinking at the moment since 1.x will be with us for a while.
Since we weren't removing the functionality, just adding a deprecation
warning, I'm ok with the warning being removed. Maybe, just maybe, we could
have a command-line switch (-mutable) that removed the warnings, and by
default properties were immutable?! :)))
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 7 Dec 2001, Jose Alberto Fernandez <j_...@yahoo.com>
wrote:
> If I understand your messages correctly, the issue is not only that
> you want mutable properties, but that you actually are using it in
> some code somewhere (from one of your last messages).
No, what I want is that people can write tasks in Ant 1.x and in Ant2
that change the value of a property. That's all.
A usecase? The iterator of an <iterate> task (trying to tease Peter 8-).
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
Stefan,
Can you please tell us, why is it that you need User properties to work?
If I understand your messages correctly, the issue is not only that
you want mutable properties, but that you actually are using it in some
code somewhere (from one of your last messages).
Can you please tell us what that is?
Is this a CORE task that is doing this changes? If it is, I think there
is consensus building that CORE should not override values of properties.
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 6 Dec 2001, Erik Hatcher <ja...@ehatchersolutions.com>
wrote:
> The quote I see is:
>
> "It will be possible to reassign values of properties via a built-in
> task."
>
> This came from http://jakarta.apache.org/ant/ant2/features.html - is
> this the definitive reference for Ant2 design?
It is a document I've put together from
<http://jakarta.apache.org/ant/ant2/requested-features.txt> which
reflects all things we've voted upon by then. So the text file is a
lot closer to definitve than that.
And I do have an archive of that votes, in case you want to see them -
looking them up in MArc should be easy enough, in our case:
<http://marc.theaimsgroup.com/?t=98519986700002&w=2&r=1>
8-)
> two non-committers causing trouble! :)
That's not my point. Neither that you or Jose Alberto are
non-committers, nor that anybody is causing trouble. I value your
opinion and you know that. It's just that I disagree and that I had
to point out that I'm not the only one.
> The overridability (thats a bad term since its really the first to
> set wins) is one of the most powerful and pleasant features of Ant
> 1.x
This is a feature of the <property> task and a feature I don't want to
take away from it. I just want to keep it possible to have mutable
properties.
> Tasks shouldn't be allowed to override properties.
Why not? Really, if people know what they are doing, why not?
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
> ----- Original Message -----
> From: "Stefan Bodewig" <bo...@apache.org>
>
> I don't read the above quote so strongly. It says a "built-in" task can
> reassign properties - this is currently possible except with a warning. And
> perhaps with some more refactoring a more privileged way of setting
> properties could be created and prevent general tasks from doing so at the
> API level yet allowing other constructs the capability.
>
Well actually, the above design principle is being satisfied by Erik's changes.
The "built-in" tasks <ant> and <antcall> are able to reassign properties
but they do it for a particular scope or period of time. ;-)
> > Having said that, let's rework the last patches so that existing core
> > tasks don't override existing properties but there still is an API to
> > modify properties.
>
I would like to explore if adding "Property Project.createUserProperty()" could be
an alternative having a constructor "Property(boolean)" my original idea was
that Project can control when it allows the method above to succeed, for example
limit to only during a particular phase of the instantiation of a project.
In any case I will try to cook a patch and then we can discuss if it is worth or not.
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Immutability
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
> Has anybody of you (those of you pushing for property immutability in
> the core) had a look at what we decided upon when we put together out
> Ant2 requirements? I'm talking about
>
> * make properties fully dynamic, i.e. allow their value to be reassigned
The quote I see is:
"It will be possible to reassign values of properties via a built-in task."
This came from http://jakarta.apache.org/ant/ant2/features.html - is this
the definitive reference for Ant2 design?
> Erik, I really appreciate all the work that you have done and you've
> cleanup up a lot of Ant's core classes a fair bit with it, but maybe
> we are really going one or two steps too far?
Oops.... I hope not. I'm with Jose (yeah, two non-committers causing
trouble! :) on this one as far as the declarative nature of Ant goes. The
overridability (thats a bad term since its really the first to set wins) is
one of the most powerful and pleasant features of Ant 1.x (1.3+ is my
experience, so not speaking for earlier versions!).
I don't know how its planned to handle allowing properties to change, and
its hard to visualize just design documents even if this is spelled out -
I'd like to see a more concrete example of any kinds of scoping and
overridability and how that would play out in Ant2.
> We want to leave <property> as task the way it is, OK. We probably
> also want to make all property setting core tasks behave the same way.
> But do we really want to enforce property immutability as a core
> feature?
I think enforcing at the API level is the way to go. Tasks shouldn't be
allowed to override properties. I do feel a bit less-strong about things
like <available> and <condition> since I'm really asking "is this file
present?" and if the property is previously set then the answer I get is not
necessarily accurate - but you can see a warning go by and re-using property
names is discouraged, and I can see benefit to being able to override such
things with -D to force something through.
> Our vote in April/May quite clearly says no, and at least
> mine still stands.
I don't read the above quote so strongly. It says a "built-in" task can
reassign properties - this is currently possible except with a warning. And
perhaps with some more refactoring a more privileged way of setting
properties could be created and prevent general tasks from doing so at the
API level yet allowing other constructs the capability.
> Having said that, let's rework the last patches so that existing core
> tasks don't override existing properties but there still is an API to
> modify properties.
I think all core tasks except <available> have been reworked to call
setNewProperty. setProperty still overrides existing properties, except
issues a warning. The warning could be removed if thats too annoying and we
could just be careful not to use that API call for built-in/optional tasks
(unless desired for some reason).
> Consider this a -1 against the functionality of enforcing property
> immutability in the core.
*ugh* :)
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>