add rowsDo: and columnsDo:

[Ducasse]

No description provided.

[n1toxyz]

Can you elaborate what these methods are supposed to do in detail? Do they iterate from 1 to: width/height? This behavior would be in line with rowsAndColumnsDo:, but from the naming I would expect them to iterate over the values of each row or column; at least from the user perspective.

[Ducasse]

I do not precisely know. :)
Now I was indeed thinking that it can be nice to manipulate a full row and column.

[Ducasse]

What I see is that we have probably two differences uses of Array2D on bottom up and one top down.
When we want a grid for game it is better than the 1@1 element is bottom left and by default it is top left right now.

[n1toxyz]

Is this really a concern of the class and its API? When I think about an 2D array, probably because I am used to from other languages, I think about it like an array where I can address its fields with two indices (e.g. i and j). So lets assume some code like the following:

anArray2D at: 1 at: 2.

In this case I am accessing the field (1,2). Whether (1,1) is in the top left or bottom left doesn't matter. Both cases are valid and just a mental model of the developer. The API just allows access with two indices or a Point. As long as we think about the first index as the x of aPoint the API should have no problems in my opinion.

Of course the mental model of rows and columns switches this a bit around, as x specifies the column, but methods like rows or columns should not be the primary accessor of the array in my opinion, but a nice to have. Even then they can do an internal conversion to the correct index anyway, so that accessors like row:column: can be used.

[Ducasse]

I agree.
To me I prefer x and y because this is easier. Else I have to always think yes column is x.

I think that there are two typical usages:

• as a "low profile" matrix with two entries row/column or x/y and here it probably makes sense to have 1@1 = top left
  In this mode I naturally think top down.
• as a kind of cheap board game like space and having 1@1 as top left is annoying because the math origin is bottom left.
  The problem is when you iterate. For example in the current game I cannot well encapsulate the iteration without reinventing.
  Because I wanted to have 1@1 bottom left and iterate

123
456

as
456
123

May be this is just the mental representation of the problem that influences me.
Now Array2D does not let me choose the way to iterate.
In addition, sometimes I do not care of the coordinates so do: = doValues: (this is typically the case when I put a structured object knowing its position and sometimes I need xyvaluesDo:
In general I do not like blocks with a lot of arguments.

S.

[n1toxyz]

The problem is when you iterate. For example in the current game I cannot well encapsulate the iteration without reinventing.

I am afraid I don't quite follow your point here. I assume the game you are talking about is the lights out game from the Pharo by Example book. Is it then because of the graphics library, which assumes the origin in the top left and thus would draw the game board wrong? If so, couldn't we solve this with a simple decorator object that just does an origin translation? This might be useful in even more cases than this one.

But I understand your point about choosing how how to iterate. However, I do think we should choose one of the two or implement two different iterators, one for row/x first and one for column/y , and just set one as default, which can be swapped out for the other. This might give more flexibility.

[Ducasse]

This is not for the quinto game but I'm working on a new book. If you want to teach people programming you often start from math and in math the origin is at a different position. So yes as a programmer I can do all the quirks to get it work. Now it means that the data structure is not transparent to the learners and that you have explain accidental complexity while I would like to focus on the essential one. This is why I like that first element of a collection is at the index 1.

The decorator could be a nice trick. Because they are many ways we may want to iterate.

[n1toxyz]

Ok, now I get your point and I agree, but I do not have a good answer for this problem. My gut however favors the top down approach. Maybe because I am so used to it from other languages, but the other approach seems reasonable too.