Luku 4.3: Olemattomia arvoja

Jatkoa viime numerosta

Jäimme tilanteeseen, jossa ohjelma kaatui, koska yritimme katsoa viittauksen kautta kokemusolion arvosanaa — another.rating — mutta another-muuttujan arvona olikin null eli ei viittausta mihinkään. Tämä siksi, että ensimmäistä kokemusoliota lisättäessä kategorialla ei vielä ole suosikkia, minkä merkitsemiseen käytimme null-arvoa.

Tietokone ei osaa itse päätellä, miten sen pitäisi suoriutua tapauksesta, jossa edellistä suosikkikokemusta ei ole. Ohjelmoijan pitää tämäkin erikseen kirjata koodiin. Viimelukuisessa algoritmissamme emme huomioineet lainkaan tätä mahdollisuutta.

Tässä kaksi erilaista mahdollisuutta korjata tilanne:

Käytetään jotakin toista tietotyyppiä, jonka avulla voi kuvata sitä, että "suosikilla on nolla tai yksi arvoa".
Käytetään olemattoman olion merkkinä null-arvoa, jonka voi sijoittaa (melkein) minkä vain tyyppiseen muuttujaan. Kuitenkin muistetaan varmistaa muilla käskyillä, ettemme yritä käsitellä olemattoman olion piirteitä.

On perusteltavissa, että ensimmäinen vaihtoehto on usein parempi. (Perustelut alempana.) Kohta tarkastelemme erästä tällaista ratkaisutapaa Category-ongelmaamme. Aloitetaan kuitenkin tutustumalla yleisemmin ratkaisun välineeseen.

Inspiraatiota `lift`-metodista

On hyvin yleistä, että jokin asia voi "olla ehkä olemassa". Tällaisia tilanteita löytyy vaikkapa Scalan peruskirjastoista: vektorin alkio indeksillä sata voi joko olla olemassa (riittävän suuressa vektorissa) tai olla olematta (pienemmässä).

Onhan meillä tämä tuttu tyyli tutkia kokoelman alkioita, mutta monesti on ikävää, että se kaatuu liian suureen tai negatiiviseen indeksiin:

val sanoja = Vector("eka", "toka", "kolmas", "neljäs")sanoja: Vector[String] = Vector(eka, toka, kolmas, neljäs)
sanoja(2)res0: String = kolmas
sanoja(100)java.lang.IndexOutOfBoundsException: 100 is out of bounds (min 0, max 3)
  [...]

Voisiko olla metodi, joka kertoo meille yhdellä kertaa 1) onko vektorissa alkiota tietyllä indeksillä vai ei, ja 2) jos on alkio, niin mikä?

Voisi olla ja on. Sen nimi on lift.

sanoja.lift(2)res1: Option[String] = Some(kolmas)
sanoja.lift(100)res2: Option[String] = None
sanoja.lift(-1)res3: Option[String] = None

Paluuarvot näyttävät aika järkeviltä:

Kun alkio löytyy, paluuarvo on "joku merkkijono, tarkemmin sanoen kolmas".

Kun alkiota ei löydy, paluuarvo on "ei arvoa lainkaan". Huom. Tämä ei ole sama kuin null; palataan siihen vielä.

Vaikka indeksi olisi epäkelpo, liftaaminen ei keskeydy ajonaikaiseen poikkeustilanteeseen. Metodilla voi poimia alkion indeksin osoittamasta kohdasta turvallisesti.

Paluuarvot eivät kuitenkaan ole tavallisia merkkijonoja vaan jotakin muuta.

lift-metodi nojautuu Option-nimiseen tietotyyppiin. Selvitetään, mikä se on ja miten se voi auttaa meitä korjaamaan Category-luokan.

Suosikkikirjanpito: uusi toteutus

`Option`-tyyppinen ilmentymämuuttuja

Palataan Category-luokkaan. Sinne voi määritellä ilmentymämuuttujan fave näin:

