[Tutor] More or less final Chutes & Ladders

[spir]

On 01/04/2014 12:33 PM, Keith Winston wrote:
> Thanks Alan & Denis: Alan, the improvement you suggested had already been
> made, and adopted. Good catch.
>
> Denis: alas, there are chutes and ladders dicts, but I guess your chutes &
> ladders lists are local to the results class... Your suggestion is quite
> shocking to me, I wouldn't have thought of creating a class for results...
> I guess it allows clearer modularity of the final candl_array? I don't
> really get it... I think you are using it, essentially, for nothing other
> than a data structure, right? And some cleaner print options, though I have
> only looked at the raw game data for debugging... it's a great suggestion,
> obviously, because I am a little dumbfounded by it, and it's making me
> think.
>
> My initial reaction is concern about having too many classes, but I don't
> really have any sense of how important that is. I was playing with storing
> ChutesAndLadders instances in my game array, but of course they include all
> their methods, etc: all kinds of overhead (at least, that's my impression),
> which is why I created the results method, so I could just pass a... list?
> composite object? Collection? I can't really sort out what the latter two
> mean in Python, and must be looking in the wrong place... while I was
> researching I found out about namedtuple(), which seems like a promising
> structure for game data, but I haven't really looked into it. It might also
> be a collection...
>
> The entire game is to be played in bulk (that is, it's really a statistical
> foray, albeit a silly one), so the candl_array might get large (perhaps
> millions of "records" -- results lists). Is there some way the Results
> class helps that?

A class for results makes your global game result stats a plain list of result 
object, each with a clear composition / structure, with nicely self-commenting 
field names. What best could you dream of. A result is "by nature" (if I may 
say) a composite with well definite fields; think at a C struct.

Some may have different views, but I'd say it's worth making a class (custom 
object type) when:
* it defines conceptually and practically _composite_ elements, just like C 
structs or Pascal records,
* or, some type-specific methods are needed or useful.
(in fact string output methods are nearly always useful, for signicant elements 
or element types of an app, if only for your own feedback as programmer, in 
debugging, testing, diagnosing...)

An additional factor is, as in your case, that there are multiple such elements 
[*]. Usually, they are then stored in a collection (list, set, dict).

Denis

[*] Unfortunately, in python there are no individual composite objects: Python 
provides "class-based" OOP (as opposed to "prototype-based", or object-based if 
you like). In eg Lua or JS, you'd just write for instance:
	origin = {x=0, y=0, label="Origin"}
full dot. (And then access fields like 'origin.y', like in python for class 
instances.)
One can simulate that in python, or abuse dicts (however with annoying syntax), 
but in any  case it is not a feature of the language.