Scalaträff i Stockholm 8/9 fulltecknad

[Enno Runne]

Hej Scala Sverige,

Då har jag räknad 17 anmälda till träffen. Lokalen är inte särskilt stor så jag anser mötet fulltecknat.

Sedan har vi förstås en solig och badvänlig sommar emellan så jag gissar att inte alla kan när det väl är dags.

Förutom Mats Henricson har ingen anmäld intresse att tala, jag hoppas att någon mer har erfarenheter som kan presenteras. I värsta fall få ni stå ut med lite halvsanningar jag kan hitta på. - kom hellre med egna förslag!

Glad sommar,

Enno.

PS: Håll utkik efter Scala artikeln i morgondagens Computer Sweden.

--
en...@runne.net
+46 70 46 16 168

[Viktor Klang]

Hej,

som halvdansk (skåning) så är jag ledsen att inte kunna närvara.
Men jag önskar alla en väldigt trevlig träff!

2010/6/17 Enno Runne <en...@runne.net>

--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

[Patrik Nordwall]

Jag ställer mig på reservlistan.

/Patrik

--

[Joakim Ohlrogge]

Jag tror att jag tills dess känner mig bekväm att prata lite om SBT (Simple Build Tool) en trevligare och trevligare bekantskap. Jan ställa den i relation till buildr, maven och ant som jag använt en del.

Men alla kanske redan kan SBT?

/J


-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
E-mail: joakim....@agical.se

2010/6/17 Enno Runne <en...@runne.net>

--

[Per Engström]

Hej!

Jag tar rygg på Patrik och ställer mig också på reservlistan.

/Per

[Olle Kullberg]

Hej

Det finns en fråga som jag skulle vilja ta upp på mötet:  Jag är lite nyfiken på hur ni ser på case-klassernas svaga inkapsling, och vidare diskutera om inkapsling är ett hinder för en fusion mellan OOP och FP. Tar kanske 5 min.

/mvh Olle

2010/6/17 Enno Runne <en...@runne.net>

--

[Mats Henricson]

Jätteintressant!

Mats

On Jun 17, 2010 9:35 PM, "Olle Kullberg" <olle.k...@gmail.com> wrote:

Hej

Det finns en fråga som jag skulle vilja ta upp på mötet:  Jag är lite nyfiken på hur ni ser på case-klassernas svaga inkapsling, och vidare diskutera om inkapsling är ett hinder för en fusion mellan OOP och FP. Tar kanske 5 min.

/mvh Olle

2010/6/17 Enno Runne <en...@runne.net>

>
> Hej Scala Sverige,
>
> Då har jag räknad 17 anmälda till träffen. Lokalen är inte särskilt stor...

--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Googl...

[Viktor Hedefalk]

Jag tycker det låter som en jättekul idé! Jag är faktiskt väldigt intresserad av att få se lite mer av sbt eftersom jag hört så mycket positivt men dock inte hunnit testa ordentligt själv.

Vore väldigt kul att tex kanske se en konvertering av ett maven-projekt och jag hör gärna på om nån har nåt att säga om IDE-stödet, sbt-eclipsify tex.

   

/Viktor

[Viktor Hedefalk]

Får jag lov att rekommendera den här tråden som en uppvärmning till
den diskussionen:

http://www.artima.com/forums/flat.jsp?forum=106&thread=166742

Med vänlig hälsning
/Viktor

2010/6/17 Olle Kullberg <olle.k...@gmail.com>:

[Hans Brattberg]

Hej alla!

En fråga jag skulle vilja ha ett enkelt och glasklart svar på :o) är:
Näe ska man använda OO och när ska man använda FP?
Framförallt i samband med DDD.

/Hasse

2010/6/18 Viktor Hedefalk <hede...@gmail.com>:

--
Hans Brattberg
hans.br...@crisp.se
www.crisp.se/hans.brattberg
+46 (0)70 575 31 32

[Peter Lewerin]

Enno Runne skrev:
>
> PS: H�ll utkik efter Scala artikeln i morgondagens Computer Sweden.

"Inom programmering syftar ordet funktionellt p� spr�k i vilka kod
tolkas p� samma s�tt som matematiska begrepp. Funktionella spr�k
underl�ttar hantering av flera tr�dar i program."

"Scala �r dynamiskt typat [...]"

