On Mon, Aug 16, 2010 at 3:37 PM, Nicolas Oury <nicolas.o...@gmail.com> wrote:
> On Mon, Aug 16, 2010 at 10:51 AM, Martin DeMello
> <martindeme...@gmail.com> wrote:
>> Sometimes there's simply no way around it. For instance, I recently
>> had some python code that (stripped to its simplest form) had two
>> classes, Document and Attachment, where Attachment was a specialised
>> subclass of Document, but Document had a list of Attachments as one of
>> its members. There was no way around packing the Document and
>> Attachment classes into one big file, simply because I couldn't do
>> circular module dependencies (python files are modules), but any
>> refactoring of the code to remove the circular dependency left it
>> *more* complicated than before.
>
> In Clojure, a protocol Attachable, could have been made explaining
> what are the things you need for an attachment.
How would that have helped? The problem lay in the fact that there
could be many subclasses of Document, but only one specific subclass,
Attachment, could go into the attachments[] field. So if we had to
split the code into two files, we'd have
class Attachment(Document) # <-- attachment.py needs to import from document.py
...
and
class Document
def create_attachment
self.attachments += Attachment.new() # <-- document.py needs to
import from attachment.py
I did think for a while that it was a code smell, but after some
attempts at refactoring decided it was a "genuine" circular reference
in that this was the conceptually simplest and clearest way to write
it.
martin
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
