plik

Tytuł oryginału: Scala in Depth

Tłumaczenie: Justyna Walkowska

Projekt okładki: Anna Mitka
Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC.

ISBN: 978-83-246-5188-7

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording or by any information storage retrieval system,
without permission from the Publisher.

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej
publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną,
fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje
naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich
właścicieli.

Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte
w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani
za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich.
Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne
szkody wynikłe z wykorzystania informacji zawartych w książce.

Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/scalao
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

Printed in Poland.

Księgarnia internetowa

•

Lubię to! » Nasza społeczność

Spis treci

Sowo wstpne ............................................................................................................................................ 7
Przedmowa ................................................................................................................................................. 9
Podzikowania .......................................................................................................................................... 11
O ksice ................................................................................................................................................... 13

Rozdzia 1. Scala: jzyk mieszany

1.1.

Programowanie funkcyjne i obiektowe w jednym .................................................................... 18
1.1.1. Koncepty

funkcyjne

...................................................................................................... 20

1.1.2.

Analiza konceptów funkcyjnych w Google Collections .............................................. 22

1.2.

Statyczne typowanie a ekspresywno kodu ............................................................................. 23
1.2.1. Zamiana

stron

................................................................................................................ 24

1.2.2.

Wnioskowanie na temat typów ..................................................................................... 24

1.2.3. Uproszczona

skadnia

.................................................................................................... 25

1.2.4.

Wartoci i konwersje domniemane .............................................................................. 26

1.2.5.

Sowo kluczowe implicit ............................................................................................... 27

1.3.

Wygodna wspópraca z JVM ....................................................................................................... 28
1.3.1.

Java w Scali .................................................................................................................... 28

1.3.2.

Scala w Javie .................................................................................................................. 29

1.3.3. Zalety

JVM

..................................................................................................................... 30

1.4. Podsumowanie

.............................................................................................................................. 31

Rozdzia 2. Podstawowe zasady

2.1.

Eksperymenty w rodowisku REPL ........................................................................................... 33
2.1.1.

Programowanie sterowane eksperymentami ............................................................... 34

2.1.2.

Obejcie zachannego parsowania ................................................................................ 36

2.1.3.

Elementy jzyka niedostpne w REPL ....................................................................... 37

2.2. Mylenie

wyraeniami

................................................................................................................. 38

2.2.1.

Unikanie instrukcji return ............................................................................................ 39

2.2.2. Modyfikowalno

........................................................................................................... 41

2.3. Obiekty

niemodyfikowalne

......................................................................................................... 43

2.3.1. Równowano

obiektów

.............................................................................................. 44

2.3.2. Wspóbieno

............................................................................................................... 48

2.4. None

zamiast

null

......................................................................................................................... 51

2.4.1.

Zaawansowane techniki wykorzystania klasy Option ................................................. 52

2.5. Równowano

polimorficzna

..................................................................................................... 55

2.5.1.

Przykad: biblioteka obsugujca kalendarz ................................................................. 55

2.5.2. Polimorficzna

implementacja

metody equals .............................................................. 57

2.6. Podsumowanie

.............................................................................................................................. 59

Kup książkę

Poleć książkę

Spis treci

Rozdzia 3. Par sów na temat konwencji kodowania

3.1.

Unikanie konwencji pochodzcych z innych jzyków .............................................................. 62
3.1.1.

Poraka z blokami kodu ................................................................................................ 63

3.2.

Wiszce operatory i wyraenia w nawiasach ............................................................................ 66

3.3.

Znaczce nazwy zmiennych ........................................................................................................ 67
3.3.1.

Unikanie w nazwach znaku $ ....................................................................................... 68

3.3.2.

Parametry nazwane i wartoci domylne ..................................................................... 71

3.4. Oznaczanie

przesaniania

metod

................................................................................................ 73

3.5. Adnotacje

optymalizacyjne

......................................................................................................... 78

3.5.1. Optymalizacja

tableswitch

............................................................................................ 79

3.5.2. Optymalizacja

wywoa

ogonowych

............................................................................ 81

3.6. Podsumowanie

.............................................................................................................................. 84

Rozdzia 4. Obiektowo

4.1.

W ciele obiektu lub cechy — tylko kod inicjalizujcy ............................................................. 86
4.1.1. Opóniona

inicjalizacja

................................................................................................. 86

4.1.2. Wielokrotne

dziedziczenie ........................................................................................... 87

4.2.

Puste implementacje metod abstrakcyjnych w cechach .......................................................... 89

4.3.

Kompozycja moe obejmowa dziedziczenie ............................................................................ 93
4.3.1.

Kompozycja i dziedziczenie razem .............................................................................. 96

4.3.2.

Klasyczne konstruktory… z niespodziank ................................................................. 97

4.4.

Wydzielenie interfejsu abstrakcyjnego do postaci osobnej cechy .......................................... 99
4.4.1.

Interfejsy, z którymi mona porozmawia ................................................................. 101

4.4.2. Nauka

pynca

przeszoci ....................................................................................... 102

4.5.

Okrelanie typów zwracanych przez publiczne API .............................................................. 103

4.6. Podsumowanie

............................................................................................................................ 105

Rozdzia 5. Domniemane wartoci i widoki podstaw ekspresywnego kodu

107

5.1. Sowo

kluczowe

implicit

............................................................................................................ 108

5.1.1. Identyfikatory

(dygresja)

............................................................................................. 109

5.1.2.

Zakres i wizania ......................................................................................................... 111

5.1.3. Wyszukiwanie

wartoci

domniemanych

.................................................................... 115

5.2.

Wzmacnianie klas za pomoc domniemanych widoków ....................................................... 119

5.3.

Parametry domniemane i domylne ........................................................................................ 124

5.4.

Ograniczanie zakresu encji domniemanych ........................................................................... 130
5.4.1.

Przygotowywanie encji domniemanych do zaimportowania .................................... 131

5.4.2.

Parametry i widoki domniemane bez podatku od importu ...................................... 133

5.5. Podsumowanie

............................................................................................................................ 137

Rozdzia 6. System typów

139

6.1. Typy

............................................................................................................................................. 140

6.1.1. Typy

cieki

............................................................................................................... 141

6.1.2.

Sowo kluczowe type ................................................................................................... 143

6.1.3. Typy

strukturalne

........................................................................................................ 144

6.2. Ograniczenia

typów

................................................................................................................... 151

6.3.

Parametry typu i typy wyszego rzdu .................................................................................... 153
6.3.1. Ograniczenia

parametrów

typu

.................................................................................. 153

6.3.2. Typy

wyszego

rzdu

.................................................................................................. 155

Kup książkę

Poleć książkę

Spis treci

6.4. Wariancja

.................................................................................................................................... 156

6.4.1.

Zaawansowane adnotacje wariancji ........................................................................... 160

6.5. Typy

egzystencjalne

................................................................................................................... 163

6.5.1.

Formalna skadnia typów egzystencjalnych .............................................................. 165

6.6. Podsumowanie

............................................................................................................................ 167

Rozdzia 7. czenie typów z wartociami i widokami domniemanymi 169

7.1.

Ograniczenia kontekstu i ograniczenia widoku ...................................................................... 170
7.1.1.

Kiedy stosowa domniemane ograniczenia typu? ..................................................... 171

7.2.

Dodawanie typów do parametrów domniemanych ................................................................ 172
7.2.1. Manifesty

..................................................................................................................... 172

7.2.2.

Korzystanie z manifestów ........................................................................................... 173

7.2.3. Ograniczenia

typu

....................................................................................................... 175

7.2.4. Wyspecjalizowane

metody

......................................................................................... 177

7.3.

Klasy typu .................................................................................................................................... 178
7.3.1.

FileLike jako klasa typu .............................................................................................. 181

7.3.2.

Zalety klas typu ............................................................................................................ 184

7.4.

Egzekucja warunkowa z uyciem systemu typów ................................................................... 185
7.4.1. Heterogeniczne

listy

typowane

.................................................................................. 187

7.4.2. Cecha

IndexedView

.................................................................................................... 190

7.5. Podsumowanie

............................................................................................................................ 196

Rozdzia 8. Wybór odpowiedniej kolekcji

197

8.1.

Wybór odpowiedniego rodzaju kolekcji .................................................................................. 198
8.1.1. Hierarchia

kolekcji

...................................................................................................... 198

8.1.2. Traversable

.................................................................................................................. 200

8.1.3. Iterable

......................................................................................................................... 203

8.1.4. Seq

............................................................................................................................... 204

8.1.5. LinearSeq

.................................................................................................................... 205

8.1.6. IndexedSeq

.................................................................................................................. 207

8.1.7. Set

................................................................................................................................ 208

8.1.8. Map

.............................................................................................................................. 208

8.2. Kolekcje

niemodyfikowalne

...................................................................................................... 210

8.2.1. Vector

........................................................................................................................... 210

8.2.2. List

............................................................................................................................... 212

8.2.3. Stream

.......................................................................................................................... 213

8.3. Kolekcje

modyfikowalne

........................................................................................................... 216

8.3.1. ArrayBuffer

.................................................................................................................. 217

8.3.2.

Nasuchiwanie zdarze zmiany kolekcji za pomoc domieszek ............................... 217

8.3.3. Synchronizacja

uyciem domieszek ........................................................................ 218

8.4.

Zmiana czasu ewaluacji za pomoc widoków i kolekcji równolegych ................................. 218
8.4.1. Widoki

.......................................................................................................................... 219

8.4.2. Kolekcje

równolege

................................................................................................... 221

8.5.

Pisanie metod, które mona wykorzysta na wszystkich typach kolekcji ............................ 223
8.5.1. Optymalizacja

algorytmów

dla rónych typów kolekcji ............................................ 226

8.6. Podsumowanie

............................................................................................................................ 229

Kup książkę

Poleć książkę

Spis treci

Rozdzia 9. Aktorzy

231

9.1.

Kiedy stosowa aktorów? ........................................................................................................... 232
9.1.1.

Zastosowanie aktorów do wyszukiwania .................................................................... 232

9.2.

Typowane, przezroczyste referencje ....................................................................................... 235
9.2.1. Realizacja

algorytmu

rozprosz-zgromad przy uyciu OutputChannel ................... 236

9.3.

Ograniczanie bdów do stref ................................................................................................... 240
9.3.1.

Strefy bdu w przykadzie rozprosz-zgromad ........................................................ 240

9.3.2.

Ogólne zasady obsugi awarii ..................................................................................... 243

9.4.

Ograniczanie przecie za pomoc stref planowania .......................................................... 244
9.4.1. Strefy

planowania

........................................................................................................ 245

9.5.

Dynamiczna topologia aktorów ................................................................................................ 247

9.6. Podsumowanie

............................................................................................................................ 251

Rozdzia 10. Integracja Scali z Jav

253

10.1. Rónice jzykowe pomidzy Scal a Jav ................................................................................ 254

10.1.1.

Rónice w opakowywaniu typów prostych ................................................................ 255

10.1.2. Widoczno

.................................................................................................................. 259

10.1.3. Nieprzekadalne

elementy jzyka .............................................................................. 260

10.2. Uwaga na domniemane konwersje ........................................................................................... 263

10.2.1.

Tosamo i równowano obiektów ........................................................................ 263

10.2.2.

acuchy domniemanych widoków ........................................................................... 265

10.3. Uwaga na serializacj w Javie ................................................................................................... 267

10.3.1.

Serializacja klas anonimowych ................................................................................... 269

10.4. Adnotowanie

adnotacji .............................................................................................................. 271

10.4.1. Cele

adnotacji

.............................................................................................................. 272

10.4.2.

Scala i pola statyczne ................................................................................................... 273

10.5. Podsumowanie

............................................................................................................................ 274

Rozdzia 11. Wzorce w programowaniu funkcyjnym

277

11.1. Teoria

kategorii

w informatyce ................................................................................................ 278

11.2. Funktory i monady oraz ich zwizek z kategoriami ............................................................... 281

11.2.1. Monady

........................................................................................................................ 284

11.3. Rozwijanie funkcji i styl aplikacyjny ........................................................................................ 286

11.3.1. Rozwijanie

funkcji

....................................................................................................... 286

11.3.2. Styl

aplikacyjny

........................................................................................................... 288

11.4. Monady jako przepywy pracy .................................................................................................. 291
11.5. Podsumowanie

............................................................................................................................ 295

Skorowidz 297

Kup książkę

Poleć książkę

108

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

lub wrcz niebezpieczne, jest zmienianie typu przez kompilator w celu umoliwienia
poprawnej kompilacji.

System domniema to jeden z najwikszych atutów Scali. Rozsdnie stosowany moe

radykalnie zmniejszy rozmiar Twojego kodu. Moe take zosta wykorzystany do ele-
ganckiego wymuszenia ogranicze projektowych.

Spójrzmy najpierw na domniemane parametry.

5.1.

Sowo kluczowe implicit

Scala udostpnia sowo kluczowe

implicit

(z ang. domniemany, niejawny), które mona

stosowa na dwa sposoby: podczas definiowania metod lub zmiennych albo na licie pa-
rametrów metody. Uyte w definicji metody lub zmiennej sowo to informuje kompilator
o tym, e dana metoda lub zmienna moe zosta wykorzystana podczas wnioskowania na
temat domniema. Wyszukiwanie wartoci domniemanych jest przeprowadzane, gdy kom-
pilator zauwaa, e w kodzie brakuje pewnej informacji. Jeli sowo

implicit

zostanie uyte

na pocztku listy parametrów pewnej metody, kompilator przyjmie, e ta lista moe nie zo-
sta podana i e konieczne moe si okaza odgadnicie parametrów na podstawie regu.

Przeanalizujmy mechanizm wnioskowania na przykadzie metody z brakujc list

parametrów:

scala> def findAnInt(implicit x : Int) = x
findAnInt: (implicit x: Int)Int

Metoda

findAnInt

(znajd liczb cakowit) deklaruje jeden parametr

typu

Int

. Zwróci

ona bez zmian kad przekazan do niej warto. Lista parametrów zostaa oznaczona
sowem

implicit

, co oznacza, e nie jest konieczne jej podawanie. Jeli opucimy list

parametrów, kompilator poszuka zmiennej typu

Int

w zakresie domniemanym. Oto

przykad wywoania tej metody:

scala> findAnInt
<console>:7: error: could not find implicit value for parameter x: Int
findAnInt
^

Metoda

findAnInt

zostaa wywoana bez listy parametrów. Kompilator skary si, e nie

jest w stanie odnale wartoci domniemanej parametru

. Dostarczmy mu tak warto:

scala> implicit val test = 5
test: Int = 5

Warto

test

zostaa zdefiniowana z uyciem sowa

implicit

. Oznacza to, e moe

ona zosta uwzgldniona we wnioskowaniu na temat domniema. Skoro dziaamy w ro-
dowisku REPL, zmienna

test

bdzie dostpna a do koca naszej sesji. Oto co si wy-

darzy, gdy wywoamy

findAnInt

scala> findAnInt
res3: Int = 5

Tym razem wywoanie si powiedzie — metoda zwróci warto zmiennej