Hmm.

[Jonas Bonér]

2010/6/18 Peter Lewerin <peter....@swipnet.se>

Enno Runne skrev:

PS: Håll utkik efter Scala artikeln i morgondagens Computer Sweden.

"Inom programmering syftar ordet funktionellt på språk i vilka kod tolkas på samma sätt som matematiska begrepp.  Funktionella språk underlättar hantering av flera trådar i program."

"Scala är dynamiskt typat [...]"

Hmm.

Har inte last artikeln men detta har jag verkligen inte sagt under intervjun. FP hjalper i concurrency, ja det har jag sagt. Men det andra ar ju rappakalja. 

 

--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.

--
Jonas Bonér

work:   http://jayway.com
code:   http://akkasource.com
blog:    http://jonasboner.com
twitter: @jboner

[Jonas Bonér]

Var ar artikeln? 

Vet inte hur manga ggr jag sa att scala ar statiskt typat och det ar darfor jag kan anv det till det jag gor. 

2010/6/18 Jonas Bonér <jbo...@gmail.com>

[Peter Lewerin]

Jonas Bon�r skrev:

>
> "Inom programmering syftar ordet funktionellt p� spr�k i vilka kod
> tolkas p� samma s�tt som matematiska begrepp. Funktionella spr�k
> underl�ttar hantering av flera tr�dar i program."
>

> "Scala �r dynamiskt typat [...]"

>
> Hmm.
>
>
> Har inte last artikeln men detta har jag verkligen inte sagt under
> intervjun. FP hjalper i concurrency, ja det har jag sagt. Men det
> andra ar ju rappakalja.

Inget av detta st�r som citat av dig, utan i journalistens egen text.

Jag tyckte att det var mycket sagt att p�st� att funktionell kod tolkas
"p� samma s�tt som matematiska begrepp", men det kanske �r h�rklyverier.

[Viktor Hedefalk]

Det gör ont, det gör ont...

Tycker iofs att beskrivningen av FP är rätt okej? Även om beskrivning
förutsätter "ren" FP. Matematisk funktion som i referensiell
transparens alltså? Vilket såklart inte är enforcat av Scala, men
ändå.

/Viktor

2010/6/18 Peter Lewerin <peter....@swipnet.se>:
> Enno Runne skrev:
>>
>> PS: Håll utkik efter Scala artikeln i morgondagens Computer Sweden.
>
> "Inom programmering syftar ordet funktionellt på språk i vilka kod tolkas på
> samma sätt som matematiska begrepp.  Funktionella språk underlättar
> hantering av flera trådar i program."
>
> "Scala är dynamiskt typat [...]"
>
> Hmm.
>

[Viktor Hedefalk]

Jonas, den tycks bara finnas i pappersversionen, hittar den inte heller online.

Jag tror inte du behöver vara orolig att nån ska tro att du har sagt
att Scala är ett dynamiskt typat språk ;) Computer Sweden är bara vår
allas älskade Hänt i veckan-tabloid. Det är jämt sådär.

/Viktor

2010/6/18 Jonas Bonér <jbo...@gmail.com>:

[Peter Lewerin]

Viktor Hedefalk skrev:
> Det g�r ont, det g�r ont...
>
> Tycker iofs att beskrivningen av FP �r r�tt okej? �ven om beskrivning
> f�ruts�tter "ren" FP. Matematisk funktion som i referensiell
> transparens allts�? Vilket s�klart inte �r enforcat av Scala, men
> �nd�.
>
Tidningens f�rklaring blir vettig om man vet vad FP �r, men om man inte
vet det �r den alldeles f�r vag (vad betyder det att "[koden] tolkas p�
samma s�tt som matematiska begrepp"?), alldeles f�r generell (�ven
imperativa spr�k kan isf s�gas tolkas p� samma s�tt som matematiska
begrepp) och alldeles f�r stark (FP-funktioner *�r* inte matematiska
funktioner, lika lite som OOP-objekt �r verkliga objekt).

Jag skulle nog beh�va fundera en stund f�r att f� ihop en kort faktaruta
som f�rklarar FP p� ett bra s�tt, men CS lyckades hsh inte s� bra.

[Jonas Bonér]

Viktigast for mig i FP ar: 

* state changes are local to the computation

