Well, we already have:
public ByteIdentity(Class target, String s) {
this (pcClass, Byte.parseByte(justTheId(str)));
}
where clearly, justTheId() can go away now.
-Patrick
On Mar 30, 2005, at 7:22 PM, Matthew T. Adams wrote:
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]; jdo-dev@db.apache.org
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
--
Patrick Linskey
SolarMetric Inc.
smime.p7s
Description: S/MIME cryptographic signature
