bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Breaking mailutils to pieces


From: Alain Magloire
Subject: Re: Breaking mailutils to pieces
Date: Tue, 15 May 2001 12:11:11 -0400 (EDT)

> 
> > The only problem is stream_t which is coming from pretty 
> > everybody, meaning a stream_t is "pure/virtual" interface that all the
> > objects can implement.
> <snip>
> > There is no way to do this whithout involving some ugly
> > void * and casting.  But at least they will be cover
> > by stubs funcs for typecast safeness.
> 
> If any object can implement a stream:

Yes,

- if you get a stream from a body, you will be able to read
the content of a message.

- if you get a stream for a header, read only the headers

- a stream for a message, read the header and the body
etc ...

I use the term implement loosely, since an object does not actually
implement the interface in the polymorphism way a` la java/C++
But rather you can call the function
XXX_get_stream () on the object to get an implementation.

I think the right terms are Factory and delegation.
For example, the mailbox does not implement a stream but
rather it creates an object for you (Factorisation via
mailbox_get_stream ()) and implements it (delegation of the
I/O operation to the stream object).

This was easier to handle then providing true polymorphism.
objects; mailbox, message, header, body, ... are  factories
that delegate the works to other objects instead.

So a message does not a stream, a header and a body, but rather
a message is factory that can produce a stream, a header and body.

message_get_stream (msg, &stream);
message_get_header (msg, &header);
message_get_body (msg, &body);

The message delegate the very specific tasks, to other object that
it creates.

The problem is when and who can destroy them, since C does not have
the notion of constructor and destructor someone must explicitely
destroy them.  This could get heavy, so the approach was that
only the factory (the creator, the owner, the parent, but for our purpose
lets start to use the term factory) of the objects could destroy them .

This is where we are going to change things, to limit the "damage" and
make things clearer by getting rid of the term "owner", when a factory
creates an object, it will be with an (void * ID)(the term may change)
this will give you access to destroy the object and change its part, so only
the factory of the object can destroy it.

header_destroy (&header, ID);

ouf!! ok lets take a short break 8-)

> and any object is a descendent of Folder,
>then it would be logical to make stream have Folder as its
> owner. Or am I missing something?

No, I think I was not clear .. and probably still not very clear 8-).

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]