* referential transparency, e.g. code that doesn't lie

2010/6/18 Peter Lewerin <peter....@swipnet.se>

Viktor Hedefalk skrev:

Det gör ont, det gör ont...

Tycker iofs att beskrivningen av FP är rätt okej? Även om beskrivning
förutsätter "ren" FP. Matematisk funktion som i referensiell
transparens alltså? Vilket såklart inte är enforcat av Scala, men
ändå.
 

Tidningens förklaring blir vettig om man vet vad FP är, men om man inte vet det är den alldeles för vag (vad betyder det att "[koden] tolkas på samma sätt som matematiska begrepp"?), alldeles för generell (även imperativa språk kan isf sägas tolkas på samma sätt som matematiska begrepp) och alldeles för stark (FP-funktioner *är* inte matematiska funktioner, lika lite som OOP-objekt är verkliga objekt).

Jag skulle nog behöva fundera en stund för att få ihop en kort faktaruta som förklarar FP på ett bra sätt, men CS lyckades hsh inte så bra.

--

Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.

[Jonas Bonér]

2010/6/18 Viktor Hedefalk <hede...@gmail.com>

Jonas, den tycks bara finnas i pappersversionen, hittar den inte heller online.

Jag tror inte du behöver vara orolig att nån ska tro att du har sagt
att Scala är ett dynamiskt typat språk ;) Computer Sweden är bara vår
allas älskade Hänt i veckan-tabloid. Det är jämt sådär.

Jovisst. Tack. 

[Viktor Hedefalk]

Men man får inte ha så stora förväntningar på CS ;)

Jag tycker dock att liknelsen med matematiska funktioner kan vara
ganska kraftfull för att förklara "ren" FP. När jag hjälpt studenter
med SML på Uppsala universitet fann jag att den verkligen hjälpte
framförallt studenter som redan sysslat en del med imperativ
programmering att förstå skillnaden och poängen med referentiell
transparens: http://en.wikipedia.org/wiki/Referential_transparency_%28computer_science%29

Jag kunde bara säga "tänk matematisk funktion, glöm din C"
tillräckligt många gånger och till slut kom det ett "AHA!!". Ofta kom
det ganska direkt en våg av insikter om sen evaluering osv. och de som
kunde nåt om trådar förstod ofta direkt hur referential transparancy
gjorde det mycket enklare att tråda beräkningar. Jag tror det är lite
så med FP, man fattar ingenting skitlänge och sen får man en
aha-upplevelse och allt blir glasklart.

Jag menar inte att faktarutan på CS-artikeln är perfekt dock ;)

/Viktor

2010/6/18 Peter Lewerin <peter....@swipnet.se>:
> Viktor Hedefalk skrev:

>>
>> Det gör ont, det gör ont...
>>
>> Tycker iofs att beskrivningen av FP är rätt okej? Även om beskrivning
>> förutsätter "ren" FP. Matematisk funktion som i referensiell
>> transparens alltså? Vilket såklart inte är enforcat av Scala, men
>> ändå.
>>
>

> Tidningens förklaring blir vettig om man vet vad FP är, men om man inte vet
> det är den alldeles för vag (vad betyder det att "[koden] tolkas på samma

> sätt som matematiska begrepp"?), alldeles för generell (även imperativa

> språk kan isf sägas tolkas på samma sätt som matematiska begrepp) och
> alldeles för stark (FP-funktioner *är* inte matematiska funktioner, lika

> lite som OOP-objekt är verkliga objekt).
>

> Jag skulle nog behöva fundera en stund för att få ihop en kort faktaruta som
> förklarar FP på ett bra sätt, men CS lyckades hsh inte så bra.

[Mikael Sundberg]

http://cstjanster.idg.se/losnummer/?pid=23334&date=2010-6

man kan köpa pdf om man tycker det är roligt. Det är nog enda sättet att läsa den online.

/Micke

[Jonas Bonér]

2010/6/18 Mikael Sundberg <mikael.s...@gmail.com>

http://cstjanster.idg.se/losnummer/?pid=23334&date=2010-6

man kan köpa pdf om man tycker det är roligt. Det är nog enda sättet att läsa den online.

Tack. 

--

[Peter Lundberg]

Jag ställer mig också på reservlistan.
Jag skulle eventuellt kunna visa lite kort om t.ex. play framework + scala.

