[Evolution-hackers] Problems with camel
Not Zed
notzed@ximian.com
Fri, 04 Mar 2005 10:16:14 +0800
--=-Q3pB1Q7kNzP2D3f0cap7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
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.
--=-Q3pB1Q7kNzP2D3f0cap7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.5.7">
</HEAD>
<BODY>
On Wed, 2005-03-02 at 09:26 +0100, Søren Hansen wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">ons, 02 03 2005 kl. 09:38 +0800, skrev Not Zed:</FONT>
<FONT COLOR="#000000">> > > And that means actually subclassing it, you can't just create it and</FONT>
<FONT COLOR="#000000">> > > override the virtual methods manually.</FONT>
<FONT COLOR="#000000">> > Ok, this might be more of a GObject question, but why? I realize now</FONT>
<FONT COLOR="#000000">> > that I'm not *supposed* to instantiate it, but I don't understand that</FONT>
<FONT COLOR="#000000">> > it fails.</FONT>
<FONT COLOR="#000000">> It has nothing to do with GObject. It is unclear what failed, I</FONT>
<FONT COLOR="#000000">> presume it just crashed because you didn't build a concrete class.</FONT>
<FONT COLOR="#000000">Maybe it's just me being too much of and old school C programmer, but</FONT>
<FONT COLOR="#000000">"abstract", "concrete", "class" and "object" are not words in my regular</FONT>
<FONT COLOR="#000000">C programming vocabulary. Hence, I don't expect the programming langauge</FONT>
<FONT COLOR="#000000">or compiler to make sure that I can't create "instances" of "objects"</FONT>
<FONT COLOR="#000000">considered "abstract". </FONT>
</PRE>
</BLOCKQUOTE>
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).
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Obviously, there's something I don't understand.. :-)</FONT>
<FONT COLOR="#000000">The way I see it:</FONT>
<FONT COLOR="#000000">* CamelSession is a struct containing some fields.</FONT>
<FONT COLOR="#000000">* Among others, it contains a CamelSessionClass as the first field.</FONT>
<FONT COLOR="#000000">* A CamelSessionClass is a struct containing some fields.</FONT>
<FONT COLOR="#000000">* One of these fields is a function pointer called get_password.</FONT>
<FONT COLOR="#000000">When I create a new object of type CamelSession, I'd expect to be able</FONT>
<FONT COLOR="#000000">to access the get_password field, regardless of what it says in a</FONT>
<FONT COLOR="#000000">comment at the top of camel-session.h. :-)</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
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).<BR>
<BR>
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.<BR>
<BR>
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().<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">> Well, you must also remember camel is just an internal library, it has</FONT>
<FONT COLOR="#000000">> incomplete documentation for external use, and neither is the api</FONT>
<FONT COLOR="#000000">> guaranteed to be stable yet.</FONT>
<FONT COLOR="#000000">I know. I'm doing this any becuase I want to get to know Camel. It makes</FONT>
<FONT COLOR="#000000">it easier to understand the Evolution code, I think.</FONT>
<FONT COLOR="#000000">Also, I'm considering using camel as is, and I'm willing maintain the</FONT>
<FONT COLOR="#000000">glue code, so it shouldn't be too much of a problem if I can understand</FONT>
<FONT COLOR="#000000">Camel.</FONT>
</PRE>
</BLOCKQUOTE>
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.<BR>
<BR>
See tests/smime/pgp.c for some code which implements a subclass of camelsession.<BR>
<BR>
</BODY>
</HTML>
--=-Q3pB1Q7kNzP2D3f0cap7--