> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Blake
> Sent: Saturday, September 10, 2005 4:17 AM
> To: The general-purpose Squeak developers list
> Subject: Re: Miscellaneous questions...
> 
> These were some great answers, guys, thanks. I'll have a lot more the more
> I write.
> 
> > I would not use any primitive value type object to represent suit or
> > rank. I would use objects, i.e. a Heart object and a King object. Doing
> > so
> > makes it much easier to do reasoning and comparisons between cards.
> >
> > I am from the old school and used to start out using symbols, numbers,
> > or strings to represent state.  I eventually found out that real
> > objects do a much better job. Rather change my code from some value
> > type of representation to a real object after I found out I need it,
> > I think it is better to just start off that way.
> 
> I see the logic of this, but I'm not 100% sure I agree.
> 
> The point of having a multiple objects versus a single object would be if
> the cards behaved differently. But not only do they not behave
> differently, they only meaning in a larger context. You can't ask the Ace
> if it's higher or lower than the Jack, for example, because the Ace
> doesn't know. You can't ask the Ace if it's okay to play itself, because
> it depends on whether it's Poker, Solitaire, Go Fish, or whatever.

True, but I think you would find that your game code would be better
composed if the representation was a real object.  In the simple case
the rank object would have a string used to display itself, i.e. Jack,
and maybe a rank number used for comparing cards.  Obviously, as you point
out, the Ace would have to he handled specially. You could also have
different rank objects for different games.

But, you will have to come to this realization yourself.  It only took
me 14 years of ST programming to figure this out. :-) My problem is
that I hate adding complexity and to me using objects instead of values
increases complexity, so I resisted.  But, I have seen too many situations
where initially it seemed that a value was simpler and would suffice, but
later it turned out not to be the case.

> You could say Rules->Deck->Card, because its the rules that determine the
> relative value of the cards and the composition of the deck. The deck,
> really, is always going to behave the same. It's just a holder. Its job is
> to keep track of the cards, shuffle and deal.
> 
> Now, if you were making a Magic: The Gathering-type game, yeah, objects
> for cards--a real hierarchy to boot. And the Deck object should be able to
> handle that. The rules, however, would determine base play, while
> deferring to the rule changes specified by the cards.