class Category(val name: String, val unit: String):

  private val experiences = Buffer[Experience]()
  private var fave: Option[Experience] = None

  def favorite = this.fave

  def addExperience(newExperience: Experience) =
    // Toteutus tänne.

end Category

Asetetaan fave-muuttujan tyypiksi Option[Experience] eli "mahdollisesti yksi kokemus tai sitten ei yhtään". Tämä määrittely vastaa täsmälleen mallinnustarvettamme.

Muuttujan arvo voi siis olla joko None tai Some(…), missä "kääreen" sisällä on viittaus Experience-olioon. Aluksi se on None.

Uusi toteutus `addExperience`-metodille

Toteutetaan addExperience-metodi ensin pseudokoodina:

  def addExperience(newExperience: Experience) =
    this.experiences += newExperience
    Suosikin päivittämistapa riippuu siitä, mitä suosikkikääreestä nyt löytyy:
    1) Mikäli ei löydy mitään, merkitään suosikiksi Some, jossa on lisätty uusi kokemus.
    2) Mikäli kääreessä on vanha suosikki, valitaan uudesta kokemuksesta ja vanhasta suosikista parempi ja kääritään se.

Kaksi tapausta: this.faven vanhana arvona on vain tyhjä kääre None tai jokin Some-kääritty vanha suosikkikokemus.

Option[Experience]-tyyppisiä arvoja ei voi vertailla arvosanan perusteella, Experience-tyyppisiä voi. Jotta vertailu onnistuisi, on vanha suosikki otettava Option-kääreestä ulos.

Tässä sama Scalalla:

def addExperience(newExperience: Experience) =
  this.experiences += newExperience
  this.fave match
    case None =>
      this.fave = Some(newExperience)
    case Some(oldFave) =>
      val newFave = newExperience.chooseBetter(oldFave)
      this.fave = Some(newFave)

Lisäyksen lopuksi kategoriaolioon liittyy väistämättä jokin suosikkikokemus. Se tallennetaan Some-kääreeseen ennen ilmentymämuuttujaan tallentamista (koska uusittuun fave-muuttujaan pitää tallentaa Option[Experience]-tyyppinen eikä Experience-tyyppinen arvo).

Kuten näet, match-käskyn sisällä voi myös määritellä apumuuttujia tavalliseen tapaan. Tässä on käytetty tilapäissäilöä newFave välivaiheiden selkiyttämiseksi, mutta koko homman olisi voinut hoitaa myös yhdellä käskyllä this.fave = Some(newExperience.chooseBetter(oldFave))

Sama toisin jäsennettynä

Voit tutkia myös tätä toista toteutusta, joka toimii yhtä lailla ja on kenties nätimpi. (Makuasia.)

def addExperience(newExperience: Experience) =
  this.experiences += newExperience
  val newFave = this.fave match
    case Some(oldFave) => newExperience.chooseBetter(oldFave)
    case None          => newExperience
  this.fave = Some(newFave)

Muutos luokan rajapinnassa

Äsken tehtyä Category-toteutusta (joka myös GoodStuff-moduulin tiedostoista löytyy) käytetään hieman eri tavalla kuin edellisessä luvussa hahmottelimme.

Nythän nimittäin favorite-metodin paluuarvon tyyppi on Experiencen sijaan Option[Experience], ja metodi palauttaa joko Nonen tai kokemusolioon viittavan Somen. Luokkaa käyttäessä on huomioitava tämä muutos. Uutta Category-luokkaamme voi koekäyttää vaikkapa näin:

val wineCategory = Category("Wine", "bottle")
// ... (Mahdollisesti lisätään kokemusolioita kategoriaan.)

wineCategory.favorite match
  case Some(bestWine) =>
    println("Suosikki on: " + bestWine.name)
  case None =>
    println("Ei suosikkia vielä.")

Toisaalta esimerkiksi lauseke wineCategory.favorite.name ei enää ole kelvollinen kuten ei sovi ollakaan. Jos yritämme kirjoittaa tuon käskyn ohjelmaamme, saamme virheilmoituksen jo ennen ohjelma-ajoa: työkalustomme toteaa, että wineCategory.favorite tuottaa Optionin, jolla ei ole name-muuttujaa (vaan sen ehkä sisältämällä Experience-oliolla on).

