Hi Ara,

ahoward <ahoward / fsl.noaa.gov> wrote:
> furthermore ( opinions were solicited earlier right? ;-) ) i would say this type of
> coding is not 'good' object oriented coding since, in order to create operator
> '+' for the parent class, knowledge of it's descendants was required.  we have
> alot of code like this in our shop and it's ____terrible____ to work with.
> consider that the header files for the parent class must include the header
> file for the derived class, which must include the header file for the parent
> class, which must include the header file for the derived class, which must
> incl.... (recurse here untill you get sick of it)

> it's header file __madness__.  only the preprocessor saves the day.

> you even have to maniplulate the build order since there are circular object
> dependancies - ouch.

> if this doesn't make sense to anyone - try writing this yourself

>   class parent;
>   class child;

>   child parent::operator + (parent anOther);

> when splitting the files out into *.h, *.cc files

I agree with what you said.  I also have been thinking of using "copy
constructors" in Ruby, but either going from parent to child or from child
to parent, it is really messy.  Besides, it seems that by default Ruby
does not like deep copy.

> my rule is this :

> use Has-A before Is-A whenever possible, when using Is-A -- think long and
> hard about it!!

Mmmm... as I don't know deep OO theory, I don't know what to say.  I think
on the discussions on contract/interface, there are people who advocate to
use Is-A instead of Has-A.

Regards,

Bill