# Is it wise to extend Matrix?

**URL:** <https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622>\
**Category:** ruby-talk\
**Created:** [14 December 2002 13:36 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622 "2002-12-14T13:36:11Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\
**Post date:** [14 December 2002 13:36 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622/1 "2002-12-14T13:36:11Z")

</div>

Since the thread “Inheritance question” has become so deep (physically 🙂 and  
my point is sort of orthoganal to it, new thread.

I personally don’t believe it makes sense to create a class that inherits from  
Matrix. Doing so would suggest to me that you are creating a new kind of  
Matrix. If you are, then perhaps you should visit a local mathematician to see  
whether there really is more than one kind of Matrix. Same goes for Array and  
probably some others.

In Jim’s case, he wanted to add some methods to Matrix. Well, he didn’t want  
to change Matrix directly, but the methods he was going to add would in no way  
be out of place in the real Matrix class, so to me, inheritance is the wrong  
approach. Delegation is the key here. Create a new class based on Matrix, add  
your methods, and forget that Matrix ever existed.

Of course, I think there are some implementation problems he had with the type  
that was returned from some methods - I lost track. But maybe he can come up  
with a new kind of delegation that solves that.

The Stack class in Java was an extension of Vector, which everybody’s favourite  
Ruby advocate Bruce Eckel (!) pointed out in his “Thinking in Java” is a  
stoopid idea. Whoever heard of a Stack having a method “elementAt(i)” ???

Anyway, I hope we see a satisfactory solution to Jim’s implementation problem.  
This kind of thing has been generating a lot of interest.

Cheers,  
Gavin

> **···**
>
> –  
> Gavin Sinclair Software Engineer  
> Sydney, Australia Soyabean Software Pty Ltd

---

<div class="post-metadata">

**Author:** ![David\_Alan\_Black1](https://avatars.discourse-cdn.com/v4/letter/d/278dde/32.png) [@David\_Alan\_Black1](https://rubytalk.org/u/David_Alan_Black1)\
**Post date:** [14 December 2002 14:09 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622/2 "2002-12-14T14:09:24Z")

</div>

Hi –

> Since the thread “Inheritance question” has become so deep (physically 🙂 and  
> my point is sort of orthoganal to it, new thread.
> 
> I personally don’t believe it makes sense to create a class that inherits from  
> Matrix. Doing so would suggest to me that you are creating a new kind of  
> Matrix. If you are, then perhaps you should visit a local mathematician to see  
> whether there really is more than one kind of Matrix. Same goes for Array and  
> probably some others.

I’ve always had a fondness for inheriting from Array and  
Hash… though, you point out in your example, it can be overkill,  
leaving an object with methods that really have nothing to do with it.  
But sometimes the fit is rather good – those core classes are core  
for good reasons. I’ve never thought of it in terms of claiming that  
there’s a new kind of Array or Hash; I see it more as just  
incrementally building on the available components of the language.

> In Jim’s case, he wanted to add some methods to Matrix. Well, he didn’t want  
> to change Matrix directly, but the methods he was going to add would in no way  
> be out of place in the real Matrix class, so to me, inheritance is the wrong  
> approach. Delegation is the key here. Create a new class based on Matrix, add  
> your methods, and forget that Matrix ever existed.

I spot an opportunity to learn more about delegation, something which  
I’ve never really absorbed. Can you elaborate a bit on the conditions  
under which delegating would be a better choice than inheriting in  
this example?

David

> **···**
>
> On Sat, 14 Dec 2002, Gavin Sinclair wrote:
> 
> –  
> David Alan Black  
> home: [dblack@candle.superlink.net](mailto:dblack@candle.superlink.net)  
> work: blackdav@shu.edu  
> Web: [http://pirate.shu.edu/~blackdav](http://pirate.shu.edu/~blackdav)

---

<div class="post-metadata">

**Author:** ![Russ\_Freeman](https://avatars.discourse-cdn.com/v4/letter/r/b77776/32.png) [@Russ\_Freeman](https://rubytalk.org/u/Russ_Freeman)\
**Post date:** [14 December 2002 14:36 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622/3 "2002-12-14T14:36:31Z")

</div>

> Of course, I think there are some implementation problems he had with  
> the type \>that was returned from some methods - I lost track. But maybe  
> he can come up \>with a new kind of delegation that solves that.

Isn’t there a Delegate mixin that can take the pain away?

Russ

> **···**
>
> * * *
> 
> Outgoing mail is certified Virus Free.  
> Checked by AVG anti-virus system ([http://www.grisoft.com](http://www.grisoft.com)).  
> Version: 6.0.422 / Virus Database: 237 - Release Date: 20/11/2002

---

<div class="post-metadata">

**Author:** ![Jim\_Freeze2](https://avatars.discourse-cdn.com/v4/letter/j/e480ec/32.png) [@Jim\_Freeze2](https://rubytalk.org/u/Jim_Freeze2)\
**Post date:** [14 December 2002 15:38 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622/4 "2002-12-14T15:38:41Z")

</div>

Yes, that is what I want. The Matrix class has a sticky issue since it  
uses a class method constructor. But, if I overlook that temporarily, I  
think the delegator class would need the ability to wrap functions that  
were chainable and return self. I believe it is as simple as that. But  
I have not come up with a good syntax for that and I don’t think I have  
had the ‘ah-ha’ moment about delegators yet.

> **···**
>
> On Saturday, 14 December 2002 at 22:36:11 +0900, Gavin Sinclair wrote:
> 
> > Since the thread “Inheritance question” has become so deep (physically 🙂 and  
> > my point is sort of orthoganal to it, new thread.
> > 
> > In Jim’s case, he wanted to add some methods to Matrix. Well, he didn’t want  
> > to change Matrix directly, but the methods he was going to add would in no way  
> > be out of place in the real Matrix class, so to me, inheritance is the wrong  
> > approach. Delegation is the key here. Create a new class based on Matrix, add  
> > your methods, and forget that Matrix ever existed.
> > 
> > Of course, I think there are some implementation problems he had with the type  
> > that was returned from some methods - I lost track. But maybe he can come up  
> > with a new kind of delegation that solves that.
> 
> –  
> Jim Freeze

---

<div class="post-metadata">

**Author:** ![Bulat\_Ziganshin](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Bulat\_Ziganshin](https://rubytalk.org/u/Bulat_Ziganshin)\
**Post date:** [15 December 2002 06:36 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622/5 "2002-12-15T06:36:28Z")

</div>

Hello Gavin,

Saturday, December 14, 2002, 4:36:11 PM, you wrote:

> Of course, I think there are some implementation problems he had with the type  
> that was returned from some methods - I lost track. But maybe he can come up  
> with a new kind of delegation that solves that.

i think just the same. current delegation classes never mind about this issue

> **···**
>
> –  
> Best regards,  
> Bulat [mailto:bulatz@integ.ru](mailto:bulatz@integ.ru)

---

<div class="post-metadata">

**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\
**Post date:** [14 December 2002 14:43 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622/6 "2002-12-14T14:43:52Z")

</div>

> I’ve always had a fondness for inheriting from Array and  
> Hash… though, you point out in your example, it can be overkill,  
> leaving an object with methods that really have nothing to do with it.  
> But sometimes the fit is rather good – those core classes are core  
> for good reasons. I’ve never thought of it in terms of claiming that  
> there’s a new kind of Array or Hash; I see it more as just  
> incrementally building on the available components of the language.

I used to inherit from HashMap in Java occasionally, but it always felt dirty.  
It’s great to built on the language’s components, but inheritance isn’t the  
only way to build. That’s one of my great realisations from Ruby. Inheritance  
used to be the path of least resistance. Now I treat inheritance as a  
significant design decision that has to be justified. I use it less than  
before, thus when it is used, its purpose is more clear.

> > In Jim’s case, he wanted to add some methods to Matrix. Well, he didn’t  
> > want  
> > to change Matrix directly, but the methods he was going to add would in no  
> > way  
> > be out of place in the real Matrix class, so to me, inheritance is the  
> > wrong  
> > approach. Delegation is the key here. Create a new class based on Matrix,  
> > add  
> > your methods, and forget that Matrix ever existed.
> 
> I spot an opportunity to learn more about delegation, something which  
> I’ve never really absorbed. Can you elaborate a bit on the conditions  
> under which delegating would be a better choice than inheriting in  
> this example?

Well, I think of inheritance as specialising a class (as in Car \< Vehicle).  
You encapsulate objects when you want to make use of them (so a Stack  
encapsulates an Array, as does a Matrix). I think of delegation as wholesale  
encapsulation - you want to use _all_ of an object. Thus, delegation provides  
all the methods you want, and gives you the opportunity to build on them. I  
was hoping to provide an example, but it’s getting very late and I’m fighting  
with the syntax.

Wholesale delegation and inheritance are only subtly different. I’d like to  
hear if you have reason to prefer inheritence in these situations. The Pickaxe  
reference section has some interesting examples on delegation.

Cheers,  
Gavin

> **···**
>
> From: [dblack@candle.superlink.net](mailto:dblack@candle.superlink.net)

---

<div class="post-metadata">

**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\
**Post date:** [14 December 2002 14:48 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622/7 "2002-12-14T14:48:42Z")

</div>

> > Of course, I think there are some implementation problems he had with  
> > the type \>that was returned from some methods - I lost track. But maybe  
> > he can come up \>with a new kind of delegation that solves that.
> 
> Isn’t there a Delegate mixin that can take the pain away?
> 
> Russ

Yes, he would begin with

require ‘delegate’

class MyMatrix \< DelegateClass(Matrix)  
# …  
end

and by examining the Pickaxe section on it, because when I tried delegating  
Array I had trouble instantiating my new class.

When I mentioned a “new kind of delegation” I meant that the return values of  
the delegated methods might be doctored (class-wise). I don’t know whether  
that would be an issue (as in the “Inheritance Question” thread) and I  
certainly don’t know if my off-the-cuff new-delegation thought would be  
feasible.

Gavin

> **···**
>
> From: “Russ Freeman” [russ@freesoft.co.uk](mailto:russ@freesoft.co.uk)

---

<div class="post-metadata">

**Author:** ![ts1](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@ts1](https://rubytalk.org/u/ts1)\
**Post date:** [14 December 2002 15:45 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622/8 "2002-12-14T15:45:45Z")

</div>

> Yes, that is what I want. The Matrix class has a sticky issue since it  
> uses a class method constructor. But, if I overlook that temporarily, I  
> think the delegator class would need the ability to wrap functions that  
> were chainable and return self. I believe it is as simple as that.

Yes, it is simple as that \*but\* the wrapped functions \*must not\* return  
self, but must return an object which is a delegator and this only in some  
special cases.

It's an error to return self.

Guy Decoux

---

<div class="post-metadata">

**Author:** ![Jim\_Freeze2](https://avatars.discourse-cdn.com/v4/letter/j/e480ec/32.png) [@Jim\_Freeze2](https://rubytalk.org/u/Jim_Freeze2)\
**Post date:** [14 December 2002 15:48 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622/9 "2002-12-14T15:48:05Z")

</div>

Sorry, but being new to delegators, can you show an example of “but must  
return an object which is a delegator…”

Thanks

> **···**
>
> On Sunday, 15 December 2002 at 0:45:45 +0900, ts wrote:
> 
> > > Yes, that is what I want. The Matrix class has a sticky issue since it  
> > > uses a class method constructor. But, if I overlook that temporarily, I  
> > > think the delegator class would need the ability to wrap functions that  
> > > were chainable and return self. I believe it is as simple as that.
> > 
> > Yes, it is simple as that _but_ the wrapped functions _must not_ return  
> > self, but must return an object which is a delegator and this only in some  
> > special cases.
> 
> ## – Jim Freeze
> 
> The computing field is always in need of new cliches.  
> – Alan Perlis

---

<div class="post-metadata">

**Author:** ![ts1](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@ts1](https://rubytalk.org/u/ts1)\
**Post date:** [14 December 2002 15:59 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622/10 "2002-12-14T15:59:12Z")

</div>

> Sorry, but being new to delegators, can you show an example of "but must  
> return an object which is a delegator..."

Here what do DelegateClass in delegate.rb

def DelegateClass(superclass)  
&nbsp;&nbsp;klass = Class.new  
&nbsp;&nbsp;methods = superclass.instance\_methods(true)  
&nbsp;&nbsp;methods -= ::Kernel.instance\_methods  
&nbsp;&nbsp;methods |= ["to\_s","to\_a","inspect","==","=~","==="]  
&nbsp;&nbsp;klass.module\_eval \<\<-EOS  
&nbsp;&nbsp;def initialize(obj)  
&nbsp;&nbsp;&nbsp;&nbsp;@obj = obj  
&nbsp;&nbsp;end  
&nbsp;&nbsp;EOS  
&nbsp;&nbsp;for method in methods  
&nbsp;&nbsp;&nbsp;&nbsp;klass.module\_eval \<\<-EOS  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def #{method}(\*args, &block)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;begin  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;@obj.\_\_send\_\_(:#{method}, \*args, &block)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rescue  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$@[0,2] = nil  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;raise  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EOS  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;&nbsp;return klass;  
&nbsp;&nbsp;end

All wrapped function return the result of

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;@obj.\_\_send\_\_(:#{method}, \*args, &block)

where @obj in your case is a Matrix Object

When you write

&nbsp;&nbsp;&nbsp;m = MyMatrix[[1,2],[3,4]]  
&nbsp;&nbsp;&nbsp;n = MyMatrix[[1,2],[3,4]]  
&nbsp;&nbsp;&nbsp;o = m + n

ruby will call the method #+ for @obj which is a Matrix and fatally the  
result is a Matrix when you want an instance of MyMatrix

Guy Decoux

---

<div class="post-metadata">

**Author:** ![Ara.T.Howard1](https://avatars.discourse-cdn.com/v4/letter/a/f19dbf/32.png) [@Ara.T.Howard1](https://rubytalk.org/u/Ara.T.Howard1)\
**Post date:** [14 December 2002 17:16 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622/11 "2002-12-14T17:16:58Z")

</div>

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](mailto:ahoward@fsl.noaa.gov)  
> > Phone: 303-497-7238  
> > Fax: 303-497-7259  
> > ====================================

---

<div class="post-metadata">

**Author:** ![ts1](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@ts1](https://rubytalk.org/u/ts1)\
**Post date:** [14 December 2002 17:30 UTC](https://rubytalk.org/t/is-it-wise-to-extend-matrix/3622/12 "2002-12-14T17:30:02Z")

</div>

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

Nothing wrong.

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

There is where you are wrong, it exist some case where it's inappropriate  
to always make this choice.

> interesting behaviour. coding Matrix in this way would not of changed the way  
> it functions \*and\* would have allowed subclassing for the irreverant.

No it will just give the possibility to have strange result :-)), like

&nbsp;&nbsp;&nbsp;&nbsp;A + Array ==\> A  
&nbsp;&nbsp;&nbsp;&nbsp;Array + A ==\> Array

> can get the job at hand done quickly in the fewest lines of code;

Yes, but nobody can predict the class of the result :-))

There are very good reasons for the actual behavior of Array.

Guy Decoux