On Mon, 11 Nov 2002 dblack / candle.superlink.net wrote:

[snip]
> But what exactly would that mean in this case?  Does every method of
> every class have to return an object of that class?
[snip]

i don't understand this conclusion?

[snip]
> Child might have methods which return arrays, numbers, strings,
> self.class.new's, Parents, etc.  I don't think there's any way to
> universalize what should happen, though there may be scenarios I'm not
> thinking of.
[snip]

let me re-state what i was fishing for (i've been doing that alot lately -
perhaps i should be more explicit) :

i figure there are smarter people than me on this list designing the packages
we all know and love.  surely the good ones share some design patterns in
common?  i think one of the dangers of ruby is that it allows people who know
little about good object-oriented design (yours truely) to implicate subtle
relationships in their code, without meaning to.  in c++ one must **really**
understand all this, or core dumps and memory leaks ensue.  in forgiving ruby
the problems are less obvious but even harder to track down!  i've done alot
of OO programming and i've come to think of subclassing as a slippery slope,
about 1 degree from flat, which can take a very long time (and many lines of
code), to slide slowly down.

everyone's answer to my question of 'what is a good design strategy for
classes intended to be subclassed?' seems to be : 'there is no good answer,
there are too many possibilities...'

obviously, this cannot be the case.  it is just a very hard question.

surely there must be some good 'rules of thumb' for this problem set.  i've
suggested some of my own which, while restrictive, have helped me build
reliable libraries in C and C++.  surely the principles are not all that
different - ruby cannot do anything C can't after all.  ;-)

i suppose i'm looking for definitive answers from the 'Scott Meyers' of ruby.

will a Scott Meyers please stand up?  ;-)


[snip]
> This is a question of how much implementation will or should be shared
> with an antecedent class or module, and I think it's hard to make a
> rule for it.
[snip]

this is because implementation sharing is directly at odds with informatin
hiding, and why i stated that aggregation (or delegation) is often better than
subclassing - even if it is not so slick...


[snip]
> For example, if the super method consists of 'raise "Not implemented!"', you
> probably don't want to call it :-)
[snip]

this specific problem deals with designing interfaces - which are not directly
supported in ruby - so it's not really a fair objection.  the only reason for
doing the above is to catch what the compiler cannot.  if a method were purely
virtual then extending it would imply creating one in the first place and
'super' would, of course, not make sense.

-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
 ====================================