[Tutor] rockpaperscissors

[ahimsa]

On Sun, 2003-01-26 at 23:03, Sean 'Shaleh' Perry wrote:

> what you have here is a classic programming "mistake".  You are combining two 
> problems in one function and as a result have loss your flexibility.

That's what I dig about this list: you folk are *really* helpful. Thank
you.

> The function results() both determines who wins *AND* is responsible for 
> reporting this data.  Here is where you went wrong.  If you had separated 
> this the print step would be rather simple.  Splitting the function would 
> also let you reimplement this program as a server for a distributed network 
> play version.

OK you lost me about the "distributed network play version", but no
doubt I'll pick that up at some point. I *do* get your point about
splitting the function up: I think that I was believing that doing it
the way I did it was parsimonious - but evidently not. 

> What you find is that splitting functions so they only do one thing (same with 
> classes and their methods) you can mix and match functions for bigger and 
> better programs.

You are right Sean, and y'know now that I reflect on this I can kick
myself because I had just finished reading about the wisdom of designing
a function to do one thing really well (which, if I'm not mistaken is
also locally referred to in Linux circles as the 'Unix Way'?), and then
to add one function to reference another function in a kind of
'daisy-chain' linkage. Having made the error, I can begin to get a
clearer sense of both what not doing it looks like as well as the wisdom
of doing it properly.

> I would have made a "who won" function and a separate "print output function".
> The print output is much simpler because it just has to say "noun verb noun, X 
> wins over Y".

Hmmm - I'll think about that for a while. I might do it like that also,
but want to think it over a bit first.

> You could also store the strings in a dictionary/list to make the lookup a 
> little cleaner.
> 
> objects[] = (("paper", "covers"), ("rock", "breaks"), ("scissors", "cut"))
> 
> This is very common in games where the object list can grow and grow like role 
> playing games.

Now I like that idea. Haven't reached the section in my work books that
deal with Dictionaries in depth, but might be worthwhile to work on it a
bit more this weekend. Neat idea - that does appeal to me aesthetically.


> That is why this list exists.  However please send the code as an attachment 
> that way various people's email programs do not reformat or munge the code.  
> Many people read email in a mailer which uses TTF fonts and this makes code 
> reading difficult because the lines do not line up how they would in a fixed 
> point code editor.

Fair enough - I guess as a regular text file should suffice. 

> Since Python is indentation sensitive this is even more important.

Agreed. And thanks :-) That was useful to me.

Andrew

-- 
ahimsa <ahimsa@onetel.net.uk>