Some things are strongly typed and playing cards are among them. It is just that playing cards are strongly typed as playing cards, not integers or pairs of integers.
In blackjack:
case 10 => Jack or Queen or King or 10
case Ace => 1 or 11
case 10 => ace or 2 or 3 or 4 or 5 or 6 or 7 or 8 or 9 or 10 or jack or queen or king
case 2 => ace or 2 or 3 or 4 or 5 or 6 or 7 or 8 or 9 or 10 or jack or queen or king
case 4 => ace or 2 or 3 or 4 or 5 or 6 or 7 or 8 or 9 or 10 or jack or queen or king
Heh, same time as my edit. Those methods should be private (i.e. they just exist for building the deck, its the consumers responsibility to shuffle / split into multiple decks etc, as well as assigning value to each card).
So what then does 13=king get me over king=king? And does forgetting to privatise implementation details suggest that the necessary language idioms make the data structure complex in a way that is orthogonal to the real world complexity of the objects it represents, and wasn't the opportunity to avoid that complexity the advantage suggested by the author. To put it another way, private and sealed and trait don't reflect characteristics of a deck of playing cards. They are overhead from the language. It is a case where a static type system, because it is biased toward it's and strings and objects, makes it more difficult to reason about our code - leaving jokers aside, how much of the Scala code makes sense if I want to play Pinnocle versus the data approach advanced by the author? Now I'll admit that Lisp has shaped the way I see the two approaches to representing cards. and this may be why I see implementation of jokers and pinnocle as easy extensions of lists and rather more complex under an object system with static type checking. But I will point out that this model got me to thinking about card games rather than card data types pretty quickly, and card games are probably the reason we're draining the swamp.
Yep, valuation can be simply a function, but wrapping in a typeclass might work as well.
Does that 'or' method actually exist in a library somewhere or was it just for illustration?
Just for illustration. But to the author of the article's point that programming languages structure our thinking, the idea that "or" must be either in the core language or part of some library illustrates the constraints imposed on expressing our ideas absent the ability to introduce new syntax via a lisp-style macro facility. In a sense, Clojure's light weight data structures can be seen as extending up into the language.
Re:Clojure vs. Scala
by dragonwriter on Tuesday December 24, 2013 @03:11PM
(#6960950)
> I'd say the 'numberToRank' parts are probably code smells, but given that its Christmas Eve, I really can't be bothered to think of a better solution right now.
object Cards {
sealed trait Suit
case object Spades extends Suit
case object Clubs extends Suit
case object Hearts extends Suit
case object Diamonds extends Suit
sealed trait Rank
trait FaceCard extends Rank
case object Jack extends FaceCard
case object Queen extends FaceCard
case object King extends FaceCard
case object Ace extends FaceCard
case class ValueCard(n: Int) extends Rank
case class Card(rank: Rank, suit: Suit)
type Deck = IndexedSeq[Card]
val faceCardRanks = IndexedSeq(Jack,Queen,King,Ace)
val valueCardRanks = for (rank <- 2 to 10) yield ValueCard(rank)
val ranks = IndexedSeq.concat(valueCardRanks,faceCardRanks)
val suits = IndexedSeq(Spades,Clubs,Diamonds,Hearts)
def apply(): Deck = for(rank <- ranks; suit <- suits) yield Card(rank, suit)
}
edit: I'd say the 'numberToRank' parts are probably code smells, but given that its Christmas Eve, I really can't be bothered to think of a better solution right now. Implementing ordering etc can be done on the traits very easily too, but that is game specific (for example are aces high or low, is a King ranked higher than a Jack etc).