Re: [curl-email-news] more followup on foundation class

[Dan B. <dbr...@wo...>]

gh...@nc... wrote:

> In PB we used inheritance extensively with transaction objects that
> handled database details and custom objects which implemented
> various specialized processing that could not be done with
> standard objects.  An example might be inplementing a spell
> check feature that picks up errors as you type.  I don't know
> enough about Curl at this point to suggest anything more specific
> but inheritance can definitely be useful with non-visual objects.

One example is the IMAP classes in the email client; there are
a couple of non-visual inheritance hierarchies there.

> I don't know of any compelling reason to use a function call to
> instantiate objects.  One reason I put those in my example
> package was that I was extremely pleased that I got them to work.
> Before I figured out that I had to give the constructor public access,
> the only way I could create the objects defined in the package was
> to use the function call method.  If you build the constructor (of a
> class defined in a package) with package visibility you can force
> any creation of the object outside of the package to go through a
> public access function which I thought was rather cool.

Note that Curl provides class factories, which may eliminate
the need for creating separate creation procs.  For example, you
may have a single concrete class at one point in your development.
Later, you may decide that you need some derived classes.
Putting a factory in the base class can allow it to return one
of the derived class objects when you need to instantiate one.
(The TextFlowBox classes do this, by the way.)

This isn't always the right approach, because it assumes you
can  update the base class code when you add a derived class,
and this isn't always the case.  (You can't add another class
derived from TextFlowBox and get the factory to return it.)

-- Dan