On Thu, Oct 2, 2008 at 20:32, Markus Wiederkehr <[EMAIL PROTECTED]> wrote: > On Thu, Oct 2, 2008 at 7:36 PM, Bernd Fondermann < > [EMAIL PROTECTED]> wrote: > >> I share the goal of having mutations of a mail without duplicating all >> related parts and underlying resources. But this has to be done >> thoughtfully. >> Incorporating this into the core container classes representing the >> message is not the way to go, I think. >> Managing (cloning, copying, cleaning up) a tree of message components >> are concerns that should be handled by a separate utility layer >> specialized classes. > > > Are you talking about using the visitor pattern? I can think of no other way > a separate utility layer could recursively clone the internal structure of a > message. > > A visitor cannot be easily implemented because a) not all classes are public > (TempFileBinaryBody and TempFileTextBody) and b) the set of classes is open > for extension (a user could override MessageBuilder.body() to use custom > Body implementations). > > Also, the underlying storage mechanism (tempory files currently) >> should be moved out so it becomes exchangable. > > > Are you aware of TempStorage.setInstance(TempStorage)? > > >> Hope this does not discourage you, because this is very important >> stuff which is in on/off discussion for a long time. > > > Not at all. If someone has a better idea let's go for it. But at the moment > I still believe that good old clone() would do a good job for this > particular problem.
I'd prefer a copy constructor, or a CopyUtil. Please consider http://en.wikipedia.org/wiki/Clone_(Java_method) Bernd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
