Go libraries are typically highly composable because they operate mostly on primitives or strictly defined common interfaces. Orthogonality is a key feature.
I'm quite sure the result will be quite different from what those kind of frameworks look like in other languages, but that could be interesting still.
You may be confusing interfaces (which enforce type compatibility) and the empty interface{}, which is effectively a dynamic type in the Go world.
One of the best examples of composability is the Reader and Writer interface. They're designed to operate on slices of bytes, so a package intended to read from a Reader can read from files, stdin, networks, sockets, and a myriad other systems with absolutely no changes to the package's code or its implementation.
{"purchaseType": "Rent","price": 0.99,"title": "inception"}
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE OverloadedStrings #-}
import Data.Aeson
import GHC.Generics
import qualified Data.ByteString.Lazy as BL
data PurchaseType = Free | Rent | Buy | Subscriber deriving (Show, Generic)
instance FromJSON PurchaseType
instance ToJSON PurchaseType
data Media = Media { title :: String, price :: Float, purchaseType :: PurchaseType} deriving (Show, Generic)
instance FromJSON Media
instance ToJSON Media
jsonData = "{\"title\": \"inception\", \"price\": 0.99, \"purchaseType\": \"Rent\"}"
main = print $ (decode jsonData :: Maybe Media)
-- running main gets:
-- λ> main
-- Just (Media {title = "inception", price = 0.99, purchaseType = Rent})
orderConfirmationMessage (Media mediaTitle _ Rent) = putStrLn ("Thanks for renting " ++ mediaTitle)
Main.hs:19:1-100: Warning: …
Pattern match(es) are non-exhaustive
In an equation for ‘orderConfirmationMessage’:
Patterns not matched:
Media _ _ Free
Media _ _ Buy
Media _ _ Subscriber
Getting to the point, my real questions are:
1. What is Go's way of ensuring your function handles cases like this, or is there an idiomatic way of avoiding it?
2. How do you discern between MovieType's without resorting to just using Strings and compromising type safety?
package main
import (
"encoding/json"
"fmt"
)
type Media struct {
Title string
Price float64
PurchaseType string
}
func main() {
jsonData := []byte(`
[
{"purchaseType":"Rent","price":0.99,"title":"Inception"},
{"purchaseType":"Free","price":0.00,"title":"Johnny Mnemonic"},
{"purchaseType":"Buy","price":17.99,"title":"John Wick"}
]
`)
var media []Media
err := json.Unmarshal(jsonData, &media)
if err != nil {
fmt.Println("error: ", err)
}
fmt.Printf("%+v\n", media)
}
$ go run main.go
[{Title:Inception Price:0.99 PurchaseType:Rent}
{Title:Johnny Mnemonic Price:0 PurchaseType:Free}
{Title:John Wick Price:17.99 PurchaseType:Buy}]
tl;dr The problem for me personally is when you start making functions based on the type of media and sacrifice type safety if MediaType is a string.
type PurchaseType byte
const (
Free PurchaseType = iota
Rent
Buy
)
func (t *PurchaseType) UnmarshalJSON(data []byte) error {
var s string
if err := json.Unmarshal(data, &s); err != nil {
return fmt.Errorf("purchase type should be a string, got %s", data)
}
have, ok := map[string]PurchaseType{"Free": Free, "Rent": Rent, "Buy": Buy}[s]
if !ok {
return fmt.Errorf("invalid purchase type %q", s)
}
*t = have
return nil
}
[{Inception 0.99 Rent} {Johnny Mnemonic 0 Free} {John Wick 17.99 Buy}]
That is just a really big one for me I wanted to share and get others opinion on. I guess I just feel like a lot of people don't realize how much having that stringly typed hole means. Perhaps others just disagree.
I would love to hear a counter argument for why others don't think this matters.
switch (someEnum) {
case foo:
<something>
case bar:
<something>
default:
throw DeveloperScrewedUpException("Unknown enum val: " + someEnum)
}