"indexed properties"...

[David C. Ullrich]

On Sun, 18 May 2008 08:50:23 +0200, pataphor <pataphor at gmail.com>
wrote:

>In article <hjlt245hnhrle11khpupg6fppr000f8f51 at 4ax.com>, 
>dullrich at sprynet.com says...
>
>> >>   window.pos = (x,y)
>> >>
>> >> seems more natural than
>> >>
>> >>   window.SetPos(x,y);
>
>Yes, and to assign a row in a matrix I'd also like to use either tuples 
>or lists on the right side. 

Heh - in the current (flawed) implementation you can
say m.row[0] = 'Hello'; m.row[1]= 'World!' .Not that I see why 
you'd want to, but that happened in the test code just to
check that things were as general as I wanted - sure enough
m.row[0] + m.row[1] comes out to ['HW', 'eo', 'lr', ''ld', 'o!'].

>>   def __add__(self, other):
>>     return Row([x + y for x, y in zip(self, other)])
>> 
>> worked as hoped if self is a Row and other is a
>> Row _or_ a list.)
>> 
>> Anyway, my m.rows[j] can't be a list, because
>> I want to be able to say things like
>> m.rows[0] += c*m.rows[2]. Allowing 
>> m.rows[j] = [1,2,3] seems convenient, while
>> requiring m.rows[j] = Row([1,2,3]) fixes
>> this problem. Hmm.
>
>I'm not sure how far you'd go along with Gabriel's idea of decoupling 
>views from data but I think there isn't even a need for using a matrix 
>as the underlying data type. Why not use a flat list and compute matrix 
>positions according to a row or column adressing scheme on the fly? 

Is there some reason that would be better? It would make a lot
of the code more complicated. Ok, it would require only one
bit of added code, I suppose, but I don't see the plus side.

Hmm. It might actually _reduce_ the total amount of code,
since the code to access columns has to exist anyway and
rows could use the same code as columns with different
"start" and "skip". And come to think of it rows and
columns could be obtained just with a slice of the data.
So column access might even be more efficient. But I
expect that row access will happen a lot more often
than column access.

>P.

David C. Ullrich