If we get rid of the targetClassName in the toString() return value,
does that make it easier to provide overloaded String-arg constructors
on the SingleFieldIdentity subclasses (except StringIdentity of course,
which already has a String-arg constructor)? For example,
// in class ByteIdentity
public ByteIdentity(String s) {
this(Byte.parseByte(s));
}
...
This might be convenient, letting Xxx.parseXxx(String) throw whatever it
may.
Thoughts?
--matthew
>-----Original Message-----
>From: Matthew T. Adams [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, March 30, 2005 4:17 PM
>To: [EMAIL PROTECTED]; [email protected]
>Subject: Re: SingleFieldIdentity.toString()
>
>
>I agree as well. I thought it was there for some reason that I didn't
>remember or couldn't figure out.
>
>--matthew
>
>"Wes Biggs" <[EMAIL PROTECTED]> wrote in message
>news:<[EMAIL PROTECTED]>...
>> Abe White wrote:
>>
>> >
>> >> I thought it would be nice for debugging to see the target class
>name
>> >> in the toString.
>> >
>> >
>> > I'm against this. It makes ids in URLs longer, makes parsing
>harder,
>> > and is unnecessary in general, IMO. It also leads to possible
>> > inconsistencies with the class encoded in the string and the class
>> > given to the String constructor.
>>
>> I'm with Abe.
>>
>> Wes
>
>
>
