[Tutor] What's in a name?

[Keith Winston]

On Fri, Jan 3, 2014 at 9:03 AM, spir <denis.spir at gmail.com> wrote:

> On 01/03/2014 12:41 PM, Alan Gauld wrote:
>
>>
>>           return [step, self.move_count, self.num_chutes,
>>> self.num_ladders, self.chutes_list, self.ladders_list]
>>>
>>
>> In OOP you rarely have to return attributes. And since step
>> is passed in as an argument the caller already knows [it]. So I
>>
>> don't think you really need to return anything here.
>>
>
Alas, it's uglier than all that, and probably inherently non-OOP organized.
The calling method DOES know the step variable (attribute? it's not part of
a class, is it still an attribute?), since it's using it to iterate through
a list: but that variable is gone by the time the play_game returns, and
yet I want to ensconce it in the data structure to keep track of the
different games... And so I pass it in to save it to the data structure.
It's ugly, and probably not the right way to do that (post script: I think
I figured this out below).

Calling method:
        return [self.play_game(i) for i in range(gamecount1)]

   def play_game(self, step):
        # various stuff happens, but step is just passed through to be
stored in the structure that the calling method is contributing to
        return [step, self.move_count, self.num_chutes, self.num_ladders,
self.chutes_list, self.ladders_list]



> Maybe the intent here (except from the case of step) is to conceptually
> isolate another part of code from the current object (here a 'game'), or
> from this method (play_game). So that don't they interact in a hidden way
> (that one cannot guess from the outside, without reading code in detail).
> In other words, to make code _transparent_, which is indeed a common advice
> (and one I approve).
>
> In this, to have the caller explicitely, obviously read information about
> the 'game' object, one could just:
>         return self
>
> However, this makes no sense if the caller the cirrent method, play_game,
> is another method of the 'game' ;-). In this case, indeed return nothing.
>
> (All this, if I correctly understand and interpret.)
>
> Denis


Well, I sort of mangle OOP still. Here's the issue: I have this play_game
method of Game, which returns/fills in the "results" of a game in the form
of a list of ints & lists. What I though I want is to play lots of games,
gather all those game "results" into a big array (just another list really,
of course), and then do stats/analsis on that array. But I think my
thinking is broken here: I am trying to create a list of game results,
whereas I should be creating a list of games (with their corresponding
attributes)... And that should happen altogether outside the Game glass. I
imagine I should have another class for that, say GameArray... but that's
just a first thought on the next reorganization...

So I guess my Game class should have an attribute like game_number,
corresponding to step variable above, and GameArray should do something
like...

game1 = Game() # instance of Game
for i in range(gamecount): game_array[i] = game1.play_game(i)

(inside play_game: self.game_number = i)

And I guess GameArray can hold all the stats/analysis/printing functions,
since that's the object they operate on...

This sounds like the right direction here, but I don't completely trust my
own thinking yet on this stuff. In retrospect, my need for a reset method
probably indicated I was going the wrong direction, and probably popped up
as soon as I tried to deal with a multitude of games within the Game class
itself.

thanks as always!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20140103/3453d3bd/attachment-0001.html>