From: ahoward <ahoward@...>
Date: 2002-12-14T01:50:22+09:00
Subject: Re: Inheritance Question


> >>>>> "J" == Jim Freeze <jim@freeze.org> writes:
>
[snip]
> J> Well, the way Matrix is setup, it makes even using DelegateClass
> J> difficult.
[snip]

i've come up against this on several occasions too.


it seems to me that a good general rule for writing classes seems to be :

**

'never call Class.method from any instance method lest ye be uninheritable'

**

for instance, if all calls to Matrix.method made from inside Matrix instance
methods are replaced with type.method - Matrix works identically and becomes
inheritable.  to me this seems abosolutely reasonable, though some would
claim class designers might want to enforce the return of a specific object
type from certain methods.  i would say this has NO place in Ruby for the
following reasons

  * Ruby classes are open so the whole thing is kindof moot any how

  * 99% of the time you have the actual sources - thus even 'mooter' ;-)

  * your class will work the same with 'type.method' vs 'Class.method'

  * if someone is inheriting your class they are breaking encapsulation anyhow
    (since inheritence opens up some of a class's internals to the inheriter)
    and it's up to *them* to maintain the semantics and behaviour of the
    inherited class ... it cannot affect the original

in fact, writing 'Class.method' from inside instance methods only _encourages_
people to hack your class to bits in an environment where both the sources and
Classes are open.

my 2 cents.

-a

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: ahoward@fsl.noaa.gov
 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================