--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On 8/22/07, Peter Reilly
> <[EMAIL PROTECTED]> wrote:
> Note that I'm lost in this discussion...
>
> > "${el:project.targets.get('not-present')}" should
> resolve to
> > "null" rather than
> "${el:project.targets.get('not-present')}".
> > - the string "null" cannot be used, it actually
> needs to be
> > an null object (when given to setAttribute(Object
> val))
>
> But this is interesting and a bit worrying. Why
> should it resolve to
> "null" or a null object, rather than the empty
> string "", or raise an
> exception? In fact, returning
> "${el:project.targets.get('not-present')}" is
> consistent with current
> Ant usage.
I am starting to remember going down this road,
myself, and deciding that it might be reasonable wrt
least surprise to simply treat nulls as they always
were. But that doesn't fully account for the
situation where one really does want to allow null as
a potential value one has pulled from some custom
PropertyEvaluator to be set as a property of an
Ant-managed type. We can continue down Peter's road,
though I'd still like an opinion on the proxy
mechanism I suggested for delegate recursion... :)
-Matt
>
> Which setAttribute(Object val) are you referring to
> Peter? A setter on
> a task? Is it a good thing to have "untyped"
> attributes like this?
>
> I'm just trying to understand the user-side behavior
> of PH and the
> Local Property proposal, but so far the picture is
> muddy for me. --DD
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news,
photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
