We should not ask objects "at the MailRepository interface level" toI tend to agree. It just feels wrong in OO terms.
destroy
or rename themselves. This leads to 'ghost' objects in memory which no
longer represent real objects in the underlying repository. From an OO
sense
its wrong as the connected entity should have no knowledge of how it is
connected and hence should not assume to know how to disconnect itself.
Hi guys, hope you don't mind me butting in...
As long as you have in-memory objects representing external resources (such as data on a filesystem), this possibility of "ghost" objects is going to occur. For example:
Thing x = foo(); x.delete(); // x is a ghost
Thing x = foo(); thingManager.delete(x); // x is a ghost
Either way, you end up in the same state. It's the same state an Input/OutputStream or JDBC connection enters when you call .close() on it. The problem (to the extent that it is a problem) is sort of inherent any time object representations can outlive the underlying resource.
And as a counterexample to Steve's file system example, java.io.File has methods on itself for rename and delete.
So my take is that it's not worth spending a lot of calories to avoid having .delete() and .rename() on a MailRepository. Unless there are other Avalon/James specific issues here, I have to admit I don't have a good sense for how the system is put together.
Not sure if this really helps, and as I've already said, I'm not sure what<>Have a nice time! I'm also on holiday so we can pick this up later :)
is in the code base. Finally, just to be really helpful, I'm off sailing
for
a week from Sunday, so will not be responding immediately to any
discussion
this may provoke.
Me too :)
-jmc
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