/P

2010/6/17 Per Engström <per...@gmail.com>

[Christoffer Sawicki]

Jag rekommenderar även det här examensarbetet av Burak Emir (som
Odersky var handledare för):

Object-oriented pattern matching
http://biblion.epfl.ch/EPFL/theses/2007/3899/EPFL_TH3899.pdf

Med vänlig hälsning,
Christoffer Sawicki

2010/6/18 Viktor Hedefalk <hede...@gmail.com>:

[Olle Kullberg]

Kollade på den, men det verkar inte som Burak använder nyckelordet private alls där. Jag tänker mig följande:

scala> case class Person(private val name: String)
defined class Person

scala> val o= Person("olle")                     
o: Person = Person(olle)

scala> o.name
<console>:8: error: value name cannot be accessed in Person
       o.name
         ^

scala> o match { case Person(n) => println("found: "+ n)
     | case _ => println("other") }
found: olle

/mvh Olle

2010/6/18 Christoffer Sawicki <christoff...@gmail.com>

[Viktor Klang]

Om jag inte minns fel så är vals i Scala backade av ett private field och en getter-metod som du kan ändra visibility på,
så du har samma inkapsling som Java

2010/6/18 Olle Kullberg <olle.k...@gmail.com>

--

[Peter Lewerin]

Viktor Hedefalk skrev:

> Jag tycker dock att liknelsen med matematiska funktioner kan vara

> ganska kraftfull f�r att f�rklara "ren" FP.

Visst �r den, det �r bara jag som �r �verdrivet petig. D�rmed inte sagt
att jag har fel, f�r det har jag inte :)

Det �r ocks� intressant att notera att m�nga FP-k�nnare �r tydliga med
att p�peka att Scala *inte* �r FP, fast det h�r v�l iofs n�stan till
genren.

[Jörgen Lundberg]

2010/6/18 Mikael Sundberg <mikael.s...@gmail.com>:

> http://cstjanster.idg.se/losnummer/?pid=23334&date=2010-6
> man kan köpa pdf om man tycker det är roligt. Det är nog enda sättet att
> läsa den online.
> /Micke

Här är den online:
http://computersweden.idg.se/2.2683/1.328072

/Jörgen

[Jonas Bonér]

2010/6/18 Jörgen Lundberg <jorgen....@gmail.com>

Ok. Tack. Av mer an 30 min intervju blev det tva meningar citat. Hmm.  

/Jörgen

--

Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.

--

[Christoffer Sawicki]

Såhär här har jag förstått det:

Om du vill gömma konstruktorargumenten så bör du inte heller använda
`case class`:er. Det stämmer att de saknar inkapsling, men det är inte
alltid man behöver det. Som Burak skriver så är de bara syntaktiskt
socker och vill du gömma något argument men ändå mönstermatcha så kan
du implementera din egen `unapply`. Exempel:

class Person(private val name: String, val age: Int)
object Person { def unapply(p: Person) = Some(p.age) }

scala> val o = new Person("olle", 123)
o: Person = Person@7e5284e9

scala> o match { case Person(n) if n > 18 => true; case _ => false }
res0: Boolean = true

Detta sagt, det känns lite konstigt att `private val` godkänns med
`case class` av kompilatorn.

Med vänlig hälsning,
Christoffer Sawicki

2010/6/18 Olle Kullberg <olle.k...@gmail.com>:

[Viktor Klang]

2010/6/18 Christoffer Sawicki <christoff...@gmail.com>

Såhär här har jag förstått det:

Om du vill gömma konstruktorargumenten så bör du inte heller använda
`case class`:er. Det stämmer att de saknar inkapsling, men det är inte
alltid man behöver det. Som Burak skriver så är de bara syntaktiskt
socker och vill du gömma något argument men ändå mönstermatcha så kan
du implementera din egen `unapply`. Exempel:

class Person(private val name: String, val age: Int)
object Person { def unapply(p: Person) = Some(p.age) }

scala> val o = new Person("olle", 123)
o: Person = Person@7e5284e9

scala> o match { case Person(n) if n > 18 => true; case _ => false }
res0: Boolean = true

Detta sagt, det känns lite konstigt att `private val` godkänns med
`case class` av kompilatorn.