test

. Kompila-

torowi udao si odnale brakujce fragmenty ukadanki. Oczywicie jeli chcemy, mo-
emy wywoa funkcj, przekazujc jej parametr:

scala> findAnInt(2)
res4: Int = 2

Kup książkę

Poleć książkę

5.1.

Sowo kluczowe implicit

109

Poniewa tym razem nie brakuje parametru, kompilator nie rozpoczyna procesu wyszu-
kiwania wartoci na podstawie regu. Zapamitaj, e domniemane parametry zawsze
mona jawnie poda. Wrócimy do tego w podrozdziale 5.6.

W celu zrozumienia sposobu, w jaki kompilator okrela, czy zmienna moe zosta

uwzgldniona w procesie wyszukiwania wartoci domniemanych, trzeba wgry si troch
w to, jak s obsugiwane identyfikatory i zakresy.

5.1.1. Identyfikatory

(dygresja)

Zanim zagbimy si w szczegóy mechanizmu wnioskowania, warto zrozumie, w jaki
sposób kompilator rozpoznaje identyfikatory w danym zakresie. Ta sekcja jest oparta na
rozdziale 2. specyfikacji jzyka Scala

. Zachcam Ci do przeczytania specyfikacji, gdy

ju zapoznasz si z podstawami. Identyfikatory odgrywaj kluczow rol podczas wybie-
rania zmiennych domniemanych, dlatego powimy im nieco uwagi.

W specyfikacji pojawia si sowo entity (z ang. encja, byt), obejmujce znaczeniem:

typy, wartoci, zmienne oraz klasy. S to podstawowe elementy uywane do budowania
programów. Odwoujemy si do nich za pomoc identyfikatorów czy te nazw. Mówimy
wówczas o wizaniu (ang. binding) pomidzy identyfikatorem a dan encj. Rozwa na-
stpujcy fragment kodu:

class Foo {
def val x = 5
}

Sama encja

Foo

to klasa zawierajca metod

. Powizalimy j z identyfikatorem

Foo

Jeli zadeklarujemy t klas lokalnie wewntrz REPL, bdziemy mogli utworzy jej in-
stancj, poniewa nazwa i encja zostay lokalnie powizane:

scala> val y = new Foo
y: Foo = Foo@33262bf4

Moemy utworzy now zmienn o nazwie

i typie

Foo

, odwoujc si do nazwy

Foo

Powtórz: jest tak dlatego, e klasa

Foo

zostaa zdefiniowana lokalnie wewntrz REPL

i lokalnie powizano j z nazw

Foo

. Skomplikujmy nieco sprawy, umieszczajc

Foo

we-

wntrz pakietu.

package test;

class Foo {
val x = 5
}

Klasa

Foo

naley teraz do pakietu

test

. Jeli spróbujemy odwoa si do niej w REPL za

pomoc nazwy

Foo

, poniesiemy klsk:

scala> new Foo
<console>:7: error: not found: type Foo
new Foo

Utworzenie nowej instancji

Foo

nie powiodo si, poniewa w naszym zakresie nazwa

Foo

nie zostaa powizana z adn encj. Klasa

Foo

znajduje si w pakiecie

test

. Aby si do

http://www.scala-lang.org/docu/files/ScalaReference.pdf.

Kup książkę

Poleć książkę

110

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

niej odwoa, musimy albo skorzysta z nazwy

test.Foo

, albo powiza nazw

Foo

z klas

test.Foo

w aktualnym zakresie. Druga z wspomnianych opcji jest dostpna dziki

sowu kluczowemu

import

scala> import test.Foo
import test.Foo

scala> new Foo
res3: test.Foo = test.Foo@60e1e567

Instrukcja

import

pobiera encj

test.Foo

i wie j z nazw

Foo

w zakresie lokalnym.

Dziki temu moliwe staje si utworzenie instancji

test.Foo

za pomoc wywoania

new

Foo

. Podobnie dziaa instrukcja

import

w Javie i

using

w C++. Mechanizm dostpny

w Scali jest jednak nieco bardziej elastyczny.

Instrukcj

import

mona zastosowa w dowolnym miejscu pliku ródowego, gdzie

stworzy ona wizanie jedynie w zakresie lokalnym. Dziki temu mamy kontrol nad tym,
gdzie s uywane zaimportowane nazwy. Ta funkcjonalno pozwala dodatkowo na ogra-
niczenie zakresu domniemanych widoków i zmiennych. Wicej na ten temat znajdziesz
w podrozdziale 5.4.

Jednym z przejawów elastycznoci mechanizmu wizania encji w Scali jest moliwo

wykorzystania arbitralnych nazw. W Javie czy w C# jest moliwe jedynie przeniesienie
do biecego zakresu nazwy zdefiniowanej w innym zakresie bd pakiecie. Klas

test.Foo

moglibymy zaimportowa lokalnie jako

Foo

. Natomiast instrukcja

import

w Scali pozwala

na zdefiniowanie nowej nazwy przy uyciu skadni

{OryginalneWizanie => NoweWizanie}

Zaimportujmy nasz encj

test.Foo

, nadajc jej now nazw:

scala> import test.{Foo=>Bar}
import test.{Foo=>Bar}

scala> new Bar
res1: test.Foo = test.Foo@596b753

Pierwsza instrukcja

import

wie klas

test.Foo

z nazw

Bar

w biecym zakresie. W

nastpnej linii tworzymy now instancj

test.Foo

, wywoujc

new Bar

. Mechanizm

ten pozwala na uniknicie konfliktów nazw podczas importowania encji z rónych pa-
kietów. Dobrym przykadem s

java.util.List

scala.List

. W celu uniknicia nie-

porozumie w kodzie wspópracujcym z kodem Javy czsto stosuje si konstrukcj

im-

port java.util.{List=>JList}

Zmiana nazwy pakietu

Instrukcj import w Scali mona zastosowa take w celu zmiany nazwy pakietu.
Przydaje si to podczas korzystania z bibliotek Javy. Sam, gdy korzystam z pakietu
java.io, czsto zaczynam od nastpujcego kodu:

import java.{io=>jio}
def someMethod( input : jio.InputStream ) = ...

Wizanie pozwala na nadanie encji okrelonej nazwy w konkretnym zakresie. Istotne jest
tutaj zrozumienie, czym jest zakres i jakie wizania mona w nim znale.

Kup książkę

Poleć książkę

5.1.

Sowo kluczowe implicit

111

5.1.2. Zakres i wizania

Zakres to leksykalna granica, wewntrz której s dostpne wizania. Zakresem moe by
ciao klasy, ciao metody, anonimowy blok kodu… Zasadniczo za kadym razem, gdy uy-
wasz nawiasów klamrowych, tworzysz w ich wntrzu nowy zakres.

W Scali jest moliwe zagniedanie zakresów — jeden zakres moe wystpi we-

wntrz drugiego. W zagniedonym zakresie s dostpne wizania z zakresu szerszego.
Moliwa jest zatem nastpujca operacja:

class Foo(x : Int) {
def tmp = {
x
}
}

Konstruktor klasy

Foo

pobiera parametr

. Nastpnie definiujemy zagniedon metod

tmp

. Parametry konstruktora s dostpne z jej wntrza — moemy odwoa si do

identyfikatora

. Zakres zagniedony ma dostp do wiza w zakresie-rodzicu, ale

moliwe jest te tworzenie wiza, które je przesoni. Metoda

tmp

moe utworzy nowe

wizanie o nazwie

. Wówczas

nie bdzie ju identyfikatorem prowadzcym do para-

metru rodzica. Zobaczmy:

scala> class Foo(x : Int) {
   |   def tmp = {
   |     val x = 2
   |     x
   |   }
   | }
defined class Foo

Klasa

Foo

ma definicj tak sam jak wczeniej, jednak metoda

tmp

w zakresie zagnie-

donym definiuje zmienn o nazwie

. Nowe wizanie przesania parametr konstruktora

W wyniku tego lokalnie widoczne jest tylko nowe wizanie, a parametr konstruktora jest
niedostpny — a przynajmniej nie przy uyciu nazwy

. W Scali wizania o wy-

szym priorytecie przesaniaj te o niszym w tym samym zakresie. Ponadto wizania
o wyszym lub tym samym priorytecie przesaniaj wizania zdefiniowane w zakresie
zewntrznym.

Priorytety wiza w Scali s nastpujce:

Najwyszy priorytet maj definicje lub deklaracje lokalne, odziedziczone lub

udostpnione poprzez klauzul pakietow w tym samym pliku, w którym
pojawia si definicja.

Nastpne w kolejnoci s encje jawnie zaimportowane.

Dalej mamy encje zaimportowane z uyciem symboli wieloznacznych