Vaihtoehtoinen toteutustapa ilman `Option`ia

Kuten luvun alussa tuli todettua, on toinenkin tapa lähestyä poikkeustilanteen aiheuttanutta null-ongelmaa: jätetään null-alkuarvo suosikille, mutta käytetään käskyjä huolellisesti niin, ettei olemattoman olion piirteisiin koskaan yritetä päästä käsiksi. Esimerkiksi addExperience-metodin olisi voinut saada toimimaan myös ilman Option-luokkaa:

class Category(val name: String, val unit: String):

  private val experiences = Buffer[Experience]()
  private var fave: Experience = null

  def favorite = this.fave

  def addExperience(newExperience: Experience) =
    this.experiences += newExperience
    this.fave =
      if this.fave == null then
        newExperience
      else
        newExperience.chooseBetter(this.fave)

end Category

Kun ensin tarkastetaan vertailuoperaattorilla, onko olion fave-muuttujan arvo null, ja sijoitetaan paremmuusvertailu else-olioon, ei metodimme tee sopimatonta paremmuusvertailua olemattoman arvosanan kanssa. Tämäkin metoditoteutus toimii moitteettomasti.

Et sitten aikaisemmin kertonut!?

Eikö tuo null-arvoa käyttävä versio ole yhtä toimiva ja yksinkertaisempi kuin Option-versio? Monimutkaistiko Option Category-luokkaamme aivan turhaan? Kannattiko tätä uutta tekniikkaa edes opetella?

Option-toteutuksessa on erittäin hyviä puolia null-toteutukseen verrattuna. Käsittelemme seuraavaksi niistä eräitä.

Miljardin dollarin virhe

Kutsun null-viittauksen keksimistä vuonna 1965 miljardin dollarin virheekseni. Suunnittelin silloin ensimmäistä kattavaa tyyppijärjestelmää viittauksille olio-ohjelmointikielessä (ALGOL W). Tavoitteeni oli varmistaa, että kaikki viittausten käyttö olisi ehdottoman turvallista. — — Mutta en pystynyt vastustamaan kiusausta ottaa null-viittaus mukaan pelkästään siksi, että se oli niin helppo toteuttaa. Tämä on johtanut lukemattomiin virheisiin, haavoittuvuuksiin ja järjestelmien kaatumisiin, jotka ovat luultavasti aiheuttaneet miljardin dollarin verran tuskaa ja vahinkoa neljänkymmenen viime vuoden aikana.

—C. A. R. Hoare (käännetty englannista)

Yllä on lainaus puheesta vuodelta 2009, jossa Sir Charles Antony Richard Hoare pyytää anteeksi null-arvon keksimistä alun perin ALGOL-ohjelmointikieleen. ALGOLista on otettu valtavasti (enimmäkseen hyviä) vaikutteita myöhempiin ohjelmointikieliin, nykyisiinkin. Myös null-arvo tai sitä vastaava toisen niminen käsite on ohjelmointikielissä yleinen. Kuitenkin null-viittausten käyttö aiheuttaa joka päivä jotakuinkin vastaavia ajonaikaisia virhetilanteita kuin se, jonka näit edellisen luvun lopussa. Usein nämä virheet ovat monimutkaisemmissa ohjelmissa ja hankalammin paikannettavia kuin esimerkissämme.

Eräät ohjelmoijien piirissä tunnetuimmat ja pahamaineisimmat virheilmoitukset (esim. segmentation fault ja edellisen luvun null pointer exception) liittyvät ohjelmoijan tekemiin null-arvojen käyttövirheisiin.

Miksi `Option`?

Kuten olet jo nähnyt, Scala-kielikin mahdollistaa null-arvojen käytön. Kieli on kuitenkin laadittu kannustamaan vaihtoehtoisiin ratkaisuihin, joista Option on yksi. null-arvon käyttö on (hyvissä) Scala-ohjelmissa harvinaista.

