Newsgroups: comp.lang.smalltalk
Path: utzoo!utgpu!cunews!bnrgate!bqnes74!news
From: CWatts@BNR.CA (Carl Watts)
Subject: RE: method-ology
Message-ID: <1991Jun24.184824.9986@bqnes74.bnr.ca>
Sender: news@bqnes74.bnr.ca
Organization: Bell Northern Research
Date: Mon, 24 Jun 91 18:48:24 GMT

The closest analagous situation to your Matrix>qr question is Point>r
and Point>theta.

Thats where I would take my cue for answering the Matrix question.  You
could provide
two methods Matrix>q and Matrix>r which each answer the appropriate
matrix.

But, I suspect that your algorithm for calculating the q and r matrices
goes through a significant amount of work to calculate either matrix
and must calculate the other one along the way anyway.  And I think
that you are also saying that this is the reason you don't want to have
two separate methods Matrix>q and Matrix>r since then Smalltalk would
have to go through the whole calculation twice in order to get both
Matrices.

If thats true, then instead I would probably implement a method
Matrix>withQR: that accepts a single parameter which is a block of code
to be evaluated with the q and r matrices as parameters.

That way if "m" is a matrix then you would be able to say things like:

	m withQR: [:q :r | ...... ]

this gets around all the problems in your origional message.  You don't
have to make a method that answers an Array of two Matrices.  And
(horror of horrors) you don't have to make a method thats destructive
to the receiver or the method parameters.

Of course my Matrix>q and Matrix>r solutions are more elegant if my
assumptions about your algorithm are the reverse.  I would use these
two separate methods if the work for calculating q and the work for
calculating r can be separated.