At 12:43 PM 06/28/2000 +0200, "SB" Stefan wrote:
>>>>>> "TD" == Tom Dimock <[EMAIL PROTECTED]> writes:
>
> TD> At 04:58 PM 06/27/2000 +0200, you wrote:
>
> TD> but not long enough to know what was proposed to replace it....
>
SB>Well, one thing we all seemed to agree on was that properties should
SB>be richer objects, not just Strings, and that the Project would hold a
SB>java.util.Properties like repository of these.
Yes, yes, yes. Or should I say +1 :-)
SB>I've not seen a proposal on how to set these properties with types
SB>other than String so far and in fact I've not seen an alternative to
SB>the ${} syntax. I think the last point should be done by passing the
SB>name of the property to the task and let the task evaluate it - just
SB>like the if/unless attributes of the include/exclude parts in
SB>MatchingTask work.
One problem with XML is that by making all attrubutes quoted, they
eliminated the most conventional way of distinguishing between a literal
and a reference. The ${} syntax is pretty ugly, but is currently the way
ant is telling the difference between a literal value and a property
reference. How would we do that if we wanted to eliminate ${} ?
SB>Your <worklist> would be a way to specify a property with file list
SB>value, right? So how about giving the Property task - it is a Task
SB>implementation after all - MatchingTask behavior?
Yes! Exactly where I was headed. The string-only aspect of properties had
prevented me from doing it the way you suggest, but if we make properties
richer objects, this becomes the way to do it.
SB><property name="files" dir="mybasedir>
SB> <include ... />
SB></property>
SB>
SB>Stefan
SB>
----------------------------------------------------------------------------
Tom Dimock ---- Cornell University ---- [EMAIL PROTECTED]
"There go my people. I must follow them, for I am their leader." M. Gandhi
