My problem with magic properties is that they pollute the namespace of
allowed property names. Since properties are immutable, it can be
confusing for someone to try to define a property for the first time in
their build file and have it come back with an error about redefinition.
Having said that, I am in favour of this patch. I think we need to be
cautious about adding magic properties because they have a slight
negative implication, but where they have a clear benefit we should
adopt them because the benefit outweighs the risk.
There are other solutions to the namespace problem, anyway. We could
have a reserved prefix like "__ant." that wasn't allowed for
user-defined properties. Or we could have a special character that was
illegal in user-defined properties and used in all system-defined ones.
Your example about "dynamic" properties is interesting. I've always been
in favoring of making properties immutable not by value but by meaning.
When the changes were being made in the code to make properties
immutable, I got as far as convincing people to keep the DSTAMP, TSTAMP,
and TODAY properties "dynamic", so that they always represented the time
when the <tstamp /> task was run, even if it was run many times during a
build.
As another example, consider how we test for a file existing that could
be created in several places throughout the build. We might have to use
a separate property to test for existence in each section of the build:
"file.exists", "file.exists.now", "file.exists.how.about.now", and then
create complex conditions that combine all three properties into a
single property. Much easier would be if we could assign the property
directly to the existence of the file, and have it change over the
lifetime of the build.
Dominique Devienne wrote:
I'd add that those properties, if made available, should probably be
prefixed with ant., to make it clear they are "built-in". Perhaps:
ant.default-target
ant.targets-invoked
I'm +0 on adding these "static" properties.
Since we're at it, we may also want to expose ant.current-target and
ant.invoked-target properties, but these are "dynamic" since changing
during the course of the build, so more problematic given the property
immutability rules. Exposing them via a PropertyHelper to made it
clear they are dynamic perhaps? ${dynamic:ant.current-target}...
--DD
On Fri, May 30, 2008 at 4:21 AM, <[EMAIL PROTECTED]> wrote:
Colm's patch in
<https://issues.apache.org/bugzilla/show_bug.cgi?id=44980> adds two
new magic properties, one for the build's default target and one for
the targets specified on the command line (or via <*ant*>).
IIRC such properties have been suggested many moons ago and rejected,
but now the dev community is a different one and maybe we do see some
things differently today. I know that I do, i.e. I'd probably add
them today.
Before I start to discuss gritty details of a really trivial patch,
let's have a quick poll so we know whether such a feature would be
acceptable. If anybody out there would reject either property, could
you please raise your hand?
${defaultTarget}:
+1 : I am not sure if there is need, but I dont see any reason of
hiding that information
as it currently available via project instance.
${calledTargets}:
+1 : Also, we dont have to hide anything. The value should be a list
of targets
as specified while invocation without any dependency-resolution.
These properties should be set while parsing/project-initialization, so
IDEs/programs,
which dont use the Launcher, have these properties too.
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