(

import foo._

Najniszy priorytet maj definicje udostpniane poprzez klauzul pakietow

znajdujc si poza plikiem, w którym pojawia si definicja.

Kup książkę

Poleć książkę

112

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

Przesanianie wiza

W Scali wizanie przesania wizania o niszym priorytecie w tym samym zakresie.
Ponadto wizanie przesania wizania o tym samym lub niszym priorytecie z zakresu
zewntrznego. Dziki temu moemy napisa:

class Foo(x : Int) {
def tmp = {
val x = 2
x
}
}

Metoda tmp bdzie zwracaa warto 2.

Sprawdmy priorytety na konkretnym przykadzie. Zacznijmy od zdefiniowania pakietu

test

i obiektu

wewntrz pliku ródowego, który nazwiemy externalbin-

dings.scala (listing 5.1).

Listing 5.1. Plik externalbindings.scala z wizaniami zewntrznymi

package test;

object x {
override def toString = "Zewntrznie powizany obiekt x w pakiecie test"
}

Plik definiuje pakiet

test

oraz zawarty w nim obiekt

. Obiekt

przesania metod

toString

, dziki czemu atwo go rozpozna. Zgodnie z przedstawionymi wczeniej re-

guami obiekt

powinien mie najniszy moliwy priorytet wizania. Stwórzmy teraz plik,

który to sprawdzi (listing 5.2).

Listing 5.2. Test wizania w tym samym pakiecie

package test;

object Test {
def main(args : Array[String]) : Unit = {
  testSamePackage()      // Ten sam pakiet
  testWildcardImport()   // Import poprzez symbol wieloznaczny
  testExplicitImport()   // Jawny import
  testInlineDefinition() // Definicja w miejscu[JW1]
}
...
}

Zaczynamy od deklaracji, zgodnie z któr tre pliku przynaley do tego samego pakietu
co nasza wczeniejsza definicja. Nastpnie definiujemy metod

main

wywoujc czte-

ry metody testowe, po jednej dla kadej reguy okrelajcej priorytety wiza. Zacznij-
my od zdefiniowania pierwszej z metod:

def testSamePackage() {
println(x)
}

Kup książkę

Poleć książkę

5.1.

Sowo kluczowe implicit

113

Metoda wypisuje encj o nazwie

. Poniewa obiekt

Test

zosta zdefiniowany we-

wntrz pakietu

test

, stworzony wczeniej obiekt

jest dostpny i to on zostanie przeka-

zany metodzie

println

. Oto dowód:

scala> test.Test.testSamePackage()
Zewntrznie powizany obiekt x w pakiecie test

Wywoanie metody

testSamePackage

generuje acuch znaków zwizany z obiektem

Spójrzmy teraz, co si zmieni, gdy do zaimportowania obiektu wykorzystamy symbol
wieloznaczny (listing 5.3).

Listing 5.3. Import z uyciem symbolu wieloznacznego

object Wildcard {
def x = "Import x poprzez symbol wieloznaczny"
}

def testWildcardImport() {
import Wildcard._
println(x)
}

Obiekt

Wildcard

przechowuje encj

. Encja

to metoda, która zwraca acuch znaków

"Import x poprzez symbol wieloznaczny"

. Metoda

testWildcardImport

najpierw wy-

wouje

import

Wildcard._

. Dziki temu wywoaniu nazwy i encje z obiektu

Wildcard

zo-

stan powizane w biecym zakresie. Poniewa importowanie za pomoc symbolu
wieloznacznego ma wyszy priorytet ni zasoby dostpne w tym samym pakiecie, ale
innym pliku ródowym, encja

Wildcard.x

zostanie uyta zamiast

test.x

. Moemy to

sprawdzi, wywoujc funkcj

testWildcardImport

scala> test.Test.testWildcardImport()
Wildcard Import x

Wywoanie metody

testWildcardImport

powoduje wywietlenie napisu

"Import x

poprzez symbol wieloznaczny"

— wanie tego spodziewalimy si, znajc priorytety

wiza. Sprawy stan si bardziej interesujce, gdy do przykadu dorzucimy jeszcze jawne
importowanie elementów (listing 5.4).

Listing 5.4. Jawny import

object Explicit {
def x = "Jawny import x"
}
def testExplicitImport() {
import Explicit.x
import Wildcard._
println(x)
}

Obiekt

Explicit

stanowi przestrze nazw dla kolejnej encji

. Metoda

testExplicitImport

najpierw importuje t encj bezporednio, a potem importuje jeszcze zawarto encji
obiektu

Wildcard

, korzystajc z symbolu wieloznacznego. Chocia import z uyciem

symbolu wieloznacznego jest drugi w kolejnoci, dziaaj tu reguy okrelajce priorytety
wiza. Metoda zwróci warto

z obiektu

Explicit

. Sprawdmy:

Kup książkę

Poleć książkę

114

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

scala> test.Test.testExplicitImport()
Jawny import x

Zgodnie z oczekiwaniami zwrócona zostaa warto

Explicit.x

. Widoczna tu regua

okrelajca priorytety wiza ma due znaczenie w kontekcie wyszukiwania wartoci
domniemanych, do którego przejdziemy w sekcji 5.1.3.

Ostatnia regua dotyczy deklaracji lokalnych. Zmiemy metod

testExplicitImport

tak, by definiowaa lokalne wizanie dla nazwy

(listing 5.5).

Listing 5.5. Definicja lokalna

def testInlineDefinition() {
val x = "Lokalna definicja x"
import Explicit.x
import Wildcard._
println(x)
}

Pierwsza linia metody

testInlineDefinition

to deklaracja zmiennej lokalnej

. Nastpnie

linie w sposób jawny bd domniemany (z wykorzystaniem symbolu wieloznacznego)
importuj wizania

z obiektów

Explicit

Wildcard

, pokazanych wczeniej. W ostatniej

linii drukujemy wynik, by przekona si, które wizanie zwyciyo.

scala> test.Test.testInlineDefinition()
Lokalna definicja x

Ponownie, mimo e instrukcje

import

pojawiaj si po instrukcji

val x

, wybór jest

oparty na priorytecie, a nie na kolejnoci deklaracji.

Wizania nieprzesaniane

Jest moliwe stworzenie w tym samym zakresie dwóch wiza o tej samej nazwie.
W takim wypadku kompilator ostrzee o dwuznacznoci nazw. Oto przykad zapoyczony
bezporednio ze specyfikacji jzyka Scala:

scala> {
| val x = 1;
| {
| import test.x;
| x
| }
| }
<console>:11: error: reference to x is ambiguous; it is both defined in
value res7 and imported subsequently by import test.x
x
^

Zmienna x jest tu wizana w zakresie zewntrznym. Jest ona take importowana z pa-
kietu test w zakresie zagniedonym. adne z wiza nie przesania drugiego. Zmienna
x z zakresu zewntrznego nie moe przesoni zmiennej w zakresie zagniedonym,
a zaimportowana zmienna x równie nie ma odpowiedniego priorytetu, by przesoni t
w zakresie zewntrznym.

Kup książkę

Poleć książkę

5.1.

Sowo kluczowe implicit

115

Skd taki nacisk na sposób rozwikywania nazw przez kompilator? Otó wnioskowanie na
temat domniema jest cile powizane z wnioskowaniem na temat nazw. Zawie reguy
okrelajce priorytety nazw maj znaczenie take w przypadku domniema. Przyjrzyjmy
si teraz, jak postpuje kompilator, napotykajc niepen deklaracj.

5.1.3. Wyszukiwanie wartoci domniemanych

Specyfikacja jzyka Scala deklaruje dwie reguy zwizane z wyszukiwaniem encji ozna-
czonych jako domniemane:

Wizanie encji domniemanej jest dostpne na stronie wyszukiwania bez
prefiksu — to znaczy nie jako

foo.x

, tylko jako

Jeli pierwsza regua nie prowadzi do rozwizania problemu, to wszystkie
skadowe obiektu oznaczone jako

implicit

nale do domniemanego zakresu

zwizanego z typem parametru domniemanego.

Pierwsza regua cile czy si z reguami wizania przedstawionymi w poprzedniej
sekcji. Druga jest nieco bardziej zoona. Przyjrzymy si jej dokadnie w sekcji 5.1.4.

Na pocztek wrómy do przedstawionego ju wczeniej przykadu wyszukiwania

wartoci domniemanych:

scala> def findAnInt(implicit x : Int) = x
findAnInt: (implicit x: Int)Int

scala> implicit val test = 5
test: Int = 5

Metoda

findAnInt

zostaa zadeklarowana z oznaczon jako

implicit

list parametrów

skadajc si z jednej wartoci typu cakowitego. Nastpnie definiujemy warto

val

test

, take oznaczon jako

implicit

. Dziki temu identyfikator,

test

, jest dostpny w za-

kresie lokalnym bez prefiksu. Jeli w REPL wpiszemy

test

, otrzymamy warto

. Jeli

wywoamy metod, piszc

findAnInt

, kompilator przepisze j jako

findAnInt(test)

Podczas wyszukiwania s wykorzystywane reguy wizania, które zostay przeze mnie
opisane wczeniej.

Druga regua domniemanego wyszukiwania jest uywana, gdy kompilator nie moe

znale adnej wartoci domniemanej, stosujc pierwsz z regu. W takim wypadku kom-
pilator spróbuje odnale domniemane zmienne zdefiniowane wewntrz dowolnego
obiektu w domniemanym zakresie typu, którego szuka. Domniemany zakres typu defi-
niuje si jako wszystkie moduy towarzyszce powizane z danym typem. Oznacza to, e
jeli kompilator szuka parametru metody

def foo (implicit param : Foo)

, to parametr

musi by zgodny z typem

Foo

. Jeli pierwsza regua nie zwróci wartoci typu

Foo

, to

kompilator sprawdzi domniemany zakres

Foo

. Domniemany zakres

Foo

to obiekt towa-

rzyszcy

Foo

Przeanalizuj kod na listingu 5.6.

Listing 5.6. Obiekt towarzyszcy a wyszukiwanie zmiennych domniemanych

scala> object holder {
   | trait Foo
   | object Foo {
   |   implicit val x = new Foo {

Kup książkę

Poleć książkę

116

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

   |     override def toString = "Obiekt towarzyszcy Foo"
   |   }
   | }
   | }
defined module holder

scala> import holder.Foo
import holder.Foo

scala> def method(implicit foo : Foo) = println(foo)
method: (implicit foo: holder.Foo)Unit

scala> method
Obiekt towarzyszcy Foo

Obiekt

holder

jest nam potrzebny do zdefiniowania cechy i obiektu towarzyszcego

wewntrz sesji REPL, podobnie jak robilimy to w sekcji 2.1.2. Wewntrz niego defi-
niujemy cech

Foo

oraz obiekt towarzyszcy

Foo

. Obiekt towarzyszcy definiuje ska-

dow

typu

Foo

, udostpnian na potrzeby wnioskowania na temat domniema. Na-

stpnie importujemy typ

Foo

z obiektu

holder

do zakresu biecego. Ten krok nie jest

wymagany, wykonujemy go w celu uproszczenia definicji metody. Nastpnie definiu-
jemy metod

method

. Pobiera ona domniemany parametr typu

Foo

Jeli wywoamy metod z pust list argumentów, kompilator uyje zdefiniowanej

w obiekcie towarzyszcym zmiennej

implicit val x

Jako e zakres domniemany jest sprawdzany w drugiej kolejnoci, moemy wykorzy-

sta go do przechowywania wartoci domylnych, a jednoczenie umoliwi uytkowni-
kowi importowanie wasnych wartoci, jeli jest mu to potrzebne. Powicimy temu za-
gadnieniu wicej uwagi w podrozdziale 7.2.

Jak wspominaem wczeniej, zakresem domniemanym dla typu

jest zbiór obiektów

towarzyszcych dla wszystkich typów powizanych z typem

— czyli istnieje zbiór ty-

pów powizanych z

. Wszystkie obiekty towarzyszce tym typom s przeszukiwane pod-

czas wnioskowania na temat domniema. Wedug specyfikacji jzyka typ powizany
z klas

to kada klasa bdca klas bazow pewnej czci typu

. Ponisza lista przed-

stawia istniejce czci typu

Wszystkie podtypy

s czciami

. Jeli typ

zosta zdefiniowany jako

A with

B with C

, to

wszystkie s czciami

, zatem ich obiekty towarzyszce zostan

przeszukane, gdy konieczne bdzie znalezienie domniemanej wartoci typu

Jeli

ma parametry, to wszystkie parametry typu i ich czci nale do zbioru

czci

. Przykadowo wyszukiwanie domniemanej wartoci dla typu

List[String]

sprawdzi obiekt towarzyszcy

List

i obiekt towarzyszcy

String

Jeli

jest typem singletonowym

p.type

, to czci typu

nale równie do zbioru

czci typu

. Oznacza to, e jeli typ

zosta zdefiniowany wewntrz obiektu,

to sam ten obiekt zostanie przeszukany pod ktem wartoci domniemanych.
Wicej na temat typów singletonowych znajdziesz w sekcji 6.1.1.

Jeli

jest projekcj typu

S#T

, to czci

s take czciami

. Oznacza to, e jeli

typ

zosta zdefiniowany wewntrz klasy lub cechy, to obiekty towarzyszce

tej klasie lub cesze zostan przeszukane pod ktem wartoci domniemanych.
Wicej na temat projekcji typów znajdziesz w sekcji 6.1.1.

Kup książkę

Poleć książkę

5.1.

Sowo kluczowe implicit

117

Zakres domniemany typu obejmuje wiele rónych lokalizacji i zapewnia du elastycz-
no, jeli chodzi o dostarczanie wartoci domniemanych.

Przeanalizujmy teraz co ciekawsze aspekty zakresu domniemanego.

AKRES DOMNIEMANY POPRZEZ PARAMETRY TYPU

Zgodnie ze specyfikacj jzyka Scala zakres domniemany typu obejmuje wszystkie obiekty
towarzyszce wszystkich typów i podtypów zawartych w parametrach typu. Oznacza to
na przykad, e moemy zdefiniowa warto domnieman dla

List[Foo]

, podajc j

w obiekcie towarzyszcym

Foo

. Oto przykad:

scala> object holder {
   |   trait Foo
   |   object Foo {
   |     implicit val list = List(new Foo{})
   |   }
   | }
defined module holder

scala> implicitly[List[holder.Foo]]
res0: List[holder.Foo] = List(holder$Foo$$anon$1@2ed4a1d3)

Obiekt

holder

suy nam, tradycyjnie, do stworzenia obiektów stowarzyszonych we-

wntrz REPL. Zawiera on cech

Foo

i jej obiekt towarzyszcy. Obiekt towarzyszcy za-

wiera definicj

List[Foo]

oznaczon sowem

implicit

. W nastpnej linii wywoujemy

funkcj Scali o nazwie

implicitly

. Pozwoli ona na wyszukanie typu w aktualnym zakresie

domniemanym. Definicja tej funkcji to

def

implicitly[T](implicit arg : T) = arg

. Pa-

rametr typu

pozwala nam wykorzysta j niezalenie od tego, jakiego typu encji szukamy.

Wicej o parametrach typów powiem w podrozdziale 6.2. Wywoanie

implicitly

typie

List[holder.Foo]

zwróci list zdefiniowan w obiekcie towarzyszcym

Foo

Mechanizm ten suy do implementacji cech typów, nazywanych te klasami typów.

Cechy typów to abstrakcyjne interfejsy wykorzystujce parametry typu, które mona
implementowa przy uyciu dowolnych typów. Przykadowo moemy zdefiniowa cech

BinaryFormat[T]

. Nastpnie mona zaimplementowa j dla danego typu, definiujc

w ten sposób jego serializacj do postaci binarnej. Oto przykad takiego interfejsu:

trait BinaryFormat[T] {
def asBinary(entity: T) : Array[Byte]
}

Cecha

BinaryFormat

definiuje jedn metod,

asBinary

. Pobiera ona instancj typu

zgodnego z parametrem typu i zwraca tablic bajtów reprezentujc przekazany para-
metr. Kod, który ma za zadanie przeprowadzi serializacj i zapisa obiekt na dysku, mo-
e odszuka cech typu

BinaryFormat

za porednictwem mechanizmu domniema. Mo-

emy doda implementacj dla naszego typu

Foo

, stosujc sowo

implicit

w obiekcie

towarzyszcym

Foo

trait Foo {}
object Foo {
implicit lazy val binaryFormat = new BinaryFormat[Foo] {
def asBinary(entity: Foo) = "zserializowaneFoo".getBytes
}
}

Kup książkę

Poleć książkę

118

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

Cecha

Foo

jest pusta. Jej obiekt towarzyszcy ma skadow

implicit val

przechowujc im-

plementacj

BinaryFormat

. Teraz gdy kod wymagajcy

BinaryFormat

widzi typ

Foo

moe w sposób domniemany odszuka

BinaryFormat

. Szczegóy tego mechanizmu i tej

techniki projektowania zostan dokadniej omówione w podrozdziale 7.2.

Domniemane wyszukiwanie na bazie parametrów typu i cech pozwala na uzyskanie

eleganckiego kodu. Inny sposób dostarczania i odnajdywania argumentów domniema-
nych jest oparty na typach zagniedonych.

AKRES DOMNIEMANY POPRZEZ TYPY ZAGNIEDONE

Zakres domniemany obejmuje take obiekty towarzyszce z zakresów zewntrznych,
jeli typ zosta zdefiniowany w zakresie zagniedonym. Pozwala nam to na stworzenie
zestawu podrcznych zmiennych domniemanych dla typu w zakresie zewntrznym. Oto
przykad:

scala> object Foo {
   | trait Bar
   | implicit def newBar = new Bar {
   |   override def toString = "Implicit Bar"
   | }
   | }
defined module Foo

scala> implicitly[Foo.Bar]
res0: Foo.Bar = Implicit Bar

Obiekt

Foo

to typ zewntrzny. Wewntrz niego zdefiniowana zostaa cecha

Bar

. Obiekt

Foo

dodatkowo zawiera opisan jako

implicit

metod tworzc instancj cechy

Bar

. Po

wywoaniu

implicitly[Foo.Bar]

warto domniemana zostanie odnaleziona w ze-

wntrznej klasie

Foo

. Ta technika jest bardzo podobna do umieszczania skadowych do-

mniemanych bezporednio w obiekcie towarzyszcym. Definiowanie domniemanych
skadowych dla typów zagniedonych przydaje si, gdy zakres zewntrzny ma kilka
podtypów. Technik t moemy stosowa, jeli nie jest moliwe utworzenie zmiennej
domniemanej w obiekcie towarzyszcym.

Obiekty towarzyszce w Scali nie mog by oznaczane jako

implicit

. Domniemane

encje zwizane z typem obiektu, jeli maj by dostpne w zakresie domniemanym, musz
by dostarczone w zakresie zewntrznym. Oto przykad:

scala> object Foo {
   |   object Bar { override def toString = "Bar" }
   |   implicit def b : Bar.type = Bar
   | }
defined module Foo

scala> implicitly[Foo.Bar.type]
res1: Foo.Bar.type = Bar

Obiekt

Bar

jest zagniedony wewntrz obiektu

Foo

. Obiekt

Foo

definiuje domnieman

skadow zwracajc

Bar.type

. Dziki takiej definicji wywoanie

implicitly[Foo.

´Bar.type]

zwróci obiekt

Bar

. W ten sposób jest moliwe definiowanie domniema-

nych obiektów.

Kup książkę

Poleć książkę

5.2.

Wzmacnianie klas za pomoc domniemanych widoków

119

Kolejny przypadek zagniedania, który moe zdziwi osoby nieprzyzwyczajone do

niego, to obiekty pakietowe. Poczwszy od wersji 2.8, obiekty mog by definiowane jako
obiekty pakietowe. Obiekt pakietowy to obiekt zdefiniowany z uyciem sowa kluczowego

package

. Konwencja w Scali nakazuje umieszcza wszystkie obiekty pakietowe w pliku

o nazwie

package.scala

w katalogu odpowiadajcym nazwie pakietu.

Kada klasa zdefiniowana wewntrz pakietu jest w nim zagniedona. Wszelkie encje

domniemane zdefiniowane w obiekcie pakietowym bd dostpne w zakresie domnie-
manym wszystkich typów zdefiniowanych wewntrz pakietu. Dziki temu mona ska-
dowa wartoci domniemane w wygodnej lokalizacji, bez potrzeby tworzenia obiektów
towarzyszcych dla kadego typu w pakiecie. Pokazuje to nastpujcy przykad:

package object foo {
implicit def foo = new Foo
}

package foo {
class Foo {
override def toString = "FOO!"
}
}

Obiekt pakietowy

foo

zawiera jedno pole

implicit

, zwracajce now instancj klasy

Foo

Nastpnie definiujemy klas

Foo

wewntrz pakietu

foo

. W Scali pakiety mog by de-

finiowane w wielu plikach, które w kocu zostan zagregowane i utworz jeden kom-
pletny pakiet. Jeden pakiet moe mie tylko jeden obiekt pakietowy, niezalenie od tego,
na ile plików zosta podzielony pakiet. Klasa

Foo

przesania metod

toString

— jej im-

plementacja wypisuje acuch

"FOO!"

. Skompilujmy pakiet

foo

i przetestujmy go w REPL:

scala> implicitly[foo.Foo]
res0: foo.Foo = FOO!

Nie musielimy importowa obiektu pakietowego ani jego skadowych. Kompilator sam
odnalaz domnieman warto obiektu

foo.Foo

. W Scali czsto mona natkn si na ze-

staw definicji domniemanych encji wewntrz obiektu pakietowego danej biblioteki. Z re-
guy obiekt pakietowy zawiera take domniemane widoki, suce do konwersji typów.

5.2.

Wzmacnianie klas za pomoc domniemanych widoków

Domniemany widok to automatyczna konwersja z jednego typu na drugi w celu spenie-
nia warunków stawianych przez wyraenie. Definicja domniemanego widoku ma nast-
pujc ogóln posta:

implicit def <nazwaKonwersji>(<nazwaArgumentu> : TypOryginalny) : TypWidoku

Powysza konwersja w sposób domniemany przeksztaca warto typu

TypOryginalny

warto typu

TypWidoku

, jeli jest dostpna w zakresie domniemanym.

Przeanalizujmy prosty przykad, w którym podejmiemy prób konwersji zmiennej

typu cakowitego na acuch znaków:

scala> def foo(msg : String) = println(msg)
foo: (msg: String)Unit

scala> foo(5)

Kup książkę

Poleć książkę

120

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

<console>:7: error: type mismatch;
found : Int(5)
required: String
foo(5)

Metoda

foo

pobiera warto

String

i wypisuje j w konsoli. Wywoanie

foo

z uyciem

wartoci

koczy si bdem, poniewa typy nie s zgodne. Domniemany widok jest

w stanie umoliwi to wywoanie:

scala> implicit def intToString(x : Int) = x.toString
intToString: (x: Int)java.lang.String

scala> foo(5)
5

Metoda

intToString

zostaa zdefiniowana jako

implicit

. Pobiera ona warto typu

Int

i zwraca

String

. Metoda ta jest domniemanym widokiem, czsto opisywanym jako

Int

=> String

. Teraz gdy wywoamy metod

foo

z wartoci

, wypisze ona acuch

"5"

Kompilator wykryje, e typy nie s zgodne, a take e istnieje widok, który moe roz-
wiza problem.

Domniemane widoki wykorzystuje si w dwóch sytuacjach:

Wyraenie nie pasuje do typu oczekiwanego przez kompilator. Wtedy kompilator
poszuka domniemanego widoku, który pozwoli przeksztaci warto do oczekiwanej
postaci. Przykad to przekazanie zmiennej typu

Int

do funkcji oczekujcej

wartoci

String

. Wówczas jest wymagane, by w zakresie istnia domniemany

widok

String => Int

Uyta zostaa selekcja

e.t

, przy czym typ

nie ma skadowej

. Kompilator

wyszuka domniemany widok, który zastosuje do

i którego typ zwracany zawiera

skadow

. Dla przykadu, jeli spróbujemy wywoa metod

foo

na wartoci

String

, kompilator wyszuka domniemany widok, który umoliwi kompilacj

wyraenia. Wyraenie

"foo".foo()

wymagaoby domniemanego widoku

wygldajcego mniej wicej tak:

implicit def stringToFoo(x : String) = new { def foo() : Unit = println("foo") }

Domniemane widoki wykorzystuj ten sam zakres domniemany co domniemane para-
metry. Jednak gdy kompilator sprawdza moliwoci przeksztacenia typu, wyszukuje
wedug typu ródowego, a nie docelowego. Przykad:

scala> object test {
   | trait Foo
   | trait Bar
   | object Foo {
   |   implicit def fooToBar(foo : Foo) = new Bar {}
   | }
   | }
defined module test

scala> import test._
import test._

Kup książkę

Poleć książkę

5.2.

Wzmacnianie klas za pomoc domniemanych widoków

121

Obiekt

test

jest kontenerem, który pozwala nam na utworzenie obiektu towarzyszcego

w ramach sesji REPL. Zawiera on cechy

Foo

oraz

Bar

, a take obiekt towarzyszcy

Foo

Obiekt towarzyszcy

Foo

obejmuje domniemany widok przeksztacajcy

Foo

Bar

. Pa-

mitaj, e gdy kompilator szuka domniemanych widoków, to typ ródowy definiuje
domniemany zakres. Oznacza to, e domniemane widoki zdefiniowane w obiekcie towa-
rzyszcym

Foo

zostan przeszukane tylko podczas próby konwersji z

Foo

na inny typ.

Na potrzeby testów zdefiniujmy metod oczekujc typu

Bar

scala> def bar(x : Bar) = println("bar")
bar: (x: test.Bar)Unit

Metoda

bar

pobiera obiekt

Bar

i wypisuje acuch znaków

"bar"

. Spróbujmy wywoa

j z argumentem typu

Foo

i zobaczmy, co si stanie:

scala> val x = new Foo {}
x: java.lang.Object with test.Foo = $anon$1@15e565bd

scala> bar(x)
bar

Warto

jest typu

Foo

. Wyraenie

bar(x)

zmusza kompilator do wyszukania do-

mniemanego widoku. Poniewa typ zmiennej

Foo

, kompilator szuka wród typów

powizanych z

Foo

. Wreszcie znajduje widok

fooToBar

i dodaje odpowiedni transforma-

cj, dziki czemu kompilacja koczy si sukcesem.

Mechanizm domniemanych konwersji pozwala nam na dopasowywanie do siebie

rónych bibliotek, a take na dodawanie do istniejcych typów naszych wasnych metod
pomocniczych. Adaptacja bibliotek Javy do postaci, w której dobrze wspópracuj z bi-
bliotek standardow Scali, to dosy czsta praktyka. Dla przykadu biblioteka standar-
dowa definiuje modu

scala.collection.JavaConversions

, usprawniajcy wspóprac

bibliotek do obsugi kolekcji w obu jzykach. Modu ten jest zestawem domniemanych
widoków, które mona zaimportowa do zakresu biecego w celu umoliwienia domnie-
manych konwersji pomidzy kolekcjami w Javie i w Scali, przez co moliwe staje si take
„dodawanie” metod do kolekcji Javy. Adaptacja bibliotek Javy czy wszelkich innych ze-
wntrznych bibliotek za pomoc domniemanych widoków to popularna praktyka w Scali.
Przeanalizujmy odpowiedni przykad.

Bdziemy chcieli opakowa pakiet

java.security

tak, by korzystanie z niego w Scali

byo wygodniejsze. Chodzi nam zwaszcza o uproszczenie zadania uruchamiania uprzy-
wilejowanego kodu za pomoc

java.security.AccessController

. Klasa

AccessController

(kontroler dostpu) zawiera statyczn metod

doPrivileged

(wykonaj uprzywilejowane),

która pozwala na uruchamianie kodu w uprzywilejowanym stanie uprawnie. Metoda

doPrivileged

ma dwa warianty. Pierwszy przyznaje kodowi uprawnienia z biecego

kontekstu, drugi pobiera obiekt

AccessControlContext

(kontekst kontroli dostpu), w któ-

rym s zdefiniowane uprawnienia do przyznania. Metoda

doPrivileged

pobiera argu-

ment typu

PrivilegedExceptionAction

(uprzywilejowana akcja), który jest cech defi-

niujc jedn metod:

run

(uruchom). Cecha ta przypomina cech Scali

Function0

, a my

chcielibymy móc uy funkcji anonimowej podczas wywoywania metody

doPrivileged

Stwórzmy domniemany widok przeksztacajcy typ

Function0

do postaci metody

doPrivileged

Kup książkę

Poleć książkę

122

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

object ScalaSecurityImplicits {
implicit def functionToPrivilegedAction[A](func : Function0[A]) =
  new PrivilegedAction[A] {
    override def run() = func()
  }
}

Zdefiniowalimy obiekt

ScalaSecurityImplicits

zawierajcy widok domniemany.

Widok

functionToPrivilegedAction

pobiera

Function0

i zwraca nowy obiekt

Privileged

´Action

, którego metoda

run

wywouje funkcj. Skorzystajmy z tego widoku:

scala> import ScalaSecurityImplicits._
import ScalaSecurityImplicits._

scala> AccessController.doPrivileged( () =>
| println("Ma przywileje"))
Ma przywileje

Pierwsza instrukcja importuje domniemany widok do zakresu. Nastpnie wywoujemy
metod

doPrivileged

, przekazujc jej anonimow funkcj

() => println("Ma przywileje")

Po raz kolejny kompilator wykrywa, e funkcja anonimowa nie pasuje do oczekiwanego
typu. Rozpoczyna wówczas wyszukiwanie i odnajduje domniemany widok zdefiniowany
w

ScalaSecurityImplicits

. T sam technik mona wykorzysta do opakowywania

obiektów Javy w obiekty Scali.

Czsto pisze si klasy opakowujce istniejce biblioteki Javy tak, by korzystay z bar-

dziej zaawansowanych konstrukcji Scali. Domniemane konwersje Scali mona zastoso-
wa w celu przeksztacania typu oryginalnego w opakowany i z powrotem. Dla przy-
kadu dodajmy kilka wygodnych metod do klasy

java.io.File

Zaczniemy od wprowadzenia specjalnej notacji — operator

bdzie tworzy nowe

pliki w danym katalogu. Stwórzmy klas opakowujc, która wprowadzi ten operator:

class FileWrapper(val file: java.io.File) {
def /(next : String) = new FileWrapper(new java.io.File(file, next))
override def toString = file.getCanonicalPath
}

Klasa

FileWrapper

w konstruktorze pobiera obiekt

java.io.File

. Definiuje ona now

metod

, która pobiera

String

i zwraca nowy obiekt

FileWrapper

. Nowy obiekt jest

powizany z plikiem o nazwie przekazanej metodzie

, wewntrz katalogu zwizanego

z oryginalnym plikiem. Na przykad jeli oryginalny

FileWrapper

o nazwie

file

by zwi-

zany z katalogiem

/tmp

, to wyraenie

file / "mylog.txt"

zwróci nowy obiekt

FileWrapper

powizany z plikiem

/tmp/mylog.txt

. Chcemy skorzysta z domniemanych widoków do

automatycznej konwersji pomidzy

java.io.File

FileWrapper

. Zacznijmy od dodania

domniemanego widoku do obiektu towarzyszcego

FileWrapper

object FileWrapper {
implicit def wrap(file : java.io.File) = new FileWrapper(file)
}

Obiekt towarzyszcy

FileWrapper

definiuje jedn metod,

wrap

, pobierajc

java.io.File

i zwracajc

FileWrapper

. Przetestujmy go teraz w sesji REPL:

scala> import FileWrapper.wrap
import FileWrapper.wrap

Kup książkę

Poleć książkę

5.2.

Wzmacnianie klas za pomoc domniemanych widoków

123

scala> val cur = new java.io.File(".")
cur: java.io.File = .

scala> cur / "temp.txt"
res0: FileWrapper = .../temp.txt

Pierwsza linia to import domniemanego widoku do naszego zakresu. Druga linia tworzy
nowy obiekt

java.io.File

, przekazujc konstruktorowi parametr

"."

. Ostatnia linia to

wywoanie metody

na zmiennej

cur

typu

java.io.File

. Kompilator nie znajdzie tej me-

tody w

java.io.File

, spróbuje wic wyszuka odpowiedni widok domniemany, umo-

liwiajcy kompilacj. Po znalezieniu metody

wrap

kompilator opakuje

java.io.File

FileWrapper

i wywoa metod

. W wyniku tego zostanie zwrócony obiekt

FileWrapper

Przedstawiony tu mechanizm stanowi doskonay sposób dodawania metod do istnie-

jcych klas Javy czy te do klas z rónych zewntrznych bibliotek. Tworzenie obiektu
opakowujcego moe wpyn na wydajno, jednak optymalizator HotSpot ma szans
na zminimalizowanie tego problemu. Pisz „ma szans”, poniewa nie mamy gwarancji,
e usunie on alokacj obiektu opakowujcego, jednak kilka niewielkich testów potwier-
dzio, e to robi. Jak zwykle lepiej jest przeprowadzi profilowanie aplikacji w celu wykrycia
problematycznych fragmentów, ni zakada, e optymalizator zrobi wszystko za nas.

Z metod

wie si pewien problem. Zwraca ona nowy obiekt

FileWrapper

Oznacza to, e nie moemy przekaza jej wyniku bezporednio do metody oczekujcej
zwykego obiektu

java.io.File

. Moglibymy zmieni j, by zwracaa

java.io.File

, ale

Scala oferuje jeszcze inne rozwizanie. Gdy przekaemy

FileWrapper

do metody oczeku-

jcej

java.io.File

, kompilator rozpocznie wyszukiwanie odpowiedniego widoku. Jak ju

wspomniaem, przeszukany zostanie take obiekt towarzyszcy typowi

FileWrapper

Dodajmy do niego domniemany widok

unwrap

(rozpakuj) i zobaczmy, czy zadziaa:

object FileWrapper {
implicit def wrap(file : java.io.File) = new FileWrapper(file)
implicit def unwrap(wrapper : FileWrapper) = wrapper.file
}

Obiekt towarzyszcy

FileWrapper

ma teraz dwie metody:

wrap

unwrap

. Metoda

unwrap

pobiera instancj

FileWrapper

i zwraca odpakowany typ

java.io.File

. Przetestujmy j

teraz w REPL.

scala> import test.FileWrapper.wrap
import test.FileWrapper.wrap

scala> val cur = new java.io.File(".")
cur: java.io.File = .

scala> def useFile(file : java.io.File) = println(file.getCanonicalPath)
useFile: (file: java.io.File)Unit

scala> useFile(cur / "temp.txt")
/home/jsuereth/projects/book/scala-in-depth/chapter5/wrappers/temp.txt

Pierwsza linia importuje widok domniemany

wrap

. Nastpna konstruuje obiekt

java.io.File

wskazujcy na biecy katalog. Trzecia linia definiuje metod

useFile

Metoda ta oczekuje wejcia typu

java.io.File

, którego ciek wypisze w konsoli.

Kup książkę

Poleć książkę

124

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

Ostatnia linia to wywoanie metody

useFile

z argumentem w postaci wyraenia

cur /

"temp.txt"

. Kompilator, jak zwykle, na widok metody

rozpocznie wyszukiwanie odpo-

wiedniego widoku domniemanego do przeprowadzenia konwersji. Wynikiem konwersji
bdzie

FileWrapper

, ale metoda

useFile

oczekuje typu

java.io.File

. Kompilator prze-

prowadzi kolejne wyszukiwanie za pomoc typu

Function1[java.io.File, FileWrapper]

W ten sposób znajdzie widok domniemany

unwrap

w obiekcie towarzyszcym

FileWrapper

Wszystkie typy si zgadzaj, zatem kompilacja koczy si sukcesem. W czasie wykonania
pojawi si oczekiwana warto typu

String

Zwró uwag na to, e do wywoania widoku

unwrap

nie jest nam potrzebna instrukcja

import

, wymagana w przypadku metody

wrap

. Jest tak dlatego, e obiekt

wrap

by po-

trzebny w sytuacji, gdy kompilator nie zna typu wymaganego do spenienia wyraenia

cur / "temp.txt"

, dlatego sprawdza tylko lokalne widoki, jako e

java.io.File

nie ma

obiektu towarzyszcego. Opisany tu mechanizm pozwala na stworzenie obiektu opako-
wujcego z dodatkowymi metodami, który jest w stanie niemale niezauwaalnie prze-
ksztaca obiekty z i do postaci opakowanej.

Zachowaj ostrono podczas dodawania funkcjonalnoci do istniejcych klas za po-

moc domniemanych widoków. Ten mechanizm sprawia, e trudno jest zauway kon-
flikt nazw pomidzy rónymi domniemanymi widokami typu. Na dodatek pociga on za
sob pewne nakady wydajnociowe, z którymi niekoniecznie poradzi sobie optymali-
zator HotSpot. Wreszcie programistom niekorzystajcym z nowoczesnego rodowiska
programistycznego nie jest atwo oceni, które domniemane widoki s wykorzystywane
w danym bloku kodu.

Regua

Unikaj domniemanych widoków

Domniemane widoki to najbardziej naduywana funkcjonalno Scali. Mimo e w wielu sytu-
acjach ich wprowadzenie moe si wydawa dobrym pomysem, w wikszoci z nich Scala
oferuje lepsze alternatywy. Zbyt dua liczba takich widoków z pewnoci utrudni nowemu
programicie wdroenie si w kod. Widoki s przydatne, jednak ich stosowanie naley ogra-
niczy do przypadków, w których rzeczywicie s najlepszym rozwizaniem.

Domniemane widoki w Scali pozwalaj uytkownikowi dopasowa istniejce API do
swoich potrzeb. W poczeniu z obiektami opakowujcymi i obiektami towarzyszcymi
widoki s w stanie radykalnie zmniejszy nakad pracy niezbdny do zintegrowania bi-
bliotek z podobnymi, ale nie takimi samymi interfejsami, a take pozwalaj na dodawanie
nowych funkcjonalnoci do istniejcych bibliotek. Domniemane widoki s kluczem do
pisania ekspresywnego kodu, jednak naley si z nimi obchodzi ostronie.

Kolejnym elementem powizanym z pojciem domniema s parametry domylne.

5.3.

Parametry domniemane i domylne

Argumenty domniemane to mechanizm pozwalajcy na uniknicie redundantnego spe-
cyfikowania parametrów. Argumenty domniemane wietnie uzupeniaj si z parametrami
domylnymi. Jeli nie podano parametru i nie odnaleziono dla niego wartoci domnie-
manej, zostanie wykorzystana warto domylna. W ten sposób moemy tworzy parame-
try domylne, które uytkownik moe pomin, ale zawsze ma moliwo ich okrelenia.

Kup książkę

Poleć książkę

5.3.

Parametry domniemane i domylne

125

Jako przykad zaimplementujmy zestaw metod wykonujcych obliczenia na macier-

zach. Bd one korzystay z wtków w celu zrównoleglenia oblicze. Jako projektant bi-
blioteki nie wiesz jednak, gdzie metody te bd wywoywane. Mog zosta uruchomione
w kontekcie, w którym nie wolno korzysta z wielowtkowoci, a moe maj ju swoj
wasn kolejk zada. Chcemy umoliwi uytkownikowi okrelenie sposobu korzystania
z wtków, ale chcemy take zapewni tryb domylny.

Zacznijmy od definicji klasy

Matrix

(macierz) na listingu 5.7.

Listing 5.7. Prosta klasa Matrix

class Matrix(private val repr : Array[Array[Double]]) {
def row(idx : Int) : Seq[Double] = {
  repr(idx)
}
def col(idx : Int) : Seq[Double] = {
  repr.foldLeft(ArrayBuffer[Double]()) {
    (buffer, currentRow) =>
      buffer.append(currentRow(idx))
      buffer
  } toArray
}
lazy val rowRank = repr.size
lazy val colRank = if(rowRank > 0) repr(0).size else 0
override def toString = "Macierz" + repr.foldLeft(") {
  (msg, row) => msg + row.mkString("\n|", " | ", "|")
}
}

Klasa

Matrix

pobiera tablic wartoci typu

Double

i zapewnia dwie podobne metody:

row

col

. Pobieraj one warto indeksu i zwracaj tablic wartoci z danego wiersza (

row

)

lub kolumny (

col

). Klasa

Matrix

zawiera take wartoci

rowRank

colRank

, zwracajce

odpowiednio liczb wierszy i kolumn. Wreszcie metoda

toString

wywietla przyjazn

reprezentacj danych w macierzy.

Klasa

Matrix

jest gotowa do zrównoleglenia. Zacznijmy od definicji przeznaczonego

do tego interfejsu:

trait ThreadStrategy {
def execute[A](func : Function0[A]) : Function0[A]
}

Interfejs

ThreadStrategy

(strategia wtków) definiuje jedn metod,

execute

(wyko-

naj). Pobiera ona funkcj, która zwraca warto typu

. Zwraca warto tego samego typu:

funkcj zwracajc warto

. Zwrócona funkcja powinna zwróci t sam warto co

funkcja przekazana, ale moe ona zablokowa aktualny wtek do momentu, w którym jej
warto zostanie wyznaczona w osobnym wtku. Zaimplementujmy nasz usug obli-
cze na macierzach, korzystajc z interfejsu

ThreadStrategy

object MatrixUtils {
def multiply(a: Matrix,
             b: Matrix)(
             implicit threading: ThreadStrategy): MatrixN = {
  ...
}
}

Kup książkę

Poleć książkę

126

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

Obiekt

MatrixUtils

zawiera metod

multiply

(mnó). Pobiera ona dwie macierze, za-

kadajc, e maj one odpowiednie wymiary, i zwraca now macierz, bdc wynikiem
mnoenia dwóch macierzy przekazanych jako parametry. Mnoenie macierzy polega
na mnoeniu wartoci z wierszy pierwszej macierzy przez wartoci z kolumn drugiej
i dodawaniu iloczynów. Takie mnoenie i sumowanie musi zosta osobno przeprowa-
dzone dla kadego elementu wynikowej macierzy. Prostym sposobem zrównoleglenia
oblicze jest wyliczenie kadej wartoci w osobnym wtku. Algorytm metody

Matrix

´Utils.multiply

jest prosty:

utwórz bufor do przechowywania wyników,

stwórz domknicie, które wyznaczy pojedyncz warto dla pary wiersz –
kolumna i umie j w buforze,

wylij stworzone w ten sposób domknicia do

ThreadStrategy

wywoaj funkcje zwrócone przez

ThreadStrategy

, by upewni si, e ich

wykonanie dobiego koca,

opakuj bufor w klas

Matrix

i go zwró.

Zacznijmy od utworzenia bufora:

def multiply(a: Matrix,
          b: Matrix)(
          implicit threading : ThreadStrategy): Matrix = {
assert(a.colRank == b.rowRank)
val buffer = new Array[Array[Double]](a.rowRank)
for ( i <- 0 until a.rowRank ) {
  buffer(i) = new Array[Double](b.colRank)
}
...
}

Pocztkowa instrukcja

assert

zostaa dodana w celu upewnienia si, e wymiary macie-

rzy pozwalaj na ich mnoenie. eby operacja ta bya moliwa, liczba kolumn w pierwszej
macierzy musi by równa liczbie wierszy w drugiej. Nastpnie tworzymy tablic tablic,
któr wykorzystamy jako bufor. Wynikowa macierz bdzie miaa t sam liczb wier-
szy co macierz

i t sam liczb kolumn co macierz

. Gdy bufor jest ju gotowy, mo-

emy przystpi do utworzenia zbioru domkni, które wylicz poszczególne wartoci
i umieszcz je w buforze (listing 5.8).

Listing 5.8. Mnoenie macierzy

def multiply(a: Matrix,
          b: Matrix)(
          implicit threading : ThreadStrategy): Matrix = {
...
def computeValue(row : Int, col : Int) : Unit = {
  val pairwiseElements =
    a.row(row).zip(b.col(col))
  val products =
    for((x,y) <- pairwiseElements)
       yield x*y
  val result = products.sum
  buffer(row)(col) = result
}
...

Kup książkę

Poleć książkę

5.3.

Parametry domniemane i domylne

127

Metoda pomocnicza

computeValue

(wylicz warto) pobiera numer wiersza i ko-

lumny, a nastpnie wylicza warto odpowiadajc tym elementom. Pierwszy krok to do-
pasowanie parami kolejnych elementów z wiersza

i kolumny

. Scala oferuje tu funkcj

zip

, która pobiera dwie kolekcje i dopasowuje do siebie ich elementy. Nastpnie spa-

rowane elementy s mnoone, w wyniku czego powstaje lista ich iloczynów. Wreszcie lista
ta jest sumowana. Wynik oblicze jest wstawiany w miejsce w buforze odpowiadajce
danemu wierszowi i danej kolumnie. Kolejn rzecz, jak musimy zrobi, jest skonstru-
owanie na podstawie tej metody funkcji, która bdzie wyznaczaa warto dla pary wiersz
– kolumna i przekazanie tej funkcji do odpowiedniej strategii:

val computations = for {
i <- 0 until a.rowRank
j <- 0 until b.colRank
} yield threading.execute { () => computeValue(i,j) }

Ptla

for

przechodzi przez kady wiersz i kad kolumn w macierzy wynikowej i przeka-

zuje funkcj do metody

execute

ThreadStrategy

. Skadnia

() =>

jest stosowana pod-

czas tworzenia obiektów funkcji anonimowych, które nie pobieraj argumentów, wy-
maganych przez typ

Function0

. Po przekazaniu pracy wtkom, a przed zwróceniem

wyników, metoda

multiply

musi „upewni si”, e praca zostaa wykonana. Robi to,

wywoujc kad metod zwrócon przez

ThreadStrategy

def multiply(a: Matrix,
b: Matrix)(
implicit threading : ThreadStrategy) : Matrix = {
...
computations.foreach(_())
new Matrix(buffer)
}

Ostatnia cz metody sprawdza, czy wszystkie obliczenia rzeczywicie zostay wykona-
ne, i zwraca obiekt

Matrix

zbudowany na podstawie bufora. Przetestujemy kod w sesji

REPL, ale najpierw musimy zaimplementowa interfejs

ThreadStrategy

. Stwórzmy pro-

st wersj, która wykonuje cao pracy w jednym wtku:

object SameThreadStrategy extends ThreadStrategy {
def execute[A](func : Function0[A]) = func
}

Strategia

SameThreadStrategy

sprowadza si do wykonania wszystkich oblicze w

jednym wtku — zwracana jest dokadnie ta sama funkcja, która zostaa przekazana
metodzie

execute

. Przetestujmy metod

multiply

w sesji REPL:

scala> implicit val ts = sameThreadStrategy
ts: ThreadStrategy.sameThreadStrategy.type = ...

scala> val x = new Matrix(Array(Array(1,2,3), Array(4,5,6)))
x: library.Matrix =
Macierz
|1.0 | 2.0 | 3.0|
|4.0 | 5.0 | 6.0|

scala> val y = new Matrix(Array(Array(1), Array(1), Array(1)))
y: library.Matrix =

Kup książkę

Poleć książkę

128

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

Macierz
|1.0|
|1.0|
|1.0|

scala> MatrixService.multiply(x,y)
res0: library.Matrix =
Macierz
|6.0|
|15.0|

W pierwszej linii tworzymy domnieman strategi

ThreadStrategy

, której bdziemy

uywa we wszystkich pozostaych przykadach. Nastpnie konstruujemy dwie macierze
i mnoymy je przez siebie. Macierz o wymiarach 2

u3 przemnoona przez macierz o wy-

miarach 3

u1 da wynik o wymiarach 2u1, zgodnie z oczekiwaniami. Wyglda na to, e

w ramach jednego wtku wszystko dziaa jak trzeba, zatem przejdmy do wersji wielo-
wtkowej (listing 5.9).

Listing 5.9. Strategia wspóbiena

import java.util.concurrent.{Callable, Executors}

object ThreadPoolStrategy extends ThreadStrategy {
  val pool = Executors.newFixedThreadPool(
               java.lang.Runtime.getRuntime.availableProcessors)
def execute[A](func : Function0[A] ) = {
  val future = pool.submit(new Callable[A] {
    def call() : A = {
      Console.println("Wykonanie funkcji w wtku: " +
                      Thread.currentThread.getName)
      func()
    }
  })
  () => future.get()
}
}

Tym razem implementacja

ThreadPoolStrategy

tworzy pul wtków, korzystajc z biblio-

teki

java.util.concurrent.Executors

. Liczba wtków w puli odpowiada liczbie dostp-

nych procesorów. Metoda

execute

pobiera przekazan jej funkcj i tworzy anonimow

instancj

Callable

. Interfejs

Callable

suy wanie do przekazywania zada do wy-

konania przez wtki z puli. Zwracany jest obiekt typu

Future

, dziki któremu jest moli-

we okrelenie, czy praca zostaa ju wykonana. Ostatnia linia

execute

zwraca anonimowe

domknicie, które wywoa metod

get

na obiekcie

future

. To wywoanie zablokuje pro-

gram do momentu, a oryginalna funkcja zakoczy dziaanie i zwróci wynik. Za kadym
razem, gdy wewntrz

Callable

jest wykonywana funkcja, wypisana zostanie informacja

o tym, który wtek za ni odpowiada. Wypróbujmy nasz kod w sesji REPL:

scala> implicit val ts = ThreadPoolStrategy
ts: ThreadStrategy.ThreadPoolStrategy.type = ...

scala> val x = new Matrix(Array(Array(1,2,3), Array(4,5,6)))
x: library.Matrix =

Kup książkę

Poleć książkę

5.3.

Parametry domniemane i domylne

129

Macierz
|1.0 | 2.0 | 3.0|
|4.0 | 5.0 | 6.0|

scala> val y = new Matrix(Array(Array(1), Array(1), Array(1)))
y: library.Matrix =
Macierz
|1.0|
|1.0|
|1.0|

scala> MatrixUtils.multiply(x,y)
Wykonanie funkcji w wtku: pool-2-thread-1
Wykonanie funkcji w wtku: pool-2-thread-2
res0: library.Matrix =
Macierz
|6.0|
|15.0|

W pierwszej linii tworzymy strategi

ThreadPoolStrategy

i oznaczamy j jako

implicit

Zmienne

to macierze o wymiarach 2

u3 i 3u1. Metoda

MatrixService.multiply

wypisuje teraz dwie linie, co oznacza, e obliczenia s wykonywane w rónych wtkach.
Wynikowa macierz zawiera poprawne wyniki, tak samo jak wczeniej.

A co by si stao, gdybymy chcieli zapewni domyln strategi wtków dla uyt-

kowników biblioteki, któr mogliby jednak nadpisa wedle potrzeb? Moemy skorzysta
z mechanizmu parametrów domylnych. Parametr domylny zostanie uyty, gdy w za-
kresie domniemanym nie bdzie dostpna odpowiednia warto, zatem uytkownicy bd
mogli nadpisa zakres domylny, importujc lub tworzc wasn strategi

ThreadStrategy

Uytkownicy mog take przesoni zachowanie pojedynczej metody, jawnie przekazujc

ThreadStrategy

. Zmiemy sygnatur metody

MatrixService.multiply

def multiply(a: Matrix, b: Matrix)(
implicit threading: ThreadStrategy = SameThreadStrategy
) : Matrix = {
...
}

Metoda

multiply

za domyln strategi uznaje teraz

SameThreadStrategy

. Korzystajc

z biblioteki, nie musimy ju okrela wasnej strategii:

scala> val x = new Matrix(Array(Array(1,2,3), Array(4,5,6)))
x: library.Matrix =
Macierz
|1.0 | 2.0 | 3.0|
|4.0 | 5.0 | 6.0|

scala> val y = new Matrix(Array(Array(1), Array(1), Array(1)))
y: library.Matrix =
Macierz
|1.0|
|1.0|
|1.0|

scala> MatrixService.multiply(x,y)
res0: library.Matrix =

Kup książkę

Poleć książkę

130

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

Macierz
|6.0|
|15.0|

Inaczej ni w przypadku zwykych parametrów domylnych, domniemana lista parame-
trów z wartociami domylnymi nie musi by oznaczona dodatkowymi nawiasami

()

. Ele-

gancja parametrów domniemanych zostaa poczona z uytecznoci parametrów do-
mylnych. Nadal moemy normalnie korzysta z parametrów domniemanych:

scala> implicit val ts = ThreadPoolStrategy
ts: ThreadStrategy.ThreadPoolStrategy.type = ...

scala> MatrixUtils.multiply(x,y)
Wykonanie funkcji w wtku: pool-2-thread-1
Wykonanie funkcji w wtku: pool-2-thread-2
res1: library.Matrix =
Macierz
|6.0|
|15.0|

Pierwsza linia tworzy w sposób domniemany dostpn strategi wtków. Od tej chwili
wywoanie

MatrixService.multiply

bdzie stosowao strategi

ThreadPoolStrategy

Uytkownicy usugi

MatrixService

mog dziki temu sami decydowa, kiedy zrównolegla

wykonywane przez ni obliczenia. Mog dostarczy domniemany obiekt strategii w danym
zakresie lub po prostu wywoa metod z odpowiednim parametrem

ThreadStrategy

Technika tworzenia domniemanej wartoci w zakresie obliczeniowym to przejaw

wzorca Strategia uytego w odpowiednim miejscu i w odpowiedni sposób. Wzorzec ten
ma zastosowanie wtedy, gdy fragment kodu musi wykona pewn operacj, lecz pewne
elementy zachowania — „strategia wykonania” — mog zosta zmienione. Przykadem
takiego zachowania jest obiekt

ThreadPoolStrategy

przekazywany do metod biblioteki

MatrixUtils

. Ta sama strategia moe zosta wykorzystana w wielu innych miejscach

systemu. Jest to kolejny obok dziedziczenia (omówionego w podrozdziale 4.3) sposób
skadania komponentów odpowiedzialnych za zachowanie aplikacji.

Kolejny dobry przykad zastosowania parametrów domniemanych i domylnych to

odczyt linii z pliku. W ogólnym przypadku uytkowników nie interesuje, czy linia jest za-
koczona sekwencj

, czy

\r\n

. Biblioteka programistyczna powinna jednak ob-

sugiwa wszystkie warianty. Mona zaprojektowa kod tak, by uytkownik móg nie-
obowizkowo poda znak koca linii, ale domyln wartoci byoby „bez rónicy”.

Parametry domniemane pozwalaj unikn nadmiarowego, powtarzajcego si kodu.

Naley jednak pamita o zachowaniu ostronoci — temu zagadnieniu jest powicony
nastpny podrozdzia.

5.4.

Ograniczanie zakresu encji domniemanych

Najwaniejszym wymaganiem podczas programowania z uyciem domniema jest g-
bokie rozumienie tego, co dzieje si w danym bloku kodu. Programista moe uatwi so-
bie zadanie, ograniczajc liczb miejsc, które musi sprawdzi w poszukiwaniu dostpnych
encji domniemanych. Oto ich moliwe lokalizacje:

obiekty towarzyszce wszelkich typów powizanych, w tym obiektów
pakietowych,

Kup książkę

Poleć książkę

5.4.

Ograniczanie zakresu encji domniemanych

131

obiekt

scala.Predef

wszelkie elementy zaimportowane do biecego zakresu.

Jak ju widzielimy w sekcji 1.1.3, Scala w poszukiwaniu zmiennych domniemanych
sprawdzi obiekty towarzyszce wszelkich typów powizanych. To zachowanie naley do
rdzenia jzyka. Obiekty towarzyszce i pakietowe powinny by uznawane za cz API
klasy. Uczc si nowej biblioteki, zawsze sprawdzaj obiekty towarzyszce i obiekty pa-
kietowe pod ktem domniemanych konwersji, z których bdziesz móg korzysta.

Regua

Ograniczaj zakres domniema

Poniewa konflikty encji domniemanych wymagaj zaawansowanego przekazywania argu-
mentów i konwersji, najbezpieczniej jest ich unika. Z tego powodu najlepiej ogranicza liczb
encji domniemanych w zakresie i udostpnia je w sposób, który mona ukry lub nadpisa.

Na pocztku kadego skompilowanego pliku Scali pojawia si domylna klauzula

import

scala.Predef._

. Obiekt

Predef

zawiera wiele uytecznych przeksztace, w tym te

pozwalajce na dodawanie metod do typu

java.lang.String

, dziki czemu wspiera on

metody wymagane w specyfikacji jzyka. Zawiera take przeksztacenia pomidzy
obiektami opakowujcymi typy proste w Javie i odpowiadajcymi im typami zunifiko-
wanymi w Scali. Dla przykadu w

scala.Predef

istnieje domylna konwersja

java.lang.Integer => scala.Int

. Podczas programowania w Scali warto zna prze-

ksztacenia dostpne w tym obiekcie.

Ostatnia moliwa lokalizacja encji domniemanych to instrukcje

import

w kodzie

ródowym. Zaimportowane encje domniemane do trudno jest wytropi, trudno
take je dokumentowa. Poniewa jest to jedyny przypadek domniema wymagajcy
instrukcji

import

w kadym pliku ródowym, powicimy mu najwicej uwagi.

5.4.1. Przygotowywanie encji domniemanych do zaimportowania

Podczas tworzenia nowego widoku lub parametru domniemanego, który w przyszoci
ma by jawnie importowany, upewnij si, e s spenione nastpujce warunki:

Domniemany widok lub parametr nie jest w konflikcie z inn domnieman encj.

Nazwa domniemanego widoku lub parametru nie jest w konflikcie z niczym
w obiekcie

scala.Predef

Domniemany widok lub parametr jest odkrywalny, to znaczy uytkownik
biblioteki lub moduu powinien by w stanie zlokalizowa domnieman
encj i zrozumie jej przeznaczenie.

Poniewa Scala wyszukuje encje domniemane w dostpnym zakresie, konflikt pomidzy
dwiema domniemanymi definicjami moe prowadzi do powstania problemów. Konflikty
takie bywaj trudne do wykrycia, poniewa widoki i parametry mog by definiowane
w dowolnym zakresie i importowane. Obiekt

scala.Predef

w sposób domniemany im-

portuje ca swoj zawarto do kadego pliku Scali, dlatego konflikty z jego skadowymi
szybko si uwidaczniaj. Zobaczmy, co si stanie w przypadku konfliktu:

object Time {
case class TimeRange(start : Long, end : Long)
implicit def longWrapper(start : Long) = new {

Kup książkę

Poleć książkę

132

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

def to(end : Long) = TimeRange(start, end)
}
}

Powyszy kod definiuje obiekt

Time

(czas) zawierajcy klas

TimeRange

(przedzia czasowy).

Mamy te domnieman konwersj na typie

Long

, dodajc do niego metod

. Za po-

moc tej metody moesz konstruowa przedziay czasowe.

Domniemana konwersja

longWrapper

jest w konflikcie z encj

scala.Predef.long

´Wrapper

, która midzy innymi oferuje widok domylny take zawierajcy metod

. Ta

metoda

zwraca obiekt

Range

(przedzia), który moe zosta uyty w ptli

for

. Wyobra

sobie scenariusz, w którym kto stosuje nasz domnieman konwersj w celu definiowa-
nia przedziaów czasowych, ale póniej chce odwoa si do oryginalnego widoku
zdefiniowanego w

Predef

, poniewa ma zamiar napisa ptl

for

. Jednym z rozwiza

jest zaimportowanie widoku z

Predef

z wyszym priorytetem w wszym zakresie — tylko

tam, gdzie jest potrzebny. Taki kod nie jest zbyt czytelny, co wida na listingu 5.10.

Listing 5.10. Priorytety i zakresy

object Test {
println(1L to 10L)
import Time._
println(1L to 10L)
def x() = {
  import scala.Predef.longWrapper
  println(1L to 10L)
  def y() = {
    import Time.longWrapper
    println(1L to 10L)
  }
  y()
}
x()
}

Obiekt

Test

natychmiast po swojej definicji wypisuje w konsoli wyraenie

(1L to 10L)

Nastpnie importujemy domniemane encje z

Time

i jeszcze raz wypisujemy wynik wyra-

enia. Dalej, w zagniedonym zakresie, importujemy

longWrapper

Predef

i ponownie

wypisujemy wynik na wyjciu. Na koniec, jeszcze gbiej, importujemy

longWrapper

Time

i wypisujemy wynik. Oto co pojawi si na wyjciu:

scala> Test
NumericRange(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
TimeRange(1,10)
NumericRange(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
TimeRange(1,10)
res0: Test.type = Test$@2d34ab9b

Pierwsza wypisana linia typu

NumericRange

(zakres liczbowy) to wynik wyraenia

(1L to 10L)

przed jakkolwiek instrukcj

import

. Dalej mamy wynik

TimeRange

, zwrócony

dziki zaimportowaniu domniemanego widoku z

Time

. Dalej pojawia si

NumericRange

zwizany z zakresem zagniedonym w metodzie

x()

, a ostatni wynik

TimeRange

to wynik

z najbardziej zagniedonej metody

y()

. Gdyby obiekt

Test

zawiera wicej takiego kodu

Kup książkę

Poleć książkę

5.4.

Ograniczanie zakresu encji domniemanych

133

i kod ten nie mieciby si w jednym oknie, trudno byoby przewidzie, jaki bdzie wynik
wyraenia

(1L to 10L)

w danym miejscu. Unikaj tego typu zawikanych sytuacji. Najle-

piej wystrzega si konfliktów w definicji domniemanych widoków, jednak nie zawsze
jest to proste. W trudnych sytuacjach mona zdecydowa, e jedna z konwersji bdzie
domniemana, natomiast inne bd wywoywane tradycyjnie.

Projektowanie odkrywalnych domniemanych encji zwiksza czytelno kodu, ponie-

wa nowemu programicie atwiej jest zrozumie, co dzieje si w danym fragmencie
kodu i co powinno si w nim dzia. Znaczenie odkrywalnych encji ronie podczas pracy
w zespole. W spoecznoci Scali panuje ogólna zgoda na ograniczenie importowalnych
encji domniemanych do jednego z dwóch miejsc:

obiektów pakietowych,

obiektów singletonowych z postfiksowymi (przyrostkowymi) widokami
domniemanymi.

Obiekty pakietowe s doskonaym miejscem do skadowania encji domniemanych,
poniewa i tak s one w zakresie domniemanym dla typów zdefiniowanych wewntrz
pakietu. Uytkownicy powinni szuka w obiekcie pakietowym encji domniemanych zwi-
zanych z pakietem. Umieszczenie w obiekcie pakietowym domniemanych encji wymagaj-
cych jawnego importu zwikszy ich szanse na to, e zostan zauwaone przez uytkownika.
Podczas korzystania z obiektu pakietowego do przechowywania encji domniemanych
zawsze dokumentuj, czy wymagaj one jawnych importów.

Lepszym rozwizaniem ni dokumentowanie jawnych importów domniemanych encji

jest cakowita rezygnacja z instrukcji

import

5.4.2. Parametry i widoki domniemane bez podatku od importu

Parametry i widoki domniemane wietnie sobie radz bez instrukcji

import

. Ich drugo-

rzdne reguy wyszukiwania, sprawdzajce obiekty towarzyszce typów powizanych,
pozwalaj na definiowanie domniemanych konwersji i wartoci, które nie wymagaj
uywania instrukcji

import

. Przy odrobinie kreatywnoci jest moliwe stworzenie eks-

presywnych bibliotek, które w peni wykorzystuj si domniema bez potrzeby impor-
towania. Przeanalizujemy to zadanie na przykadzie, za który posuy nam biblioteka do
reprezentacji liczb zespolonych.

Liczby zespolone to liczby, które skadaj si z czci rzeczywistej i urojonej. Cz

urojona jest mnoona przez pierwiastek kwadratowy z –1, znany take jako i (lub j w dzie-
dzinie elektrotechniki). W Scali atwo zamodelowa tak liczb za pomoc tzw. klasy
wzorcowej (

case class

) — prostej klasy bdcej kontenerem na wartoci.

package complexmath
case class ComplexNumber(real : Double, imaginary : Double)

Klasa

ComplexNumber

definiuje cz rzeczywist jako pole

real

typu

Double

. Cz

urojona to pole

imaginary

, take typu

Double

. Klasa reprezentuje liczby zespolone przy

uyciu arytmetyki zmiennoprzecinkowej w poszczególnych czciach. Liczby zespolone
mona dodawa i mnoy, stwórzmy wic przeznaczone do tego metody (listing 5.11).

Kup książkę

Poleć książkę

134

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

Listing 5.11. Klasa ComplexNumber reprezentujca liczb zespolon

package complexmath

case class ComplexNumber(real : Double, imaginary : Double) {
def *(other : ComplexNumber) =
  ComplexNumber( (real*other.real) - (imaginary * other.imaginary),
                (real*other.imaginary) + (imaginary * other.real) )
def +(other : ComplexNumber) =
  ComplexNumber( real + other.real, imaginary + other.imaginary )
}

Dodawanie (

) polega na dodaniu do siebie osobno czci rzeczywistej i urojonej dwóch

liczb. Mnoenie (

) jest nieco bardziej zoone. Definiuje si je w nastpujcy sposób:

Cz rzeczywista iloczynu dwóch liczb zespolonych to iloczyn ich
komponentów rzeczywistych pomniejszony o iloczyn ich czci urojonych:

(real*other.real) - (imaginary * other.imaginary)

Cz urojona iloczynu dwóch liczb zespolonych to suma iloczynów czci
rzeczywistej jednej liczby z czci urojon drugiej:

(real*other.imaginary) +

(imaginary * other.real)

Klasa

ComplexNumber

wspiera teraz dodawanie i mnoenie. Zobaczmy j w akcji:

scala> ComplexNumber(1,0) * ComplexNumber(0,1)
res0: imath.ComplexNumber = ComplexNumber(0.0,1.0)

scala> ComplexNumber(1,0) + ComplexNumber(0,1)
res1: imath.ComplexNumber = ComplexNumber(1.0,1.0)

Pierwsza linia mnoy liczb rzeczywist z liczb urojon — wynikiem jest liczba urojona.
Druga linia dodaje do siebie liczb rzeczywist i urojon, tworzc liczb zespolon. Ope-
ratory

dziaaj zgodnie z oczekiwaniami, jednak wywoywanie metody wytwór-

czej

ComplexNumber

jest troch mczce. Mona to uproci, stosujc now notacj dla

liczb zespolonych.

W matematyce liczby zespolone najczciej przedstawia si jako sum czci rzeczy-

wistej i urojonej. Liczba

ComplexNumber(1.0,1.0)

zostaaby zapisana jako

1.0 + 1.0*i

gdzie

to jednostka urojona, odpowiadajca pierwiastkowi kwadratowemu z –1. Taka

notacja byaby optymaln skadni dla biblioteki zajmujcej si liczbami zespolonymi.
Zdefiniujmy symbol i powimy go z pierwiastkiem kwadratowym z –1.

package object complexmath {
val i = ComplexNumber(0.0,1.0)
}

Zdefiniowalimy w ten sposób warto

val i

w obiekcie pakietowym

complexmath

. Nazwa

staje si dostpna w caym pakiecie, moliwe jest take jej bezporednie importowanie.

Za jej pomoc mona konstruowa liczby zespolone z ich czci rzeczywistej i urojonej.
Cigle jednak brakuje pewnego elementu, co pokazuje nastpujca sesja REPL:

scala> i * 1.0
<console>:9: error: type mismatch;
found : Double(1.0)
required: ComplexNumber
i * 1.0

Kup książkę

Poleć książkę

5.4.

Ograniczanie zakresu encji domniemanych

135

Próba pomnoenia naszej liczby urojonej przez warto typu

Double

koczy si niepowo-

dzeniem, poniewa typ

ComplexNumber

definiuje mnoenie jedynie dla zmiennych typu

ComplexNumber

. W matematyce moliwe jest mnoenie liczb rzeczywistych przez ze-

spolone, poniewa na liczb rzeczywist mona spojrze jak na liczb zespolon bez
czci urojonej. T waciwo liczb rzeczywistych mona emulowa w Scali za pomoc
domniemanej konwersji z

Double

ComplexNumber

package object complexmath {
implicit def realToComplex(r : Double) = new ComplexNumber(r, 0.0)
val i = ComplexNumber(0.0, 1.0)
}

Obiekt pakietowy

complexmath

zawiera teraz take definicj wartoci

oraz domniemanej

konwersji z

Double

ComplexNumber

o nazwie

realToComplex

. Chcielibymy ograniczy

zastosowanie tej konwersji do przypadków, w których jest ona absolutnie konieczna.
Spróbujmy zastosowa pakiet

complexmath

bez jawnego importowania adnych konwersji:

scala> import complexmath.i
import complexmath.i

scala> val x = i*5.0 + 1.0
x: complexmath.ComplexNumber = ComplexNumber(1.0,5.0)

Warto

val x

zostaa zadeklarowana za pomoc wyraenia

i*5 + 1

i ma typ

ComplexNumber

Cz rzeczywista to

1.0

. a cz urojona

5.0

. Zwró uwag, e tylko nazwa

zostaa

zaimportowana z

complexmath

. Pozostae domniemane konwersje s wywoywane z obiektu

, gdy tylko kompilator napotyka wyraenie

i*5

. O wartoci

wiadomo, e jest liczb

zespolon

ComplexNumber

i e definiuje metod

, która wymaga drugiej wartoci typu

ComplexNumber

. Litera

5.0

nie jest typu

ComplexNumber

, tylko

Double

. Kompilator rozpo-

czyna zatem wyszukiwanie domniemanej konwersji

Double => complexmath.ComplexNumber

znajdujc wreszcie konwersj

realToComplex

w obiekcie pakietowym. Nastpnie kompi-

lator napotyka wyraenie

(... : ComplexNumber) + 1.0

. Znajduje wtedy metod

zde-

finiowan w

ComplexNumber

, która akceptuje drugi obiekt

ComplexNumber

. Warto

1.0

typ

Double

, a nie

ComplexNumber

, zatem znowu rozpocznie si wyszukiwanie domniemanej

konwersji

Double => ComplexNumber

. Oczywicie poszukiwania kocz si sukcesem,

dziki czemu ostatecznie jest zwracany wynik

ComplexNumber(1.0, 5.0)

Zauwa, e to warto

powoduje uruchomienie oblicze na liczbach zespolonych.

Gdy tylko pojawia si liczba zespolona, kompilator znajduje odpowiednie konwersje, po-
zwalajce na kompilacj wyrae. Skadnia jest elegancka i zwiza, nie musielimy take
importowa adnych konwersji. Minusem jest to, e w tej sytuacji jest konieczne od-
woanie si na samym pocztku do wartoci

, by zostaa stworzona pierwsza liczba

typu

ComplexNumber

. Zobaczmy, co si stanie, gdy

pojawi si pod koniec wyraenia:

scala> val x = 1.0 + 5.0*i
<console>:6: error: overloaded method value * with alternatives:
(Double)Double <and>
(Float)Float <and>
(Long)Long <and>
(Int)Int <and>
(Char)Int <and>
(Short)Int <and>
(Byte)Int
cannot be applied to (complexmath.ComplexNumber)
val x = 1 + 5*i

Kup książkę

Poleć książkę

136

OZDZIA

Domniemane wartoci i widoki podstaw ekspresywnego kodu

Kompilator narzeka, poniewa nie moe znale metody

zdefiniowanej w typie

Double

która pobieraaby argument typu

ComplexNumber

. Ten problem mona rozwiza, im-

portujc domniemany widok

Double => ComplexNumber

do naszego zakresu:

scala> import complexmath.realToComplex
import complexmath.realToComplex

scala> val x = 1.0 + 5.0*i
x: complexmath.ComplexNumber = ComplexNumber(1.0,5.0)

Najpierw importujemy widok

realToComplex

. Teraz wyraenie

1 + 5*i

daje oczekiwany

wynik

ComplexNumber(1.0,5.0)

. Minusem jest to, e w zakresie typu

Double

pojawi si

dodatkowy domniemany widok. Moe to spowodowa kopoty, gdy zostan zdefinio-
wane inne domniemane widoki o metodach podobnych do

ComplexNumber

. Zdefiniuj-

my now domnieman konwersj, która doda do typu

Double

metod

imaginary

scala> implicit def doubleToReal(x : Double) = new {
| def real = "Rzeczywista(" + x + ")"
| }
doubleToReal: (x: Double)java.lang.Object{def real: java.lang.String}

scala> 5.0 real
<console>:10: error: type mismatch;
found : Double
required: ?{val real: ?}
Note that implicit conversions are not applicable
because they are ambiguous:
both method doubleToReal in object $iw of type
(x: Double)java.lang.Object{def real: java.lang.String}
and method realToComplex in package complexmath of type
(r: Double)complexmath.ComplexNumber
are possible conversion functions from
Double to ?{val real: ?}
5.0 real

Pierwsza instrukcja definiuje domniemany widok dla typu

Double

, który dodaje nowy typ

zawierajcy metod

real

. Metoda

real

zwraca warto

Double

w postaci acucha znaków

String

. Kolejna linia to próba wywoania metody

real

, zakoczona niepowodzeniem.

Kompilator informuje o znalezieniu niejednoznacznych domniemanych konwersji. Pro-
blem polega na tym, e typ

ComplexNumber

równie definiuje metod

real

, zatem do-

mniemana konwersja pomidzy typami

Double => ComplexNumber

kóci si z konwersj

domnieman

doubleToReal

. Konfliktu mona unikn, rezygnujc z importowania konwersji

Double => ComplexNumber

scala> import complexmath.i
import complexmath.i

scala> implicit def doubleToReal(x : Double) = new {
| def real = " Rzeczywista(" + x + ")"
| }
doubleToReal: (x: Double)java.lang.Object{def real: java.lang.String}

scala> 5.0 real
res0: java.lang.String = Rzeczywista(5.0)

Kup książkę

Poleć książkę

5.5. Podsumowanie

137

Rozpoczynamy tu now sesj REPL, w której importujemy jedynie

complexmath.i

Kolejna instrukcja redefiniuje konwersj

doubleToReal

. Teraz wyraenie

5.0 real

kom-

piluje si poprawnie, poniewa nie wystpuje konflikt.

Takie konstrukcje pozwalaj na tworzenie ekspresywnego kodu bez niebezpiecze-

stwa konfliktu pomidzy domniemanymi przeksztaceniami. Mona tu zaproponowa
nastpujcy wzorzec:

Zdefiniuj podstawowe abstrakcje dla biblioteki, takie jak klasa

ComplexNumber

Zdefiniuj domniemane konwersje niezbdne do powstania ekspresywnego
kodu w jednym z typów powizanych konwersj. Konwersja

Double =>

ComplexNumber

zostaa zdefiniowana w obiekcie pakietowym

complexmath

powizanym z typem

ComplexNumber

, dziki czemu jest odkrywalna w kodzie

korzystajcym z typu

ComplexNumber

Zdefiniuj punkt wejcia do biblioteki, na podstawie którego ujednoznaczniane
bd domniemane konwersje. W przypadku biblioteki

complexmath

punktem

wejcia jest warto

W niektórych sytuacjach nadal jest konieczne jawne zaimportowanie widoku.
W bibliotece

complexmath

punkt wejcia

pozwala na konstruowanie pewnych

typów wyrae, jednak inne typy, cho intuicyjnie wydaj si poprawne, nie
zadziaaj. Przykadowo

(i * 5.0 + 1.0)

jest akceptowane, a

(1.0 + 5.0*i)

nie. W tej sytuacji mona zaimportowa konwersj z dobrze znanej lokalizacji.
W

complexmath

t lokalizacj stanowi obiekt pakietowy.

Trzymajc si powyszych wytycznych, bdziesz w stanie tworzy API, które bd nie tylko
ekspresywne, ale take odkrywalne.

5.5. Podsumowanie

Ten rozdzia by powicony kwestii domniemanych wartoci i widoków oraz mechani-
zmowi ich wyszukiwania. Wartoci domniemane wykorzystuje si do przekazywania pa-
rametrów wywoaniom metod. Domniemane widoki su do konwersji pomidzy typami
oraz do wywoywania metod na zmiennych, których oryginalny typ na to nie pozwala.
Wyszukiwanie domniemanych parametrów i widoków jest oparte na tym samym me-
chanizmie. Proces odnajdywania domniemanej encji przebiega dwuetapowo. Najpierw
jest podejmowana próba odnalezienia encji, które nie maj prefiksu w biecym zakresie.
Drugi etap to sprawdzenie obiektów towarzyszcych typom powizanym. Domniemane
encje pozwalaj na rozszerzanie istniejcych klas. Dodatkowo mona je poczy z pa-
rametrami domylnymi w celu uproszczenia wywoa metod i powizania zachowania
z zakresem domniemanej wartoci.

Najistotniejsze jest to, e domniemania to potne narzdzie, które powinno by sto-

sowane rozsdnie. Kluczem do sukcesu jest ograniczanie zakresu domniemanych encji
i definiowanie ich w dobrze znanych lub atwo odkrywalnych lokalizacjach. Mona
osign ten cel, zapewniajc jednoznaczne punkty wejcia dla domniemanych konwersji
oraz ekspresywne API. Domniemane encje w bardzo ciekawy sposób cz si z syste-
mem typów Scali. Wrócimy do tego tematu w rozdziale 7., na razie zajmijmy si samym
systemem typów.

Kup książkę

Poleć książkę

Skorowidz

adaptacja bibliotek Javy, 121
adnotacja, 254, 271

@BeanProperty, 272
@reflect.BeanInfo, 272
@switch, 81
@tailrec, 81, 83
override, 105

adnotacje optymalizacyjne, 78
aktor HeadNode, 234
aktorzy, 231

anonimowi, 236
transakcyjni, 244

algorytm

MatrixUtils.multiply, 126
podkradania pracy, 245
przeszukiwania wszerz, 82
Quicksort, 25, 224
rozprosz-zgromad, 236
sortowania, 186

algorytmy rekurencyjne

ogonowo, 207

analiza ucieczki, escape analysis,

AnyRef, 21
API kolekcji, 274
argumenty

domniemane, 124
domylne, 97

automat stanowy, 247
automatyczna konwersja typów

prostych, 26

automatyczne

formatowanie kodu, 63
opakowywanie typów, 255,

257

zarzdzanie zasobami, 292

AWT, Abstract Windows

Toolkit, 245

biblioteka

AKKA, 244, 248, 251
Collections, 160
Google Collections, 20
MatrixUtils, 130
MetaScala, 187
scala.actors, 250
scalaj-collections, 267
Scalaz, 296

biblioteki Javy, 28
binarny Vector, 211
bd

czasu wykonania, 80
kompilacji, 66, 75

cecha

App, 87
Application, 86
Applicative, 287
ArraySortTrait, 228
BinaryFormat, 117
BinaryTree, 206
Config, 279
DataAccess, 94
DefaultHandles, 149
DelayedInit, 86
Dependencies, 166
FileLike, 182
Foo, 100
Function, 160
Gen*, 199
GenericSortTrait, 227
HasLogger, 96
HList, 188
IndexedSeq, 207
IndexedView, 190

Iterable, 203
Job, 270
LeafNode, 248
LinearSeq, 205
LinearSeqLike, 226
Logger, 94
ManagedResource, 292
Map, 208
MessageDispatcher, 103
Monad, 284
Nat, 193
NetworkEntity, 90
OutputChannel, 235
ParentNode, 249
Property, 88
PureAbstract, 102
SchedulingService, 270
SearchNode, 237
Seq, 204
Set, 178, 208
SimulationEntity, 89
Synchronized*, 218
TBool, 187
Traversable, 200

cechy, traits, 85

funkcyjne, 29
typów, 117

cele adnotacji, 272
cig Fibonacciego, 215

dane audio, 205
definicje typów, 140
definiowanie funkcji

anonimowych, 26

deklaracje lokalne, 114
dekorowanie nazw, name

mangling, 68

deserializacja, 268

Kup książkę

Poleć książkę

298

Skorowidz

domieszki, mixins, 85
domniemana konwersja kolekcji,

264

domniemane

encje, 137
konwersje, 26, 254, 259, 263
ograniczenia typu, 171
parametry, 108
widoki, 119, 124, 137, 264
wyszukiwanie, 118

domniemany zakres typu, 115
domylna implementacja klasy

typu, 183

drzewo

binarne, 207
rozprosz-zgromad, 248
trie, 210
wyszukiwania, 246

DSL, Domain-Specific

Language, 35

dynamiczna

deoptymalizacja, dynamic

deoptimization, 31

zmiana ksztatu, 250

dziedziczenie, 72, 85, 93

domieszkowe, 105
wielokrotne, 76, 78, 87

EJB, Enterprise Java Beans, 20,

221

encja, entity, 109
encje domniemane, 130
endofunktor, 284
ewaluacja zachanna, 219

fabryka

instancji SearchTree, 247
MessageDispatcher, 103

faza

gromadzenia, 233
rozpraszania, 233

framework

Akka 2.0, 251
Spring, 20

funkcja, 160

environment, 289
mieszajca, 47
readFile, 291
synchronize, 180
unobserve, 148

funkcje Scali w Javie, 29
funktor ManagedResource, 292
funktory, 281

generyki, 254
grawis, backtick, 98

heterogeniczne listy typowane,

187

hierarchia

cech, 91
domieszek, 93
klas, 89, 288
kolekcji, 198
loggerów, 96
Traversable, 199

IDE, 62
identyfikatory, 109
implementacja, 86

funktora, 283
HList, 188

import domniemanego widoku,

123

inicjalizacja opóniona, 86
instrukcja, 39

goto, 83
import, 110, 131
match, 79
tableswitch, 79

integracja Scali z Jav, 28, 253
interfejs, 86

Callable, 128
FileLike, 179
Iterable, 203
JdbcTemplate, 21
List, 161, 163

Observable, 148
Predicate, 22
PreparedStatementCreator,

RowMapper, 21
ThreadStrategy, 125

interfejsy

abstrakcyjne, 99–102
wyszego rzdu, 181

iterator Splitable, 221
iteratory, 200

jawny import, 113
jzyki

dziedzinowe DSL, 35
imperatywne, 41
obiektowe, 85, 99

JPA, Java Persistence API, 273
JVM, 18, 28, 30

kierunek wywoania metody, 26
klasa

AbstractAddress, 262
AccessController, 121
ActorDispatcher, 103
Address, 261, 263
Application, 288
Applicative, 287
ApplicativeBuilder, 290
Average, 69
Branch, 206
CanBuildFrom, 225
ComplexNumber, 133
Config, 289
DataAccess, 94
EmptyList, 161
Event, 57
FileLineTraversable, 200
FileWrapper, 122
Foo, 109, 111
Foo$, 274
FooHolder, 64
HasLogger, 96
HList, 196
HListViewN, 192

Kup książkę

Poleć książkę

Skorowidz

299

HNil, 189
InstantaneousTime, 55
Iterator, 257
Jdbc-Template, 20
List, 215
LoggedDataAccess, 95
Logger, 95
Main, 100
Manifest, 173
Matrix, 125
None, 51
Option, 51
Point2, 44
Router with NetworkEntity,

ScalaMain, 100
SearchQuery, 232, 236
SeqLike, 225
Simple, 271
Some, 51
Sortable, 226
Sorter, 186
T, 116
test.Foo, 110
Traversable, 202
UserServiceImpl, 75
VariableStore, 149

klasy towarzyszce, 36
klasy typu, 178, 181, 226

bezpieczestwo dla typów, 185
kompozycyjno, 184
przesanialno, 185
rozdzielenie abstrakcji, 184

kolejno operacji, 42
kolekcja, 197

ArrayBuffer, 217
ArrayBufferwithObservable

Buffer, 218

BitSet, 208
HashSet, 208
List, 212
ParVector, 222
Stream, 213
Traversable, 200
TreeSet, 208
Vector, 210

kolekcje

modyfikowalne, 216
niemodyfikowalne, 210, 216
równolege, 221

kompilacja klasy Main, 99
kompilator HotSpot, 31
kompilowanie

cech, 86
obiektu, 86

komponenty

encyjne, entity beans, 20
sesyjne, session beans, 20

kompozycja, 93
kompozycja i dziedziczenie, 96
komunikaty o bdzie, 184
konfiguracja aplikacji, 289
konflikt

encji domniemanych, 131
nazw, 110
pomidzy domniemanymi

przeksztaceniami, 137

konsolidacja klas, 101
konstruktor, 86
konstruktory typu, 155
kontener

None, 51
Some, 51

kontrawariancja, 157
konwersje

domniemane, 26
kodowania, 63

konwersja

doubleToReal, 136
na ComplexNumber, 135
typu, 119
typu Byte, 27

kowariancja, covariance, 156

lambda, 26
lambdy typu, 156
leniwa ewaluacja, 22, 215
liczba wtków w puli, 128
liczby naturalne, 193
liczby zespolone

cz rzeczywista, 134
cz urojona, 134

linearyzacja

cech, 93
klas, 76, 90

lista, 213

Nil, 213
uchwytów, 166

listy

heterogeniczne, 187, 195
HList, 196

logowanie, 201

acuchy domniemanych

widoków, 265

czenie

obiektów modyfikowalnych,

predykatów, 23

macierz, 125
magazynowanie danych, 271
manifest

ClassManifest, 173
Manifest, 173
OptManifest, 173

manifesty typu, 172
mapa

addresses, 209
errorcodes, 209

mapowanie biblioteki, 29
maszyna wirtualna Javy, 18
mechanizm

obsugi bdów, 243
wnioskowania, 108, 154

metoda

:, 189
##, 45, 56
++, 163
==, 45, 56, 150
act, 238
Actor.actorOf, 250
add2, 256
Applicative.build, 290
apply, 22
asScala, 266
avg$default$1, 70
build, 290
canEqual, 58, 59
child, 178
createDispatcher, 103
createErrorMessage, 39, 41
delayedInit, 86
doPrivileged, 121

Kup książkę

Poleć książkę

300

Skorowidz

metoda

DriverManager.

getConnection, 289

environment, 280
equals, 22, 45, 55
Factory, 103
filter, 22
find, 22
findAnInt, 108, 115
flatMap, 279
fold, 193
foldLeft, 222
foo, 66, 155, 170, 175
force, 220
foreach, 201
functorOps, 283
get, 279
getLines, 294
getTemporaryDirectory, 52
handleMessage, 91
hashCode, 44, 45
hasNext, 203
indexAt2of3, 190
insert, 49
iterator, 203
LeafNode.addDocument

´ToLocalIndex, 249

LeafNode.

executeLocalQuery, 248

lift3, 54, 281
lift3Config, 281
lineLengthCount, 294
link, 243
lookUp, 48
main, 86
makeLineTraversable, 293
MatrixService.multiply,

129

monadOps, 285
NaiveQuickSort.sort, 224
naiveWrap, 265
next, 203
Option, 52
par, 218
parsedConfigFile, 220
peek, 177
receive, 250
receiver, 235
removeDependencies, 166
sendMsgToEach, 172

sliding, 205
sort, 186
Sortable.sort, 227
Sorter.sort, 228
synchronize, 181
testInlineDefinition, 114
testSamePackage, 113
testWildcardImport, 113
toList, 220
traverse, 206
traverseHelper, 206
unwrap, 123
useFile, 123
view, 218
viewAt, 195
wrap, 123

metody

abstrakcyjne, 73
dostpowe, 272
statyczne, 29
wyspecjalizowane, 177
wytwórcze, 52

mnoenie macierzy, 126
modyfikacja zachowania

kolekcji, 218

modyfikator protected, 259
modyfikowalno, 40
monady, 279, 284, 295
monadyczne przepywy, 291,

295

morfizmy, 281
MPI, Message Passing

Interface, 232

nadtyp, 151
nadzorca

SearchNodeSupervisor, 242
wzów wyszukiwawczych,

241

narzdzie

JRebel, 37
maven-scala-plugin, 38
REPL, 35
SBT, 14
Scalariform, 63

nasuchiwanie zdarze, 217
nawias otwierajcy, 63

nawiasy klamrowe, 63, 84
nazwy

klas anonimowych, 268
parametrów, 73
zmiennych, 67

niemodyfikowalno, 40, 44, 50
nieprzekadalne elementy

jzyka, 260

niezmienno, invariance, 156
notacja operatorowa, 25

obiekt, 85

AnnotationHelpers, 273
Average, 69
FileLike, 178
FileWrapper, 122
HashMap, 49
holder, 116
HttpSession, 53
IndexedView, 195
MatrixUtils, 126
NaiveQuickSort, 224
QuickSortBetterTypes, 224
scala.collection.

JavaConversions, 263

scala.Predef, 26
ScalaSecurityImplicits, 122
Sorter, 227
ThreadPoolStrategy, 130
Wildcard, 113

obiekty

funkcyjne, 159
jako parametry, 141
modyfikowalne, 42
niemodyfikowalne, 43
pakietowe, 119, 133
polimorficzne, 59
Scali, 29
towarzyszce, 36, 115, 121,

195

zagniedone, 118

obsuga

aktorów, 235, 244
awarii, 243
bdów, 240
kolekcji, 21, 197, 229

odnajdywanie domniemanej

encji, 137

Kup książkę

Poleć książkę

Skorowidz

301

odraczanie wnioskowania, 225
odzyskiwanie stanu, 244
ogon listy, 188
ograniczanie

bdów, 240
przecie, 244

ograniczenia

importowalnych encji

domniemanych, 133

kontekstu, 170
typu, 151, 170, 175
widoku, 170

okrelanie konwencji

kodowania, 63

opakowywanie typów prostych,

255

operacja

flatten, 284
fold, 191

operacje

funktora, 282
wejcia-wyjcia, 232

operator

#, 142
., 142
/, 122
<-, 278
infiksowy, 26
czenia list, 191
postfiksowy, 26

operatory wiszce, 66, 84
optymalizacja

algorytmów, 226
tableswitch, 79
wywoa ogonowych, 81

pakiet

complexmath, 135
java.security, 121
scala.collection.parallel., 223
scala.collection.script., 218
test, 112

parametr T, 224
parametry

domniemane, 124
domylne, 124, 130
nazwane, 71

przekazywane przez nazw,

279

typu, 153

parowanie kolekcji, 204
parsowanie danych, 36
ptla for, 54, 255
pierwszoklasowe typy

funkcyjne, 21

planista

ExecutorScheduler, 245
ForkJoinScheduler, 245
ResizableThreadPool

´Scheduler, 245

plik

Average.scala, 69, 70
externalbindings.scala, 112

podtyp, 151
pole statyczne, 29, 273
polecenie paste, 37
polimorfizm, 57, 151, 171
porównywanie elementów, 224
prawa monad, 295
predykaty, 22
priorytety wiza, 111
programowanie

funkcyjne, 17, 19, 23, 277
na poziomie typów, 188, 196
obiektowe, 17–19
sterowane eksperymentami,

34, 36

zorientowane wyraeniowo,

projekcja typu, 142
projektowanie architektur

rozproszonych, 240

protokó MPI, 232
przechwytywanie wyjtków, 202
przekazywanie aktorom

referencji, 235

przeksztacanie kolekcji, 222
przeadowywanie, overload, 73,

185

przepywy pracy do-notation,

294

przesanianie, override, 73, 186

metod, 74, 88
parametrów, 111
wiza, 112

przezroczyste referencje

do aktorów, 248

przezroczysto referencyjna,

244

pula wtków, 128
puste implementacje metod, 93,

102

referencje do obiektów, 43
reguy widocznoci, 260
reifikacja, 175
rekurencyjna konstrukcja typów,

193

REPL, Read Eval Print Loop,

33, 38, 57

rozprosz-zgromad,

scatter-gather, 232

rozwijanie

funkcji, 286
metod, currying, 254

równowano

obiektów, 44, 60, 263
polimorficzna, 55

rzutowanie asInstance, 258

scalanie obiektów Option, 54
serializacja, 254, 275

dugoterminowa, 270
Javy, 267, 271
klas anonimowych, 269
obiektu, 47

sesja interpretacyjna, 65
skadanie obiektów, 98
skadnia

() =>, 127
jzyka, 25
typów egzystencjalnych, 165

sowo

entity, 109
sealed, 235

sowo kluczowe

@specialized, 257
_, 26
class, 140
explicit, 62
implicit, 27, 108
import, 110

Kup książkę

Poleć książkę

302

Skorowidz

sowo kluczowe

object, 140
override, 73
trait, 140
type, 143, 144
var, 43
with, 144

sortowanie, 223
sortowanie przez wybieranie,

228

specyfikacja

EJB, 20
Scala, 165

sprawdzanie typów, 80
statyczne

elementy Javy, 29
metody przekazujce, 29

stos, 205
strategia

SameThreadStrategy, 127
ThreadPoolStrategy, 129
ThreadStrategy, 128

strefy

bdu, 240, 243
planowania, 244

strumie, 215

fibs, 215
ObjectInputStream, 268

styl aplikacyjny, 286, 288, 290
symbol wieloznaczny, 113
synchronizacja plików, 179

cieki, 141
miertelny romb, 76
rodowisko, environment, 97
rodowisko REPL, 33

TDD, Test-Driven

Development, 35

teoria kategorii, 278
test

klasy DataAccess, 97
wizania, 112

testowanie równowanoci

referencyjnej, 56

tumaczenie kodu, 20
transformata Fouriera, 67
tworzenie

aktorów, 243, 250
domniemanej konwersji, 258
domniemanej wartoci, 130
migawek, 244
obiektów funkcji

anonimowych, 127

typ, 140

::, 189
<:<, 176
Callback, 155
CollectionConverter, 266
ComplexNumber, 135
Handle, 148, 167
HNil, 188
lewostronny, 165
Nat, 193
Ref, 166
TTrue, 187
Vector, 212
ViewAt, 194

typy

abstrakcyjne, 143
egzystencjalne, 163
kolekcji, 209
lambda, 156
ograniczenia parametrów,

153

ograniczenie dolne, 151
ograniczenie górne, 152
proste i obiekty, 255
strukturalne, 144, 145
uogólnione, 254
wariancja, 156
wyszego rzdu, 155
zagniedone, 118
zalene od cieki, 143, 150
zbiorów, 208
zmiennych, 24
zwracane, 104

usuga

indeksujca, 48
modyfikowalna, 49
niemodyfikowalna, 49

wariancja, 156, 162
wariancja metod, 158
wartoci domniemane, 26, 108,

115

wtek, 127
wczesne definiowanie

skadowych, 88

wczytywanie linii, 293
wze

AdaptiveSearchNode, 250
GathererNode, 238
HeadNode, 239
SearchNode, 233

wizania nieprzesaniane, 114
wizanie, binding, 109, 111
widoczno, 259
widok TraversableView, 221
widoki

domniemane, 119
kolekcji, 219

wnioskowanie

o typie, 24
typu zwracanego, 103

wspóbieno, 48, 128
wstawianie kodu metod, 31
wstrzykiwanie zalenoci, 295
wybór kolekcji, 198
wyjtek

AbstractMethodError, 101
scala.util.control.ControlThr

owable, 202

wymazywanie typów, type

erasure, 163, 186, 254

wymuszanie zmian typu, 162,

180

wyraenia, 38
wyszukiwanie

rozprosz-zgromad, 232, 234,

246

wartoci domniemanych, 115

zagniedanie zakresów, 111
zagniedone typy strukturalne,

145

Kup książkę

Poleć książkę