Sorry, I meant "forCanonicalName" of course. -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Monday, September 05, 2005 11:26 PM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: RE: [lang] enhanced version of Class.forName
I have the code added to ClassUtils in "lang" right now in my IDE. What would be a good name for the method, though? I don't really like "extendedForName." What about "getCanonicalName"? Any other suggestions? We could just use "forName", but the distinction between the Class.forName() and the ClassUtils.forName() wouldn't be that obvious. Would the "lang" folks care if I checked in this code (with test cases of course) once we decide on what the name of the method should be (or whether or not it should be in there in the first place)? -----Original Message----- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, September 05, 2005 8:26 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: [lang] enhanced version of Class.forName Deja Vu :) +1 Jan-2005:http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200501 .mbox/[EMAIL PROTECTED] Feb-2005:http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200502 .mbox/[EMAIL PROTECTED] Various ClassLoader issues raised by Stephen, we agreed to hold off until after 2.1; so now is a good time. Hen On 9/5/05, Thomas Dudziak <[EMAIL PROTECTED]> wrote: > (Ups, only replied to Wade, not the list) > > On 9/5/05, Wade Chandler <[EMAIL PROTECTED]> wrote: > > > What's a use case for it Tom? curious. > > I just checked-in an enhancement for OJB that allows to specify which > constructor/factory-method to utilize for constructing objects read > from the database. These can have parameters which are described by > corresponding parameter element: > > <creation-descriptor > type="factory" > factory-class="org.apache.ojb.broker.ObjectTestFactory" > factory-method="createInstance" > > > <parameter field-ref="name"/> > <parameter field-ref="value" type="int[]"/> > </creation-descriptor> > > The optional type attribute allows the user to explicitly specify the > parameter type thus helping OJB finding the correct constructor/method > (in case of overload). > > Now if I'd use plain Class.forName, the user would have to specify: > > [LI > > for this int array which is hardly user-friendly. The solution that I > added, allows for the normal type specification as is used in variable > declarations or for method parameters. > > Tom > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
