ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rees <d.ree...@usa.net>
Subject Re: [VOTE] the simple stuff
Date Sun, 01 Apr 2001 20:47:05 GMT
On 28 Mar 2001 10:03:06 +0200, Stefan Bodewig wrote:

>David Rees <d.rees.l@usa.net> wrote:
>
>>>Stefan Bodewig wrote:
>>>
>>>> Glenn McAllister <glenn@somanetworks.com> wrote:
>>>>
>>>> ${myclasspath} should invoke .toString() on the thingy named
>>>> myclasspath, be it a <path> or a <property>.
>>>>
>>>> Stefan
>>>
>>>And that's probably the clearest explaination I've head yet. :-)
>>
>> Should it really be toString()?
>
>Yes.
>
>> Perhaps a toAntAttributeString() that falls back to toString()?
>
>Do you mean whoever expands the ${} should look whether the referenced
>object has a toAntAttributeString() method and invoke this - and fall
>back to toString if it doesn't? Why?
>


Because the use of toString() is overloaded already. Its used for
debugging, its used for displaying, it is used by other application,
and it used for the Ant string. If I want to use it differently for
debugging, some other application and/or Ant then I am out of luck.

This is actually a well known "problem" in the Smalltalk world. The
method printString (same as toString) has been on the list of "bad"
design decisions for at least ten years. About 6? years ago they
introduced printDisplayString so at least you could distinguish
between the string the system uses and the string user sees. However
its not as big a problem in Smalltalk because you can add a method at
Object. The typical solution would be to add Object.toAntString() and
have it return the results of toString(). Then you can easily override
for the places you need to. You clearly can't do this in Java so you
need to add complexity in the caller.

dave

Mime
View raw message