Redux: Circular Imports
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080704/2bd9cb7a/attachment.html
Redux: Circular Imports
Thomas Beale wrote: Tim Cook wrote: For example in IArchetype (the Archetype interface) I define ontology as an ArchetypeOntology type. Now Archetype of course is supposed to implement IArchetype. IArchetypeOntology defines parentArchetype as an Archetype type. This creates a circular dependency when the interfaces try to create a datatype based on a class that depends on itself. 2 the difference between circular references in the object model, and circular references in instances graphs. ... 3. a self-reference in the class model, such as for DV_MULTIMEDIA doesn't necessarily mean a circular reference in an instance graph (and it doesn't in this case) ... Now I need to be clear about something ;-) I'm 99% certain, Thomas, that Tim is talking about circular references in the class model, not in the instance graph. Eiffel seamlessly lets classes reference each other, but some languages can't cope with it as easily. First thing is, Tim has done the mind-body split thing, writing an interface for each class. That's fine. But his problem is this: Archetype --- implements --- IArchetype: ontology: IArchetypeOntology IArchetypeOntology: parentArchetype: Archetype So he has Archetype depends on IArchetype depends on IArchetypOntology depends on Archetype depends on IArchetype depends on ... ad infinitum. Apparently it gives the Python interpreter an apoplexy when it tries to resolve references that it has discovered yet. But as I mentioned in my earlier email, a bit of googling suggests that Python does have ways of working around this. Let's see what Tim thinks. - Peter
Redux: Circular Imports
On Fri, 2008-07-04 at 10:03 +1000, Peter Gummer wrote: Hi Tim, Tim, you're reminding me of the old days when I programmed in Delphi, Ahhh yes. The good old days of Clipper. :-) In Python's case, I imagine that the root cause of the problem would be that it's an interpreted language. Is this why circular imports cause trouble in Python? Well, first of all Python doesn't have the concept of Interfaces in the language. This is added by another library that abuses the 'class' statement to create them. More on this issue in followup emails. Can you fix the problem by putting the two interfaces in the same module? Nope. In fact I started with this approach and it was MUCH worse. Does one of these work for you? Nope. They aren't the same problem. - Peter P.S. Your posts to the mailing lists are always interesting, Tim, but those of us using Microsoft Outlook (and its successor Windows Live Mail) have to go to considerable effort to read them, because the messages appear empty with the content as an attachment. I realise that this is because of a defect in those applications, but you are one of only two people in all the various lists that I subscribe to who send emails in this form, so I'm certainly not going to all the trouble of moving to a new email client. I know of one person who simply deletes your posts because of this issue. (For the benefit of people using these email clients, I've manually pasted your message in full below.) Thanks for this reminder Peter. The problem is manifested in the way that Outlook Express and it's successor(s) handle MIME types. I digitally sign all of my outgoing email. I think it is the right thing to do and if the world ever catches on then we could eliminate SPAM with simple filters that dump all unsigned/unauthenticated email. However, I realize that I am in a 1% minority and I try to remember to subvert this issue by creating an attachment to my emails. This (somehow) causes those email clients to correctly display the text (see my attached graphic). I often forget to attach something and without it, that causes certain clients to display my text as an attachment. I have also had several corporate email systems reject my emails because of the signature. They seem to think it's a virus. Go figure; a more 'certain' email is rejected due to sociological and technological ignorance. I remain steadfast though and will hopefully remember to add the attachment so people don't have to reach for the delete button. Though I am sure many people go into the ignore mode upon receiving email from me. :-) Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** -- next part -- A non-text attachment was scrubbed... Name: Displayemail.gif Type: image/gif Size: 4274 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080704/e3b3b35d/attachment.gif -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080704/e3b3b35d/attachment.asc
Redux: Circular Imports
On Fri, 2008-07-04 Peter Gummer wrote: Now I need to be clear about something ;-) I'm 99% certain, Thomas, that Tim is talking about circular references in the class model, not in the instance graph. True. Apparently it gives the Python interpreter an apoplexy when it tries to resolve references that it has discovered yet. But as I mentioned in my earlier email, a bit of googling suggests that Python does have ways of working around this. Let's see what Tim thinks. Let's see if I can add some context and explain my complaint a bit better. An Archetype instance is a container and it has 6 items in it. Some are required, some optional. Some of those are containers as well. You can visualize this by thinking of a directory tree: Archetype adl_version archetype-id uid concept parent_archetype_id definition ontology invariants revision_history (inherited) Sticking with the ontology issue: Archetype adl_version archetype-id uid concept parent_archetype_id definition ontology terminologies_available specialisation_depth term_codes constraint_codes term_attribute_names parent_archetype_id invariants revision_history (inherited) The issue here is the REQUIRED attribute parent_archetype_id. The description is; Archetype which owns this ontology. Intuitively (to me anyway) this would indicate that I would assign the OID of the parent Archetype to this attribute. However, the specifications call for the attribute to be of the type 'Archetype' and it can't be just any archetype, it is supposed to be the Archetype containing this ontology. so I would have a repeating tree like this: Archetype adl_version archetype-id uid concept parent_archetype_id definition ontology terminologies_available specialisation_depth term_codes constraint_codes term_attribute_names parent_archetype_id Archetype adl_version archetype-id uid concept parent_archetype_id definition ontology terminologies_available specialisation_depth term_codes constraint_codes term_attribute_names parent_archetype_id ... (repeat infinitely) invariants revision_history (inherited) invariants revision_history (inherited) So my suggestion is that ARCHETYPE.ontology.parent_archetype_id be of a 'type' that represents the OID of the parent and NOT the parent itself. Cheers, Tim -- next part -- A non-text attachment was scrubbed... Name: Displayemail.gif Type: image/gif Size: 4274 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080704/8f2c65b6/attachment.gif -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080704/8f2c65b6/attachment.asc
Redux: Circular Imports
On Thu, 2008-07-03 at 16:50 -0300, Tim Cook wrote: My solution for Archetype.parentArchetype is to make it an ArchetypeId type. Sorry, this should have said make it an ObjectRef type that points to the parent Archetype. -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080703/7fa01676/attachment.asc
Redux: Circular Imports
On Thu, 2008-07-03 at 17:14 -0300, Tim Cook wrote: On Thu, 2008-07-03 at 16:50 -0300, Tim Cook wrote: My solution for Archetype.parentArchetype is to make it an ArchetypeId type. Sorry, this should have said make it an ObjectRef type that points to the parent Archetype. Just one more note here for my personal pet peeve in this area. If you do not break up your archetyped data in some non-hierarchical persistence layer then you don't need this attribute anyway. :-) --Tim -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080703/b14288bd/attachment.asc
Email Clients (was Redux: Circular Imports)
Message: 5 Date: Fri, 04 Jul 2008 10:18:48 +1000 From: Hugh Leslie hugh.leslie at oceaninformatics.com Subject: Re: Redux: Circular Imports To: Peter Gummer peter.gummer at oceaninformatics.com, For openEHR technical discussions openehr-technical at openehr.org Message-ID: 486D6C68.6000801 at oceaninformatics.com Content-Type: text/plain; charset=us-ascii An HTML attachment was scrubbed... URL: http://lists.chime.ucl.ac.uk/mailman/private/openehr-technical/attachments/20080704/2bd9cb7a/attachment.html -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical End of openEHR-technical Digest, Vol 24, Issue 9 Though your Thunderbird client wreaks havoc on the digest version which scrubs it and sends me to a wickedly difficult post to read... An HTML attachment was scrubbed... URL: http://lists.chime.ucl.ac.uk/mailman/private/openehr-technical/attachments/20080704/2bd9cb7a/attachment.html Tim's are fine though, lol. Lets hope openEHR has more interoperability than RFC 821 ... :-)