Kun lausekkeen tyyppinä on Option[X] eikä vain X, emme voi yksinkertaisesti käyttää sitä kohdassa, jossa kaivataan X-tyyppistä arvoa. Yritys tehdä näin aiheuttaa virheilmoituksen jo ennen ohjelman ajamista. Niinpä ohjelmoijan on huolehdittava "kääreen avaamisesta". Tämä muistuttaa häntä käsittelemään myös None-tapauksen, jossa "kääreessä" ei ole arvoa lainkaan.

Esimerkiksi kun Categoryn favorite-metodi palauttaa Option[Experience]-tyyppisen arvon, on tämä selvä signaali luokkaa käyttävälle ohjelmoijalle: suosikkia ei välttämättä ole, ja molemmat tapaukset pitäisi jotenkin huomioida metodia käyttäessä. Jos ohjelmoija asian silti jättää huomioimatta, hän saa pikaisen virheilmoituksen eikä ongelma jää bugiksi ohjelmaan ja ilmene kenties vasta epäonnisen loppukäyttäjän kärsiessä siitä joskus myöhemmin.

Voi olla, että saamme luokan kuten Category toteutettua null-arvoja käyttäen siten, että tuon luokan metodit huolellisesti valvovat ettei virhetilanteita synny. Silti ongelma ei poistu, jos luokan rajapintaan kuuluvat metodit (kuten favorite) palauttavat null-arvoja. Luokan käyttäjän, joka voimme olla me itse tai joku muu, pitää muistaa olla varpaillaan niiden varalta.

Jos olet ohjelmoinnin aloittelija tai paatunut null-arvoilla ohjelmoija, et ehkä aavistakaan, kuinka monelta ongelmalta vältyt käyttämällä "ehkä olemattomien arvojen" kuvaamiseen Optionia.

Virheilmoituksista

Option-ratkaisumallin hyväksi puoleksi mainittiin se, että saa virheilmoituksia. Se saattaa kuulostaa oudolta.

Ohjelmoinnin aloittelija voi pitää virheilmoituksia puhtaasti ikävinä. Mutta ennen ohjelma-ajoa tuleva virheilmoitus on ystäväsi! Se tarkoittaa, että tietokone on kyennyt automaattisesti havaitsemaan ohjelmassa jonkin ongelman. On hienoa, että saat viestin — vaikka sitten valituksenkin — välittömänä palautteena. Ajonaikaisten virheiden syiden etsiminen on usein paljon hankalampaa, ja jo niiden havaitseminen on kaikkea muuta kuin itsestään selvää.

Hyvä osa siitä Tony Hoaren miljardista olisi säästetty aikaisemmilla virheilmoituksilla.

Lisämateriaalia `Option`in ympäriltä

Seuraavat laatikot täydentävät äskeistä tekstiä. Lue, jos ei ole liian kiire.

Onko Option vain Scalan ja sen lähisukulaisten erikoisuus?

Ei. Sama tai samantapainen rakenne on käytettävissä monessa muussakin kielessä. On yleistymään päin.

Useissa yleisissä kielissä (esim. C, Java) kyllä käytetään usein null-arvoja, joskus syystä (ks. seuraava lisätietolaatikko alla) ja joskus syyttä. Tuoreimmissa Java-kielen versioissakin on eräänlainen Optional-luokka. Nähtäväksi jää, millaisen käyttäjäkunnan se saavuttaa.

Tämä ei ole puhtaasti kielikysymys. Jos Option-luokkaa tai vastaavaa työkalua ei ole, mutta sellaista haluaa käyttää, niin sellaisen voi tehdä itsekin. Scalassakaan Option ei varsinaisesti ole muuta kuin peruskirjastoon kuuluva luokka. Alla on Optionin, Somen ja Nonen lähdekoodi karsitussa muodossa niiltä osin, joita kurssilla on tähän mennessä käsitelty.

