Re: [Evolution-hackers] Problems with camel

[Jeffrey Stedfast <fejj novell 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". 

they're not.

> 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 /pointer/

thus making ((CamelSessionClass *) session) an incorrect cast.

> * 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. :-)

yea, and you can... but that doesn't make it a safe thing to do.

Jeff