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, <Jan.Materne@(protected):
>  
>>> 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: dev-unsubscribe@(protected)
>> For additional commands, e-mail: dev-help@(protected)
>>
>>
>>  
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@(protected)
> For additional commands, e-mail: dev-help@(protected)
>
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@(protected)
For additional commands, e-mail: dev-help@(protected)