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.
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
