oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

Hi Diego,

Thanks for the prompt reply.

On Mon, 2010-06-28 at 15:19 -0300, Diego Manhães Pinheiro wrote:
>         
> In fact, I implement this behaviour. I think a can explain why I
> choose this way: that way I find to solve the circular problem[1].
> It's more simple that it sounds. Take a look at the history.txt[1]
> file where have tests that exercise the behaviour properly. Just a
> hint: You don't have to interact directly with that EventContainer
> object.Your focus is History object, right ? Try to pass a list of
> events at the object instantiation. Anyway, look at the history.txt
> doctest to help you.

I do not have time right now to take an in-depth look at it.  But I
understand your approach. It seems to be a usable solution to the
circular import problem by abstracting away those offending attributes.

>         
> The EventContainer really isn't defined in the openEHR specification.
> In the specification it was defined as a list[2]. 

Correct; a list that can only contain instances of Events.

> If you think more generically the intention to use a List object is
> define a collection of objects. I prefered use the Container object
> than a List object why it solved fast and pretty well, IMHO. I also
> could change that to use a diferent class such as a PersistentList
> object [3]. This is a implementation concern that have to be
> discussed.

There are pros for this choice especially in path to object creation.


>         
>         There is not any documentation on them either.  There should
>         be a
>         blueprint or a bug report stating the necessity for them as
>         well as some
>         documentation on their purpose and usage if they are in fact
>         required.
> Ok. Tests are not exactly documentation. If we look at this
> affirmation, I could say all OSHIP code don't have a good
> documentation. 

You COULD say that; but it wouldn't be true.  Every Interface and Class
have a docstring and the package (file) documentation references you to
exactly the module out of more than 1000 pages of specification
documentation. That equals pretty well documented, I think.

> Anyway, the doctest that did looks like a documentation. Take a look
> and find out it's ok.

It seems to be complete enough for implementation by others.

However, we are working on a large project with many people in various
geographic locations.  We also have an obligation to funding agencies to
account for our progress so that funding may continue. It is imperative
that the tools available on Launchpad are used for their intended
purposes.  Use of these tools and the mailing list is crucial for a
coherent working environment and good project management.

Thank You,
Tim

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