Seuraavaa koodia ei ole pakko kokonaan ymmärtää, mutta se toimii näyttönä siitä, että jos tämä tyyppi Scalasta puuttuisi, niin sen toteuttaminen ei olisi mikään taikatemppu. Itse asiassa iso osa tästä koodista on jo tämän kurssin alkupään perusteella ymmärrettävissä.

abstract class Option[InnerType]:
  def getOrElse(default: =>InnerType) = if this.isEmpty then default else this.get
  def get: InnerType   // toteutettu erikseen alakäsitteille Some ja None tuossa alempana
  def isEmpty: Boolean // toteutettu erikseen alakäsitteille Some ja None tuossa alempana
  def isDefined = !this.isEmpty

class Some[InnerType](val content: InnerType) extends Option[InnerType]:
  def isEmpty = false
  def get = this.content

object None extends Option[Nothing]:
  def isEmpty = true
  def get = throw new NoSuchElementException

// Yksinkertaistettu Scala APIn Option-toteutuksesta, joka on täällä:
// https://github.com/scala/scala/blob/v2.11.8/src/library/scala/Option.scala

Yleisempi opetus tästä on, että ohjelmoija voi toteuttaa itselleen ja muille työkaluja, jotka muovaavat tapaa, jolla ohjelmoidaan.

Toki se, että tietty rakenne — vaikkapa Option — on osa kielen valmista työkalupakkia ja sitä käytetään kielen peruskirjastoissa, vaikuttaa tuon rakenteen suosioon kieltä käyttävien ohjelmoijien keskuudessa. Osittain asia on siis kyllä kielikysymyskin.

Miksi Scalassa sitten edes on null? Miksi se esiteltiin kurssilla?

Osa ohjelmoijista onkin sitä mieltä, että esimerkiksi Scalassa ei null-arvoa pitäisi ollakaan.

Tilanteesta riippuen null-arvon käyttäminen saattaa olla perusteltua. Scalassa se on mukana lähinnä parantamassa Scalan yhdisteltävyyttä muihin kieliin. nullin sisällyttäminen kieleen tekee helpommaksi sen, että Scala-ohjelmasta voi käyttää Java-kielellä kirjoitettuja kirjastoja. (Siitä vähän lisää luvussa 5.4 ja myöhemmin).

../_images/martin_odersky.png — Martin Odersky, Scalan johtohahmo

We want to move away from null. Null is a source of many, many errors. We could have come out with a language that just disallows null as a possible value of any type, because Scala has a perfectly good replacement called an option type. But of course a lot of Java libraries return nulls, and we have to treat it in some way.

—Martin Odersky

Muissa kielissä nullia saatetaan käyttää:

kätevien vaihtoehtojen puutteen vuoksi
tapauskohtaisista suoritustehokkuus- tai kätevyyssyistä
ohjelmointikulttuurillisista syistä; tai joskus vain
koska ei muutakaan osata.

Option vaatii hieman lisätoimenpiteitä tietokoneelta ohjelman suorituksen aikana (Some-olioiden luominen, arvojen noutaminen niiden sisältä). Usein tällä ei ole mitään käytännön merkitystä, mutta joskus on.

Kuten todettu, emme jatkossa suosi nulliin perustuvia ratkaisuja. Silti Scala-kieliselläkin ohjelmoinnin alkeiskurssilla nullin esittely on perusteltua, koska:

null-arvo on monessa muussa yhteydessä yleinen ja kuuluu ohjelmoijan yleissivistykseen. Kun etsit itse tietoa netistä tai tutustut muiden tekemään koodiin, törmäät varmasti null-arvoon ennemmin tai myöhemmin.
Scala on kiva kieli, mutta tämä ei ole vain Scala-kurssi tai edes ensisijaisesti Scala-kurssi. Tämä on ensisijaisesti ohjelmoinnin perusteiden kurssi.
Kun käsittelemme tämän aiheen, voimme vertailla eri ratkaisutapoja ja pohtia lyhyesti ohjelmointikielten suunnitteluperiaatteista. Tämä auttaa ymmärtämään, miksi ohjelmoimme niin kuin ohjelmoimme.
Vaikka välttäisitkin null-arvon käyttöä, voit päätyä vastatusten NullPointerExceptionin kanssa. Tunne vihollisesi.

