[Newbies] Best way to implement two-dimensional array

[Bert Freudenberg]

On Sep 4, 2007, at 5:58 , John Almberg wrote:

> Hi Goran,
>
>> Mmmm, I feel I must ask the "why?" question here. :) What are you  
>> actually
>> trying to implement? The reason I ask is because it looks like you  
>> may be
>> falling into the trap of "data objects" (creating structures of  
>> data with
>> no real behaviors).
>
> Yes, that's an accurate description of what I'm trying to model:  
> the Movement Table from a very complicated, 'age of sail' board  
> game. The table models the speed of 9 classes of sailing ships at  
> various wind speeds, sail settings, damage, and points of sail.
>
> Thus it describes or summarizes some of the sailing attributes of  
> these 9 classes of ships. I've studied the table to see if it could  
> be computed, rather than simply stored, but I think the table  
> summarizes empirical data gleaned from historical records, rather  
> than a mathematical function, so not easy to model without a table.
>
> I have use polymorphism to break the one massive table into 9  
> smaller tables, one in each of the 9 classes of ships (children of  
> class Ship).
>
> I'm storing them in a class variable and using it, more or less, as  
> a constant lookup table. There isn't much behavior in the table  
> itself, but it models behavior, if you see what I mean.
>
> And there is plenty of other behavior in the ship classes, as you  
> can imagine.
>
> The real 'why' is fun. I've been wanting to learn Smalltalk and to  
> program a game like this for about 25 years. With Squeak on a Mac,  
> and a pile of Smalltalk books bought second-hand from Amazon, I'm  
> making some progress. With the side benefit of learning some new  
> tricks that help my Ruby programming (my day job).
>
>
>>> Or, I'm thinking it might be simpler to leave the literal as an
>>> array, and do the castings as necessary during access, like this:
>>
>> The word "casting" is not generally used in the Smalltalk context  
>> given
>> that Smalltalk is not statically typed. #as: is a message send and it
>> creates a new object of the given class. You can see what it does by
>> looking at Object>>as:.
>
> Sorry... still learning the Smalltalk jargon.
>
>> You can do it in several ways - it's just "code". If you only need  
>> Symbols
>> and literals as above you could use regular Array syntax (it only
>> evaluates literals - not expressions - and it is constructed at  
>> compile
>> time):
>>
>> | result dict |
>> result := Dictionary new.
>> #(
>> 	(fs (C 0  B 1  R 0))
>> 	(gs (C 7  B 5  R 4))
>> 	(gs (C 7  B 5  R 4))
>> ) do: [:arr |
>> 	dict := Dictionary new.
>> 	arr second pairsDo: [:a :b | dict at: a put: b].
>> 	result at: arr first put: dict].
>> result
>
> This is an interesting approach, too. I'm currently thinking that I  
> don't really need to store the data as a dictionary... my main  
> concern is to format the table(s) in a way that is easy for *me* to  
> read (so I can find and fix the inevitable typos.)
>
> I don't really care if the computer has to do some heavy lifting to  
> *access* the data. It's not something that has to be fast. So I'm  
> going to go for an approach that maximizes the human readability of  
> the data, and pushes the complicated bits into the accessors.

Well, since you are storing it in a class var, the "heavy lifting"  
can be done at initialization time. This way the code remains  
readable but you can do heavy pre-processing to bring that stuff into  
an easily accessible form. Btw, the "real" Smalltalk way would be to  
just create your data in the class var interactively using an  
inspector. The image will store these just fine. The problem with  
there may not be a simple way of transporting them along with the  
code into another image.

- Bert -