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
>> >> 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.
>> >>> 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. >> >>> -- >> >>> e...@runne.net >> >>> +46 70 46 16 168
>> >>> -- >> >>> 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-sverige@googlegroups.com. >> >>> Om du vill sluta prenumerera på den här gruppen skickar du e-post till >> >>> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >> . >> >>> För fler alternativ, besök gruppen på >> >>> http://groups.google.com/group/scala-sverige?hl=sv.
>> >> -- >> >> 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-sverige@googlegroups.com. >> >> Om du vill sluta prenumerera på den här gruppen skickar du e-post till >> >> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >> . >> >> För fler alternativ, besök gruppen på >> >> http://groups.google.com/group/scala-sverige?hl=sv.
>> > -- >> > 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-sverige@googlegroups.com. >> > Om du vill sluta prenumerera på den här gruppen skickar du e-post till >> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >> . >> > För fler alternativ, besök gruppen på >> http://groups.google.com/group/scala-sverige?hl=sv.
>> -- >> 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-sverige@googlegroups.com. >> Om du vill sluta prenumerera på den här gruppen skickar du e-post till >> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >> . >> För fler alternativ, besök gruppen på >> http://groups.google.com/group/scala-sverige?hl=sv.
> -- > 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-sverige@googlegroups.com. > Om du vill sluta prenumerera på den här gruppen skickar du e-post till > scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.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
> -- > 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-sverige@googlegroups.com. > Om du vill sluta prenumerera på den här gruppen skickar du e-post till > scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> > . > För fler alternativ, besök gruppen på > http://groups.google.com/group/scala-sverige?hl=sv.
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.
>> >> 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.
>> >>> 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. >> >>> -- >> >>> e...@runne.net >> >>> +46 70 46 16 168
>> >>> -- >> >>> 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-sverige@googlegroups.com. >> >>> Om du vill sluta prenumerera på den här gruppen skickar du e-post till >> >>> scala-sverige+unsubscribe@googlegroups.com. >> >>> För fler alternativ, besök gruppen på >> >>> http://groups.google.com/group/scala-sverige?hl=sv.
>> >> -- >> >> 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-sverige@googlegroups.com. >> >> Om du vill sluta prenumerera på den här gruppen skickar du e-post till >> >> scala-sverige+unsubscribe@googlegroups.com. >> >> För fler alternativ, besök gruppen på >> >> http://groups.google.com/group/scala-sverige?hl=sv.
>> > -- >> > 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-sverige@googlegroups.com. >> > Om du vill sluta prenumerera på den här gruppen skickar du e-post till >> > scala-sverige+unsubscribe@googlegroups.com. >> > För fler alternativ, besök gruppen på >> > http://groups.google.com/group/scala-sverige?hl=sv.
>> -- >> 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-sverige@googlegroups.com. >> Om du vill sluta prenumerera på den här gruppen skickar du e-post till >> scala-sverige+unsubscribe@googlegroups.com. >> För fler alternativ, besök gruppen på >> http://groups.google.com/group/scala-sverige?hl=sv.
> -- > 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-sverige@googlegroups.com. > Om du vill sluta prenumerera på den här gruppen skickar du e-post till > scala-sverige+unsubscribe@googlegroups.com. > För fler alternativ, besök gruppen på > http://groups.google.com/group/scala-sverige?hl=sv.
> 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)
> 2010/6/18 Olle Kullberg <olle.kullb...@gmail.com>: > > 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
> >> Med vänlig hälsning, > >> Christoffer Sawicki
> >> 2010/6/18 Viktor Hedefalk <hedef...@gmail.com>: > >> > Får jag lov att rekommendera den här tråden som en uppvärmning till > >> > den diskussionen:
> >> >> 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.
> >> >>> 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. > >> >>> -- > >> >>> e...@runne.net > >> >>> +46 70 46 16 168
> >> >>> -- > >> >>> 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-sverige@googlegroups.com. > >> >>> Om du vill sluta prenumerera på den här gruppen skickar du e-post > till > >> >>> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> > . > >> >>> För fler alternativ, besök gruppen på > >> >>> http://groups.google.com/group/scala-sverige?hl=sv.
> >> >> -- > >> >> 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-sverige@googlegroups.com. > >> >> Om du vill sluta prenumerera på den här gruppen skickar du e-post > till > >> >> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> > . > >> >> För fler alternativ, besök gruppen på > >> >> http://groups.google.com/group/scala-sverige?hl=sv.
> >> > -- > >> > 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-sverige@googlegroups.com. > >> > Om du vill sluta prenumerera på den här gruppen skickar du e-post till > >> > scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> > . > >> > För fler alternativ, besök gruppen på > >> > http://groups.google.com/group/scala-sverige?hl=sv.
> >> -- > >> 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-sverige@googlegroups.com. > >> Om du vill sluta prenumerera på den här gruppen skickar du e-post till > >> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> > . > >> För fler alternativ, besök gruppen på > >> http://groups.google.com/group/scala-sverige?hl=sv.
> > -- > > 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-sverige@googlegroups.com. > > Om du vill sluta prenumerera på den här gruppen skickar du e-post till > > scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> > . > > För fler alternativ, besök gruppen på > > http://groups.google.com/group/scala-sverige?hl=sv.
> -- > 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-sverige@googlegroups.com. > Om du vill sluta prenumerera på den här gruppen skickar du e-post till > scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.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
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
>> 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)
>> Med vänlig hälsning, >> Christoffer Sawicki
>> 2010/6/18 Olle Kullberg <olle.kullb...@gmail.com>: >> > 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
>> >> Med vänlig hälsning, >> >> Christoffer Sawicki
>> >> 2010/6/18 Viktor Hedefalk <hedef...@gmail.com>: >> >> > Får jag lov att rekommendera den här tråden som en uppvärmning till >> >> > den diskussionen:
>> >> >> 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.
>> >> >>> 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. >> >> >>> -- >> >> >>> e...@runne.net >> >> >>> +46 70 46 16 168
>> >> >>> -- >> >> >>> 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-sverige@googlegroups.com. >> >> >>> Om du vill sluta prenumerera på den här gruppen skickar du e-post >> till >> >> >>> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >> . >> >> >>> För fler alternativ, besök gruppen på >> >> >>> http://groups.google.com/group/scala-sverige?hl=sv.
>> >> >> -- >> >> >> 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-sverige@googlegroups.com. >> >> >> Om du vill sluta prenumerera på den här gruppen skickar du e-post >> till >> >> >> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >> . >> >> >> För fler alternativ, besök gruppen på >> >> >> http://groups.google.com/group/scala-sverige?hl=sv.
>> >> > -- >> >> > 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-sverige@googlegroups.com. >> >> > Om du vill sluta prenumerera på den här gruppen skickar du e-post >> till >> >> > scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >> . >> >> > För fler alternativ, besök gruppen på >> >> > http://groups.google.com/group/scala-sverige?hl=sv.
>> >> -- >> >> 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-sverige@googlegroups.com. >> >> Om du vill sluta prenumerera på den här gruppen skickar du e-post till >> >> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >> . >> >> För fler alternativ, besök gruppen på >> >> http://groups.google.com/group/scala-sverige?hl=sv.
>> > -- >> > 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-sverige@googlegroups.com. >> > Om du vill sluta prenumerera på den här gruppen skickar du e-post till >> > scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >> . >> > För fler alternativ, besök gruppen på >> > http://groups.google.com/group/scala-sverige?hl=sv.
>> -- >> 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-sverige@googlegroups.com. >> Om du vill sluta prenumerera på den här gruppen skickar du e-post till >> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.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
> -- > 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-sverige@googlegroups.com. > Om du vill sluta prenumerera på den här gruppen skickar du e-post till > scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> > . > För fler alternativ, besök gruppen på > http://groups.google.com/group/scala-sverige?hl=sv.
> 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?
>>> 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)
>>> Med vänlig hälsning, >>> Christoffer Sawicki
>>> 2010/6/18 Olle Kullberg <olle.kullb...@gmail.com>: >>> > 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
>>> >> Med vänlig hälsning, >>> >> Christoffer Sawicki
>>> >> 2010/6/18 Viktor Hedefalk <hedef...@gmail.com>: >>> >> > Får jag lov att rekommendera den här tråden som en uppvärmning till >>> >> > den diskussionen:
>>> >> >> 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.
>>> >> >>> 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. >>> >> >>> -- >>> >> >>> e...@runne.net >>> >> >>> +46 70 46 16 168
>>> >> >>> -- >>> >> >>> 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-sverige@googlegroups.com. >>> >> >>> Om du vill sluta prenumerera på den här gruppen skickar du e-post >>> till >>> >> >>> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >>> . >>> >> >>> För fler alternativ, besök gruppen på >>> >> >>> http://groups.google.com/group/scala-sverige?hl=sv.
>>> >> >> -- >>> >> >> 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-sverige@googlegroups.com. >>> >> >> Om du vill sluta prenumerera på den här gruppen skickar du e-post >>> till >>> >> >> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >>> . >>> >> >> För fler alternativ, besök gruppen på >>> >> >> http://groups.google.com/group/scala-sverige?hl=sv.
>>> >> > -- >>> >> > 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-sverige@googlegroups.com. >>> >> > Om du vill sluta prenumerera på den här gruppen skickar du e-post >>> till >>> >> > scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >>> . >>> >> > För fler alternativ, besök gruppen på >>> >> > http://groups.google.com/group/scala-sverige?hl=sv.
>>> >> -- >>> >> 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-sverige@googlegroups.com. >>> >> Om du vill sluta prenumerera på den här gruppen skickar du e-post till >>> >> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >>> . >>> >> För fler alternativ, besök gruppen på >>> >> http://groups.google.com/group/scala-sverige?hl=sv.
>>> > -- >>> > 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-sverige@googlegroups.com. >>> > Om du vill sluta prenumerera på den här gruppen skickar du e-post till >>> > scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >>> . >>> > För fler alternativ, besök gruppen på >>> > http://groups.google.com/group/scala-sverige?hl=sv.
>>> -- >>> 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-sverige@googlegroups.com. >>> Om du vill sluta prenumerera på den här gruppen skickar du e-post till >>> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.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
>> -- >> 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-sverige@googlegroups.com. >> Om du vill sluta prenumerera på den här gruppen skickar du e-post till >> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >> . >> För fler alternativ, besök gruppen på >> http://groups.google.com/group/scala-sverige?hl=sv.
> -- > Det här meddelandet skickas till dig eftersom du prenumererar på gruppen > scala-sverige i Google
"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.
> 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
>> ----------------------------------------------------- >> Joakim Ohlrogge >> Agical AB >> Västerlånggatan 79, 2 tr >> 111 29 Stockholm, SWEDEN
>>>> 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)
>>>> Med vänlig hälsning, >>>> Christoffer Sawicki
>>>> 2010/6/18 Olle Kullberg <olle.kullb...@gmail.com>: >>>> > 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
>>>> >> Med vänlig hälsning, >>>> >> Christoffer Sawicki
>>>> >> 2010/6/18 Viktor Hedefalk <hedef...@gmail.com>: >>>> >> > Får jag lov att rekommendera den här tråden som en uppvärmning till >>>> >> > den diskussionen:
>>>> >> >> 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.
>>>> >> >>> 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. >>>> >> >>> -- >>>> >> >>> e...@runne.net >>>> >> >>> +46 70 46 16 168
>>>> >> >>> -- >>>> >> >>> 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-sverige@googlegroups.com. >>>> >> >>> Om du vill sluta prenumerera på den här gruppen skickar du e-post >>>> till >>>> >> >>> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >>>> . >>>> >> >>> För fler alternativ, besök gruppen på >>>> >> >>> http://groups.google.com/group/scala-sverige?hl=sv.
>>>> >> >> -- >>>> >> >> 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-sverige@googlegroups.com. >>>> >> >> Om du vill sluta prenumerera på den här gruppen skickar du e-post >>>> till >>>> >> >> scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >>>> . >>>> >> >> För fler alternativ, besök gruppen på >>>> >> >> http://groups.google.com/group/scala-sverige?hl=sv.
>>>> >> > -- >>>> >> > 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-sverige@googlegroups.com. >>>> >> > Om du vill sluta prenumerera på den här gruppen skickar du e-post >>>> till >>>> >> > scala-sverige+unsubscribe@googlegroups.com<scala-sverige%2Bunsubscribe@goog legroups.com> >>>> . >>>> >> > För fler alternativ, besök gruppen på >>>> >> > http://groups.google.com/group/scala-sverige?hl=sv.
>>>> >> -- >>>> >> Det här meddelandet skickas till dig eftersom du prenumererar på >>>> gruppen >>>> >> scala-sverige i Google Groups. >>>> >> Om du vill göra ett
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
> "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.
>> 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
>>> ----------------------------------------------------- >>> Joakim Ohlrogge >>> Agical AB >>> Västerlånggatan 79, 2 tr >>> 111 29 Stockholm, SWEDEN
>>>>> 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)
>>>>> Med vänlig hälsning, >>>>> Christoffer Sawicki
>>>>> 2010/6/18 Olle Kullberg <olle.kullb...@gmail.com>: >>>>> > 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