Lisää jorinaa Optionista

On toki totta, että Optionin hyödyllisyys riippuu tilanteesta, tarkoituksesta ja osin ohjelmoijastakin. On toki myös totta, että tilaa virheille jää, vaikka välttäisitkin nullin käyttöä. Aina jää.

Optionilla on puolensa. Sen hyviä puolia on helpompi aliarvoida kuin huonoja.

Olit itse mitä mieltä tahansa, niin Optionia joka tapauksessa käytetään laajasti Scala-ohjelmoinnissa ja muillakin kielillä ohjelmoidessa. Tämä tekniikka on siis syytä hallita.

Tällä kurssilla käytämme Option-luokkaa jatkossa runsaasti.

Yhteenvetoa

"Ehkä olemassa olevasta arvosta" voi pitää kirjaa Option-luokan avulla. Luokalle määrätään käyttöyhteyteen sopiva tyyppiparametri: esimerkiksi Option[Int] tarkoittaa "nolla tai yksi kokonaislukuarvoa".
- Option-tyyppinen arvo on joko viittaus None-olioon ("tyhjään kääreeseen") tai sellaiseen Some-olioon, jonka sisälle on "kääritty" yksi arvo.
- On lähes aina parempi käyttää Optionia kuin null-viittauksia.
Scalan match-käsky sopii mm. Option-olioiden käsittelyyn. Sillä voi valita toimenpiteen tapauskohtaisesti sillä perusteella, onko Option-oliolla sisältöä vai ei.
Monesti hyödyllisiä Option-luokan metodeita ovat mm. getOrElse, isDefined ja isEmpty. Lisää Option-olioiden metodeita kohdataan myöhemmin kurssilla (luku 8.3), jolloin luokan käyttö kätevöityy.
Ohjelmointikieli peruskirjastoineen voidaan suunnitella vähentämään ohjelmavirheitä ja edesauttamaan virheiden nopeaa havaitsemista. Option-luokka on esimerkki tästä.
Lukuun liittyviä termejä sanastosivulla: Option, null-viittaus; käännösaikainen virhe, ajonaikainen virhe.

Tekijät

Tämän oppimateriaalin kehitystyössä on käytetty apuna tuhansilta opiskelijoilta kerättyä palautetta. Kiitos!

Materiaalin luvut tehtävineen ja viikkokoosteineen on laatinut Juha Sorva.

Liitesivut (sanasto, Scala-kooste, usein kysytyt kysymykset jne.) on kirjoittanut Juha Sorva sikäli kuin sivulla ei ole toisin mainittu.

Tehtävien automaattisen arvioinnin ovat toteuttaneet: (aakkosjärjestyksessä) Riku Autio, Nikolas Drosdek, Kaisa Ek, Joonatan Honkamaa, Antti Immonen, Jaakko Kantojärvi, Onni Komulainen, Niklas Kröger, Kalle Laitinen, Teemu Lehtinen, Mikael Lenander, Ilona Ma, Jaakko Nakaza, Strasdosky Otewa, Timi Seppälä, Teemu Sirkiä, Joel Toppinen, Anna Valldeoriola Cardó ja Aleksi Vartiainen.

Lukujen alkuja koristavat kuvat ja muut vastaavat kuvituskuvat on piirtänyt Christina Lassheikki.

Yksityiskohtaiset animaatiot Scala-ohjelmien suorituksen vaiheista suunnittelivat Juha Sorva ja Teemu Sirkiä. Teemu Sirkiä ja Riku Autio toteuttivat ne apunaan Teemun aiemmin rakentamat työkalut Jsvee ja Kelmu.

Muut diagrammit ja materiaaliin upotetut vuorovaikutteiset esitykset laati Juha Sorva.

O1Library-ohjelmakirjaston ovat kehittäneet Aleksi Lukkarinen, Juha Sorva ja Jaakko Nakaza. Useat sen keskeisistä osista tukeutuvat Aleksin SMCL-kirjastoon.

