From: james@...
Date: 2002-07-05T12:19:19+09:00
Subject: RE: self_parent

>
> hi james,
>
> isnt this simply a matter of design? and one that is really inherit in
> OOP? when i inherit a class or mixin a module, i am depending on certain
> instances and methods to exist. that's the nature of OO designs, in
> order to achive code reuse. its a given that if you change one thing
> somewhere you can break something that depends on it. that's always a
> consideration, self_parent or no.

Yes, if A creates B, and B changes its interface, A has a problem. That's
expected, and why interfaces of base classes shouldn't change without a
good reason.  But, B should not break because A changes.

Suppose Ruby has self_parent, and people start using it.  You write a class
that calls somebody else's code.  Your application works.  Can you safely
change your code in the future? If the 3rd-party class is using self_parent
to call some of your object's methods, then you might have an unplanned
dependency.  If you are required to *explicitly* pass an object reference
to another class, then you know up front what the dependencies are.

Likewise, if I write code that inherits from a super class, the author of
that class knows that changes can break subclasses.  But changes to a
subclass shouldn't break the super class.

self_parent, as used in your example, means that the parent class must know
too much about how the other class is implemented.  Dependencies are a part
of OO, but not something to be actively encouraged.


James

>
> ~transami
>
>