Re: [Evolution-hackers] Problems with camel

[Not Zed <notzed ximian com>]

On Wed, 2005-03-02 at 09:26 +0100, Søren Hansen wrote:
> ons, 02 03 2005 kl. 09:38 +0800, skrev Not Zed:
> > > > And that means actually subclassing it, you can't just create it and
> > > > override the virtual methods manually.
> > > Ok, this might be more of a GObject question, but why? I realize now
> > > that I'm not *supposed* to instantiate it, but I don't understand that
> > > it fails.
> > It has nothing to do with GObject.  It is unclear what failed, I
> > presume it just crashed because you didn't build a concrete class.
>
> Maybe it's just me being too much of and old school C programmer, but
> "abstract", "concrete", "class" and "object" are not words in my regular
> C programming vocabulary. Hence, I don't expect the programming langauge
> or compiler to make sure that I can't create "instances" of "objects"
> considered "abstract". 
Well you'll have to be more flexible, just like the C language is :)  Camel is an object-based library.  It may be written in C, but it's design and implementation is just as OO as if it was written in Java (similarly, it is possible to write procedural code in Java - and often happens since OO design is harder than most coders know how to deal with properly).
> Obviously, there's something I don't understand.. :-)
> The way I see it:
> * CamelSession is a struct containing some fields.
> * Among others, it contains a CamelSessionClass as the first field.
> * A CamelSessionClass is a struct containing some fields.
> * One of these fields is a function pointer called get_password.
>
> When I create a new object of type CamelSession, I'd expect to be able
> to access the get_password field, regardless of what it says in a
> comment at the top of camel-session.h. :-)

Well, that's like saying you should be able to pass an int to a string parameter to printf, because the compiler lets you (ok, modern compilers warn, but lets assume for the sake of argument they didn't).

But you can't.  Because the documented design is such that that is an invalid argument.  Camel is an object system, a class instance is implemented as a struct, but it isn't a simple struct you should allocate on your own.  Becuase that isn't part of the library interface.

Or like saying you can allocate any structure with malloc even when there is a specific allocator for it (e.g. a file handle).  The class allocator is camel_type_register().

> > Well, you must also remember camel is just an internal library, it has
> > incomplete documentation for external use, and neither is the api
> > guaranteed to be stable yet.
>
> I know. I'm doing this any becuase I want to get to know Camel. It makes
> it easier to understand the Evolution code, I think.
> Also, I'm considering using camel as is, and I'm willing maintain the
> glue code, so it shouldn't be too much of a problem if I can understand
> Camel.
Ok.  It isn't really that difficult once you grok the object idea.  And camel-session is about the only class any external code has to actually implement anyway, after that it is really just function calls.

See tests/smime/pgp.c for some code which implements a subclass of camelsession.