fellow rubyists-

i've been out of this thread for a while, but i wanted to back up a bit and
ask _again_ what people find so fundementally wrong with the paradigm of
creating classes as in :


    class PotentiallyExtended

      def PotentiallyExtended.class_method
	PotentiallyExtended.new
      end

      def instance_method
	type.class_method
      end

    end


classes which do this are certainly better *candidates* for subclassing.  in
the Marix case, it may or may not be the best idea due to the associative
properties of some of operators but that is not the point.  if class designers
hardwire classname.methodname into instance methods they forbid all sorts of
interesting behaviour.  coding Matrix in this way would not of changed the way
it functions *and* would have allowed subclassing for the irreverant.  i know
people get religious about subclassing but the fact remains that, regardless
of the design principles, it can sometimes be the case that

    class MyClass < Array
    end

or even

    class MyClass < Matrix
    end

can get the job at hand done quickly in the fewest lines of code; bearing in
mind that the number of code lines is *also* a measure of design that many
scientific studies have shown to be one of the more important ones.

getting back to the Matrix example, i'd like to see an example of Delegation
in the case of the '+' method which provides this behaviour :

    p (MyMatrix[] + MyMatrix[]).type    # >> MyMatrix

i'm not saying it can't be done... i'd just like to see an example on par in
complexity with the subclassing method.

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