Du kan även ha curried primary constructor:

case class Foo(age : Int)(awesomenessFactor : BigInt)
 

--

[Joakim Ohlrogge]

Jag brukade tycka att inkapsling var superviktigt, jag tycker inte att det är lika viktigt längre. Jag tror att en anledning är att immutabilitet löser en del problem jag tidigare använde inkapsling för att lösa. Jag tror att en annan anledning är att jag tenderar att skriva kortare klasser nu (men fler) och där varje klass har en mycket större andel publikt API än vad mina äldre, större klasser hade. Jag tror att jag segmenterar koden på en annan ledd nu.

Har inte inkapsling fått lite orättvist mycket fokus i OO? (Jag säger inte att det är meningslöst och dåligt bara att det kanske fått mer uppmärksamhet än det förtjänar, kanske främst för att c++, java och c# kräver att man deklarerar och döljer sina fält).

När jag kodar i scala skriver jag ganska sällan private. Antagligen för att man får inkapslade fält på köpet och för att det faller sig så naturligt att hålla mängden mutabilitet nere och för att det är så väldigt enkelt att bryta upp sina klasser i flera i scala.

Någon annan som börjat slappna av lite med inkapslingen eller tycker listan att jag borde gå hem och smiska upp mig själv tills jag kommer upp på banan igen?

-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
E-mail: joakim....@agical.se

2010/6/18 Viktor Klang <viktor...@gmail.com>

[Viktor Klang]

2010/6/18 Joakim Ohlrogge <joakim....@gmail.com>

Jag brukade tycka att inkapsling var superviktigt, jag tycker inte att det är lika viktigt längre. Jag tror att en anledning är att immutabilitet löser en del problem jag tidigare använde inkapsling för att lösa. Jag tror att en annan anledning är att jag tenderar att skriva kortare klasser nu (men fler) och där varje klass har en mycket större andel publikt API än vad mina äldre, större klasser hade. Jag tror att jag segmenterar koden på en annan ledd nu.

Framförallt så gör ju möjligheten att skriva metod-definitioner inuti metoder att man faktiskt kan undvika private-metoder i många fall.
 

Har inte inkapsling fått lite orättvist mycket fokus i OO? (Jag säger inte att det är meningslöst och dåligt bara att det kanske fått mer uppmärksamhet än det förtjänar, kanske främst för att c++, java och c# kräver att man deklarerar och döljer sina fält).

Jag tror inte att man ska ha ett korståg för inkapsling utan att vara lite pragmatisk och faktiskt applicera de tekniker som finns där de gör som mest nytta.
 

När jag kodar i scala skriver jag ganska sällan private. Antagligen för att man får inkapslade fält på köpet och för att det faller sig så naturligt att hålla mängden mutabilitet nere och för att det är så väldigt enkelt att bryta upp sina klasser i flera i scala.

Absolut, möjligheten att med en liten rad kod skapa en case-class skapar ju incitament att faktiskt bryta upp sina klasser bättre.
 

Någon annan som börjat slappna av lite med inkapslingen eller tycker listan att jag borde gå hem och smiska upp mig själv tills jag kommer upp på banan igen?

+1

[Olle Kullberg]

Hej Joakim, du skrev:

"Jag brukade tycka att inkapsling var superviktigt"

Intressant (vi släpper case-klasserna för stunden). Jag tillhör nog fortfarande det gamla gardet där inkapsling fortfarande är numero uno. Min syn på inkapsling har egentligen inte ändrats sedan C-tiden, där alla publika funktioner deklarerades i header-filen, övriga blev privata. Jag brukar tänka mig att i större system så bidrar inkapsling till att minska den mentala belastningen på oss kodare. Vi har t.ex. en typisk klass med 20 metoder, varav bara 3 av dessa anropas utifrån. Vi har då två fall:

1) Alla 20 metoderna är publika.
2) Bara 3 metoder är publika, de som faktiskt anropas utifrån.

Alternativ 1) innebär att när du läser klassen så måste du tänka dig att alla dessa metoder potentiellt kan anropas utifrån, något som kan vara förvirrande. Alternativ 2) brukar göra det lättare för mig att refaktorisera de 17 privata metoderna, eftersom jag vet att de bara används internt. I ett statiskt typat språk som Scala är det oftast inte så svårt att kolla vilka klasser som har beroende till en metod, men det medför ändå märkbar mental belasting IMO.

