Re: mailbox (was Re: intro)

[Sam Roberts]

I worked in C++ for years, and prefer it as a language whenever
my software architecutre starts to look object oriented. I think
C++ basically is C with language support for good C programming
practices.

I got into mailutils by porting part of my C++ library to deal with
rfc822 addreses (innovatively named mail++) to C, and integrating it.

But, I completely agree with Sergey. mailutils is an API that
allows writing programs in C or C++ that work with email (and
potentially nntp, iCalendar, ... I have my dreams). If it is
written in C++, it will not work for C programs, and that will
instantly ghettoize it.

Last time I surveyed there were NO open source libraries to do
what mailutils does in C OR in C++. Perl, Ruby, Java, ... all
have libraries to deal with mail. GNU mailutils doesn't fill a
a niche, it fills a gaping chasm.

Factoring out the internal APIs is something we all think should
be done, but don't quite have time for. But we keep trying. If we
did that then somebody could write a C++ framework on the low-level
APIs, or perhaps a nice object-oriented Ruby API.

Anyhow, I'm just repeating Sergey. I'm going back to implementing
NFS-safe locking.

Bon soir,
Sam


Quoting Sergey Poznyakoff <address@hidden>, who wrote:
> > But something that you forgot .. how many people know C++?
> > Ok those on the list that understand(can code with C++) speak
> > loudly .... The silence is deathning.
> 
> No, not at all. I know C++ and was working pretty actively in some
> projects that were using it, and my silence is just due to the fact
> that I understood C++ is not a panacea as well and have heard such
> discussions before :^) In spite of its being more strictly standardized
> than C, C++ usually poses much more compatibility problems.
> "Standards are a good thing, for you can always choose the one you
> prefer", said someone and that seems to be particularly true regarding
> different C++ compilers. Besides, there exists a strong mutual
> dependence: 'way of thinking' <=> 'spoken language' which is true for
> programming languages as well as for natural ones. In case of
> programming languages, that means that one is always tempted to use
> approaches that seem more effective in that given language. But that
> does not necessarily mean they are effective in the code the compiler
> produces. Having spent much time programming in the Lisp, I understand
> you, Alain, when you say: 'It felt funny after doing Java for so long
> to call (free) and to play with pointers.' It really feels funny after
> Lisp with its garbage collectors and other attractive features, but
> usually memory management (and not only memory management) controlled
> by programmer is much effective than that controlled by
> compiler/interpreter.
> 
> OK, that all seems to become a philosophical essay, so I'd better
> stop here. Anyway, I've said it -- I feel better :^) Let's return
> to the ... meat of the matter :^)
> 
> Both C and C++ have their pros and their contras. The reality is that
> neither is perfect and that many programs are written in C (and many
> will be written in it, I believe) and other many are written in C++.
> Mailutils could facilitate writing of those working with email. It
> would be a Good Thing if it could provide both C and C++ interfaces.
> As Alain has pointed out, usually this is achieved by writing a C++
> interface to the C API. Doing it other way around is possible but
> imposes many problems and difficulties. Portability issues should not
> be forgotten, also. So, my proposition is to provide a very good
> C API, and build other interfaces (Scheme, C++, Perl, whatever) on
> top of it.
> 
> (Sorry for being so verbose)
> 
> Regards,
> Sergey
> 
> _______________________________________________
> Bug-mailutils mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-mailutils

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)