bug-mailutils
[Top][All Lists]
Advanced

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

Re: C++ & Hydrant


From: Alain Magloire
Subject: Re: C++ & Hydrant
Date: Fri, 9 Feb 2001 14:28:17 -0500 (EST)

> 
> "Alain Magloire" <address@hidden> writes:
> 
> > > Aaargh! I started a library for that purpose some time ago, but it is
> > > far, far, *FAR* from finished. I think the last thing it was doing was
> > 
> > In C++ ?
> > If you browse sourceforge, freshmeat or whatever you have that's
> > hype today.  You'll find tons of free software, some are good
> > very good and many are bad ... very bad.
> 
> In C++? Absolutely not! No, GNUTS is being designed/written in C for
> maximum portability and ease of adding bindings for other
> languages.

Sigh ... you know that's not completly true.
It is, I admit, very unfortunate that C++ does not provide __binary__
compatibility, this was not address in the ISO C++ std.
But there are good examples on how to do this cleanly with
the Factory design patterns, Microsoft COM(no comments form the gallery
please) is a prime example of good use of those patterns.

And you can add bindings for other language using C++.  You just
have to be carefull and use pure virtual base class when defining
your interface, working like this is already a good engineering practice.


> Does it make the code a bit harder than if it were C++?
> Sure, but that's OK. I like a challenge. :)

We agree that C was not designed to be an OO.  The language maybe in the way
when implementing some features.  Also I can agree with you
for the portability i.e. when talking about general acceptance
not from a technical point of view.

> I'm also thinking about adding a small shim at a later point to make a
> plugin architecture, but that may or may not make sense. Bottom line,

It makes a lot of sense, I've seen some good ones, Java AWT, Java SWING,
Not sure what is becoming of gtk-- and the offspring "inti" etc ...
Now to be able to use "Curses" also as the back engine that's a novelty.
And would be of great fun.

> though, is that I desire for GNUTS to be to the GUI as libmailbox will
> be to mailbox access. Now, we'll see when it gets transferred to
> savannah (in process...). ;)

[laughs] 8-) ... Well libmailbox is really (or try to be) focus
on  one vision of what is a mailbox and how to access it.  So
the object "mailbox_t" and the object "message_t" are just empty
or virtual class (in our case pointers to functions in a structure) that
the different format implements, So the POP will implement the
int (*read)() function of message_t differenty then the int *(read)()
function of IMAP.  In the former case a "RETR %d\r\n" is generate and the
later a "tag FETCH % BODY[]\r\n" is send.

In OO term the mailbox_t and message_t are virtual interfaces/classes
that have concrete implementation instanciation base on the type
of URL ("pop://address@hidden").

Don't know 'bout you, but it sounded cooler in OO terms ;-)

> though, is that I desire for GNUTS to be to the GUI as libmailbox will

Ok, I'll byte, what GNUTS stand for, you english people seems to
love puns and "unprononcabale"(ist that a word ?) acronyms.

How about calling it ... Fir (Free Internet Reader) in the tradition
of Elm, Pine and Balsa.

Do you have an API for ... G NUTS or a general idea on paper ?

-- 
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]