Re: C++ & Hydrant

[Jakob 'sparky' Kaivo]

"Alain Magloire" <address@hidden> writes:

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

Not completely true, perhaps, but it does have some truth.

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

Binary compatibility is quite important, don't you think? Perhaps when
GCC has settled down and C++ becomes stable, there will be more
useable C++ libraries, which will be a Good Thing, but until then C
will remain my personal language of choice for libs.

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

Of course you can add bindings for other langauges from any language
(theoretically). Arguably, though, I think it is far easier to make
C++ bindings for C rather than the other way around, especially given
the mentioned ABI flux. Also, given that C is still where the majority
of free software development takes place (and is the recommended
language by the FSF for GNU projects in particular), it seems C
bindings are more important right now.

> > 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 ;-)

Yes, similar thing with GNUTS. You have things like a window_t and a
button_t and you tell the window_t to insert this button_t and if the
current backend is curses it is naturally implemented differently than
if GTK+ is the backend. OO-y in nature, with window_t and button_t
designed as opaque structures and families of functions associated
with them.

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

To be honest, I've forgotten myself. GNU something-or-other Tookit
Shell, I think. And FWIW, it's not unpronouncable, it's "G'nuts" (like
GNU, pronounce the G sound then say the word nuts). ;)

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

I think that would be hydrant that you're trying to rename now. That
is Jeff's baby.

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

Not written down anywhere, I keep meaning to do it so I can force
myself to stick with something at least, but as we all know writing
documentation isn't the fun part. ;)

-- sparky