I like the idea of these methods being in a class which specializes in cloning. I think it will make it more obvious where to look. If a person wants to find a method which will help them clone their objects, where would they naturally look? If there is no CloneUtils, they might look in ObjectUtils, since the clone() method is defined in the Object class. It's not exactly obvious that they should look in SerializationUtils, since not everyone knows about that little trick. So, I'm +1 for moving that stuff into a new class, CloneUtils.
-----Original Message----- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 6:27 AM To: Jakarta Commons Developers List Subject: Re: [lang] CloneUtils I generally like small classes with few methods, but a significant exception to that is utility classes. In this case I prefer the kind of thing we've done with StringUtils. That way, when there is string manipulation to be done, I know exactly where to go to look, without having to drag out sveral classes hunting the right method. So I'm +1 on multiple methods with nice names. On 6/7/05, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > > I like the idea of multiple methods with nice names. I'm not averse to a > CloneUtils class (it could be argued that StringUtils is too big as one > class, or that it is most convenient as one class...) Perhaps others can > comment on the location of the new methods. > > Stephen > > > Kevin Gessner wrote: > > Kind of what I had in mind, but I'm not sure why serialization would > > be the last-attempted method. It's guaranteed to work for any > > Serializable without mucking about with reflection, so it should > > probably go first. We should also add support for Externalizables (as > > rare as they often are). I hacked up some code based on Serialization > > cloning, which I could send along. > > > > I don't think this should nec'ly go in with ObjectUtils. Each of the > > techniques of cloning would be its own method, with something like a > > cloneAll(Object o) that would try each in turn. I think this would > > make ObjectUtils messy, and CloneUtils would tie it together nicely. > > > > Kevin > > > > On 6/6/05, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > > > >>OK, here is the definition of CloneUtils as originally in my mind: > >> > >>See PrototypeFactory in [collections]. > >> > >>It clones an object by > >>a) public method named cloned (called by reflection) > >>b) public copy constructor > >>c) serialization > >>(trying each in turn until one suceeds) > >> > >>IMHO, this would now be written as ObjectUtils.clone(Object). > >> > >>(serialization is merely a means to an end, otherwise it would sit with > >>[io]) > >> > >>Stephen > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
