[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OO should break when broken(was re: the benefits ofimmutability)
At 8:50 AM -0700 9/1/03, James McCartney wrote:
>On Monday, September 1, 2003, at 04:05 AM, Geoffrey Knauth wrote:
>
>>This reminds me of something that bothers me about OO: the
>>accumulation of unused stuff. When I extend Circle to make
>>Ellipse, I add x-radius and y-radius, but the original radius
>>instance variable is still there. Since I'm not going to use
>>Circle's radius any more, I wish I could just ask it to go away, if
>>the compiler or runtime could verify it isn't needed by methods I
>>decide not to override.
>>
>
>If you are in this situation it means that you probably should have
>had an abstract class which is a common ancestor of these two
>classes.
I dunno. If you look on OO programming as a form of
programmer-directed, static genetic programming where the
programmer's determining the behaviour of child classes rather than
letting darwininan-weighted random chance determine the behaviour, it
makes perfect sense to want to obscure or block parent class methods,
rather than factoring the parent class into multiple classes (which
can be a pain with no MI, or can lead to the degenerate case where
you're inheriting from a zillion single-method classes, which makes
sharing instance data a bit problematic)
Of course, if you don't look at it like that, this makes no sense. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk