oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

On Wed, 2010-09-01 at 13:52 -0300, Wagner Francisco wrote:
> Eduardo, actually I have done the same thing, but in the Pathable
> class (I created a constructor for it). Then I added the name() and
> parent() methods just to access __parent__ and __name__ attributes.
> 
> Diego, I realized that too. Is this going to be a problem? And the
> __name__ will be the archetypeNodeId?
> 

No. 

The node id is the node id.

See the descriptions in the specifications.  

The parent and name attributes or methods *can* be archetype node ids.
But they can also be archetypeids, or EHR IDs.  

I was told by Sergio that he and Diego had decided to implement these as
methods.  It was never explained why this choice was taken instead of
attributes.

If you look at the use of __parent__ and __name__ attributes in Grok.
Why not write the code for the openEHR specs according to the specs.
Except in PATHABLE assign __parent__ to the PATHABLE.parent and __name__
to PATHABLE.name ?  

In my mind this allows the code everywhere to match the specs
everywhere.  It connects the PATHABLE functionality to the Grok
functionality for discovering containment and containers.  

This reduces confusion and the need to make notes about what is
different between the code and the specs. 

Does this make sense?

Thanks,
Tim

Attachment: signature.asc
Description: This is a digitally signed message part