För att närma sig dynamiska språk har Scala släppt på inkapsling genom att göra default-synligheten till publik. Precis som du säger leder detta till att man oftare väljer publik synlighet än tidigare. Mindre och fler klasser är en enorm fördel med Scala, men har egentligen inget med inkapsling att göra (om inte private används i dessa klasser d.v.s.)

Som Scalafanatiker och inkapslingsdiggare ligger mitt hopp nu alltså till Actors (och Akka). Jag drömmer om en inkapsling lika obeveklig som den som går att finna i Erlang:

"An Erlang system can be thought of as a communicating network of black boxes."

(märk att inkapsling inte används inuti dessa svarta lådor (=aktörer), bara mellan dem).

Hur som helst är det en spännande värld vi lever i... vi får se hur detta utvecklar sig.

/mvh Olle

[Joakim Ohlrogge]

Inkapsling är inte struket från min lista men det är inte numero uno längre. Fler och mindre klasser är som du säger inte inkapsling, det är mera... segmentering. Segmentering är också ett sätt att förenkla användningen av ditt system. Ditt publika api med 3 metoder på klass a delegerar i sin till instanserna B och C som i sin tur har X publika metoder och kanske i sin tur delegerar till ytterligare instanser. Här vägleder man användaren genom att organisera sin kod så att det är tydligt vad som hör ihop och vilka naturliga ingångar som finns tex genom paket osv.

Jag tror också att det kan vara mycket mer intressant att "gömma undan" funktionalitet som privat om man skriver ett API som används av många som du inte har snabb och enkel dialog med. Då kan du vilja försäkra dig om att ditt system används på rätt sätt med mer än bara konvension. Det kan dock bli lite tröttsamt att använda API:er som är allt för strikta i de avseendena... det är en svår balans.

Viktors synpunkt om anonyma funktioner är också intressant, kanske far mycket sådant som tidigare var privat in i ett pussel av funktioner som kan kombineras ihop till funktionalitet bakom en eller flera olika publika facader? Inkapsingen kanske inte har försvunnit, den har tagit en annan form.

Erlang-exemplet är väldigt intressant för det är väl egentligen essensen av OO, meddelande som skickas mellan "aktörer" trots att det ser så underligt ut mot vad vi är vana vid. Ur den aspekten så tycker jag också att inkapsling är intressant att kunna garantera att ingen annan pillar på "mitt" state. Mycket av den problematiken kan man ju även angripa med immutable objekt och pure functions. I erlang så snurrar ju statet så att säga runt mellan aktörerna i form av meddelanden (om jag nu inte är helt ute och snurrar, jag ska erkänna att jag mest läst om Erlang och inte så mycket).

Kanske är det så att jag tar mer inkapsling för given nu och därmed inte tror att jag bryr mig i lika stor utsträckning?

Ibland känner jag det som att scala ger dig mycket valfrihet i hur du vill skriva ditt system men att man ofta väljer om man vill vara mer funktionell eller mer objektorienterad och att det speglar större delar av systemet. Jag upplever att bra OO ofta är "all tell" och bra FP ofta är "all ask" och att det när man binder ihop dem kan bli lite... onaturligt att vända håll. Man kan vara ganska all tell och OO mellan actors och ganska all ask och FP inom actors men inte alltid att OO och FP möts så väl på samma plan? Kanske är det beroende på vilket stilval man har gjort hur illa det känns att bända bända ut värdena ur en case klass? På sätt och vis så är det ju lite det de är till för, att kunna plocka det man vill ha ur dem med pattern-matching, använder man sina case-klasser så så kanske de tenderar att vara lite simplare databärare med mindre "betende" än vad som skulle kännas mer "riktig" OO, Man vänder liksom ut och in på objekten. Det är en av de sakerna som jag debatterar med mig själv nu och då. För tillfället föredrar jag att hålla case-klasserna enkla, gärna oneliners, mer som structar i syfte att matcha på dem. Entiteter i DDD termer?

Hur använder ni andra case klasser? Är det kanske så att de är för öppna för vissa stilar men funkar bra med andra?

-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
E-mail: joakim....@agical.se

2010/6/18 Olle Kullberg <olle.k...@gmail.com>