Tapa, jolla käytämme O1Libraryn työkaluja (kuten Pic) yksinkertaiseen graafiseen ohjelmointiin, on saanut vaikutteita tekijöiden Flatt, Felleisen, Findler ja Krishnamurthi oppikirjasta How to Design Programs sekä Stephen Blochin oppikirjasta Picturing Programs.

Oppimisalusta A+ luotiin alun perin Aallon LeTech-tutkimusryhmässä pitkälti opiskelijavoimin. Nykyään tätä avoimen lähdekoodin projektia kehittää Tietotekniikan laitoksen opetusteknologiatiimi ja tarjoaa palveluna laitoksen IT-tuki; sitä ovat kehittäneet kymmenet Aallon opiskelijat ja muut.

A+ Courses -lisäosa, joka tukee A+:aa ja O1-kurssia IntelliJ-ohjelmointiympäristössä, on toinen avoin projekti. Sen suunnitteluun ja toteutukseen on osallistunut useita opiskelijoita yhteistyössä O1-kurssin opettajien kanssa.

Kurssin tämänhetkinen henkilökunta löytyy luvusta 1.1.

Joidenkin lukujen lopuissa on lukukohtaisia lisäyksiä tähän tekijäluetteloon.

Luku 4.3: Olemattomia arvoja

Jatkoa viime numerosta

Inspiraatiota `lift`-metodista

`Option`-tietotyyppi

`Some` ja `None`

`Option`-arvoja muuttujassa

Kuvia tai sitä ei tapahtunut

Kääritty vs. käärimätön arvo

`Option`, kas siinä pulma

Voisiko selventää eroa `null` vs. `None`, kiitos?

Ja `Unit` vielä?

`Option`-kääreen avaaminen ja `match`-käsky

`match`-valintakäsky

Pikkutehtäviä: `match` ja `Option`in metodeita

Suosikkikirjanpito: uusi toteutus

`Option`-tyyppinen ilmentymämuuttuja

Uusi toteutus `addExperience`-metodille

Muutos luokan rajapinnassa

Vaihtoehtoinen toteutustapa ilman `Option`ia

Et sitten aikaisemmin kertonut!?

Miljardin dollarin virhe

Miksi `Option`?

Virheilmoituksista

Lisämateriaalia `Option`in ympäriltä

Yhteenvetoa

Palaute

Tekijät

Luku 4.3: Olemattomia arvoja

Jatkoa viime numerosta

Inspiraatiota lift-metodista

Option-tietotyyppi

Some ja None

Option-arvoja muuttujassa

Kuvia tai sitä ei tapahtunut

Kääritty vs. käärimätön arvo

Option, kas siinä pulma

Voisiko selventää eroa null vs. None, kiitos?

Ja Unit vielä?

Option-kääreen avaaminen ja match-käsky

match-valintakäsky

Pikkutehtäviä: match ja Optionin metodeita

Suosikkikirjanpito: uusi toteutus

Option-tyyppinen ilmentymämuuttuja

Uusi toteutus addExperience-metodille

Muutos luokan rajapinnassa

Vaihtoehtoinen toteutustapa ilman Optionia

Et sitten aikaisemmin kertonut!?

Miljardin dollarin virhe

Miksi Option?

Virheilmoituksista

Lisämateriaalia Optionin ympäriltä

Yhteenvetoa

Palaute

Tekijät

Inspiraatiota `lift`-metodista

`Option`-tietotyyppi

`Some` ja `None`

`Option`-arvoja muuttujassa

`Option`, kas siinä pulma

Voisiko selventää eroa `null` vs. `None`, kiitos?

Ja `Unit` vielä?

`Option`-kääreen avaaminen ja `match`-käsky

`match`-valintakäsky

Pikkutehtäviä: `match` ja `Option`in metodeita

`Option`-tyyppinen ilmentymämuuttuja

Uusi toteutus `addExperience`-metodille

Vaihtoehtoinen toteutustapa ilman `Option`ia

Miksi `Option`?

Lisämateriaalia `Option`in ympäriltä