Tråden för oss som programmerar eller sysslar med IT

[Trance]

Då det finns en del som programmerar eller jobbar med andra relaterade saker så tänkte jag att man kan ha en tråd där man avhandlar viktiga saker så som editorer och vilken pappa som är starkast.

Man kan även använda tråden för att snika sig till läxhjälp om man gömmer det snyggt nog så inte Allan nosar upp det.

Ursprungligen postat av mikaelj

1. Du använder ett externt bibliotek som har en generisk funktion HIT-DRUM som tar emot två objekt, ett har typen STICK och den andra har typen DRUM:

(defgeneric hit-drum (stick drum)
  (:documentation "Hit drum with stick and return the sound generated."))

Du har inte källkoden till det externa biblioteket och/eller vill/kan inte ändra på biblioteket av en annan anledning. Biblioteket använder HIT-DRUM för att generera ljud. Notera att HIT-DRUM (och tillhörande kod) inte känner till din special-trumstock och special-trumma. Hur gör du för att biblioteket skall använda din JWZRD-STICK och JWZRD-SKULL-DRUM, i Java?

Ha en metod i klassen Stick som heter .hit(Drum drum)? Eller skall du ha Drum.hit(Stick stick)? Eller en mediatorklass, DrumHitter som har som enda metod en hit(Stick, Drum)? Vad händer då med din kod?

Förhoppningsvis så är biblioteket implementerat så den tar interfaces istället för konkreta implementationer. Så problemet dyker inte upp så ofta i praktiken. Om jag nu inte misslyckats med att förstå dig fullständigt.

public void HitDrum(IDrum drum, IStick stick)

IDrum drum = new JwzrdDrum(); osv.

Ursprungligen postat av mikaelj

Går alltså att lösa, men inte på något snyggt sätt.

Följande är svårare.

Ta den generiska funktionen PRINT-OBJECT som tar emot en stream och ett objekt, (defgeneric print-object (object stream)). Den anropas av FORMAT m.fl. funktioner som skall göra om ett objekt till ett utskriftbart format, anpassat till en särskild stream, t.ex. *standard-output*, din egna fil-ström, eller någon helt annan utdata-ström.

Antag att .toString() inte fanns i Java. Hur lägger du till utskrift-funktionalitet för din och alla andras kod? (det finns fler riktiga exempel, kommer inte på något direkt just nu)

[mikaelj]

Bra initiativ!

Ursprungligen postat av Trance

Förhoppningsvis så är biblioteket implementerat så den tar interfaces istället för konkreta implementationer. Så problemet dyker inte upp så ofta i praktiken. Om jag nu inte misslyckats med att förstå dig fullständigt.

public void HitDrum(IDrum drum, IStick stick)

IDrum drum = new JwzrdDrum(); osv.

Japp. I single dispatch har du en implicit specialisering på första argument, dvs (den osynliga) this-parametern. Med multiple dispatch kan du specialisera på vilken/vilka parameter som helst.

Och för att lösa problemet i Java har vi helt plötsligt kommit bort från att metoder tillhör klasser, eller hur? Det är en del av problemet multiple dispatch löser. Klasser är data, metoder är metoder.

För ganska exakt ett år sedan skrev jag en snutt på Extension Methods: Greenspunning Generic Functions | Mikael Jansson om hur moderna språk nästan kommit ikapp med CLOS.

[tossefar]

aa tja, jag gillar kod och tjejer och mat.

[shut teh face]

select * from tab;

[Trance]

Jag har inte riktigt bestämt mig hur jag ställer mig till Extension methods än. Visst kan de vara smidiga, t.ex. System.Linq som lägger till massa metoder till allt som implementerar IEnumerable<T>.

Men samtidigt så är det trots allt bara syntactic sugar (kolhydrater!) för statiska metoder som man brukar lägga i hjälpklasser. Statiska metoder är något jag vill minimera maximalt vanligtvis då det uppmuntrar folk till att göra dumma saker. I verkliga livet när man programmerar Java/C# så får man barnsäkra koden fullt ut ;-)

Common Lisp och Python verkar även ha en lite mer pragmatisk inställning till objektorientering (använd det där de anser det fungerar) medan modet i C#/Java, mycket på grund av hur språken är designade, är att man kör så mycket som möjligt och bara sprutar ut sig klasser.

[jwzrd]

Ursprungligen postat av mikaelj

Bra initiativ!



Japp. I single dispatch har du en implicit specialisering på första argument, dvs (den osynliga) this-parametern. Med multiple dispatch kan du specialisera på vilken/vilka parameter som helst.

Och för att lösa problemet i Java har vi helt plötsligt kommit bort från att metoder tillhör klasser, eller hur? Det är en del av problemet multiple dispatch löser. Klasser är data, metoder är metoder.

För ganska exakt ett år sedan skrev jag en snutt på Extension Methods: Greenspunning Generic Functions | Mikael Jansson om hur moderna språk nästan kommit ikapp med CLOS.

Men alltså vad är då felet med att det finns en DrumHitter som accepterar två argument Drum och Stick? Jag tycker fortfarande att multidispatch är en efteretikett på en feature som egentligen inte är en sådan utan ett sätt att jämföra äpplen med päron och säga att en feature hos päronet är att det inte är format som äpplet.

[jwzrd]

I ditt utskriftsexempel skulle jag i Scala använt mig av match/case och helt enkelt mönstermatchat+dekompositerat (helvete så konstigt det blir på svenska) i en metod. Typ:

def toString[A](x:A):String = match {
case Flibble(foo:Foo, bar:Bar) => "foo: " + toString(foo) + "; bar: " + bar
case ...
}

[jwzrd]

Jag ska lägga till att jag inser att det är två olika features och att det alltså finns en skillnad.

[mikaelj]

Ursprungligen postat av jwzrd

Men alltså vad är då felet med att det finns en DrumHitter som accepterar två argument Drum och Stick? Jag tycker fortfarande att multidispatch är en efteretikett på en feature som egentligen inte är en sådan utan ett sätt att jämföra äpplen med päron och säga att en feature hos päronet är att det inte är format som äpplet.

Inget fel att ha en drumhitter-metod. Ganska perfekt, rentav. Men att vara tvungen att ha en klass DrumHitter är redigt fel -- enda anledningen är just att du måste ha ansvar för specifika klasser någonstans. Och om det är delat på två eller fler klasser, vad gör du då? Skapar proxy-klass eller global funktion.

Ursprungligen postat av jwzrd

I ditt utskriftsexempel skulle jag i Scala använt mig av match/case och helt enkelt mönstermatchat+dekompositerat (helvete så konstigt det blir på svenska) i en metod. Typ:

def toString[A](x:A):String = match {
case Flibble(foo:Foo, bar:Bar) => "foo: " + toString(foo) + "; bar: " + bar
case ...
}

Jag är inte riktigt säker på vad det där gör, men det ser ut som att du i din toString() måste ha ett fall för varje funktion som använder toString. Stämmer det? Hur gör du, i så fall, för att implementera en metod på toString för din egendefinierade datatyp i framtiden utan att gå tillbaka och ändra definitionen?

----

I övrigt om multimetoder, se http://www.usenet.com/newsgroups/com.../msg00009.html för hur C++ inte klarar av multiple dispatch ("D'oh"-kommentaren), samt artikeln Multiple Dispatch in Practice (bra beskrivningar i den senare med specifika kodexempel i olika språk).

[The_RobRoy]

Har fått en kodar-guru på min grupp på jobbet. Han menar att Python är himmelriket som kodar-språk här på företaget.

Tidigare har det mesta lösts med Queries, Macron och VBA-kod i MS Access snurror.

Har han rätt eller borde vi köra något annat?

[jwzrd]

Ursprungligen postat av mikaelj

Jag är inte riktigt säker på vad det där gör, men det ser ut som att du i din toString() måste ha ett fall för varje funktion som använder toString. Stämmer det? Hur gör du, i så fall, för att implementera en metod på toString för din egendefinierade datatyp i framtiden utan att gå tillbaka och ändra definitionen?

----

I övrigt om multimetoder, se http://www.usenet.com/newsgroups/com.../msg00009.html för hur C++ inte klarar av multiple dispatch ("D'oh"-kommentaren), samt artikeln Multiple Dispatch in Practice (bra beskrivningar i den senare med specifika kodexempel i olika språk).

Jo jag förstår skillnaden och att det inte går enligt de förutsättningar du ger mig. Jag hade löst ett problem av den typen med hjälp av <Blah>Handler-interface och jag hade haft en <Blah>HandlerMapper som är konfigurerbar. Det är the enterprise kludge/bloat/java-way typ.

Och ja, du förstår toString-metoden jag visade rätt. Men för att bli mer verklighetsanknytna så löser faktiskt en helt vanlig statisk metod apply(Drum, Stick) på DrumHitter ditt problem. <Vad som helst> är faktiskt inte en trumma och det är heller inte en Stick. Jag vet att du givit ett exempel för att visa på hur multidispatch fungerar, men hur tänkte du dig att fem olika metoder hitDrum skulle se ut? Fem helt väsensskilda processer som alla ändå är samma sak men som ändå inte kan implementeras på annat vis med mer gemensamma typer?

apply()-metoden kan överlagras i olika implementationer av en AbstractDrumHitter där du alltså får en subtyp per multi-metod.

Om din genersiska funktion alltså har en hit(ElectronicDrumKit Spatula) och en hit(KitchenSink SoupLadel) som ju blir fallet - du får skriva en metod per fall, så kan jag ha en: ElectronicDrumKitSpatulaHitter och en KitchenSinkSoupLadelHitter implementation av AbstractLittleDrummerBoy<T, U> (där T är trumtypen; U pinntypen) men "problemet" för mig blir att först delegera anropet rätt.

[Trance]

Ursprungligen postat av The_RobRoy

Har fått en kodar-guru på min grupp på jobbet. Han menar att Python är himmelriket som kodar-språk här på företaget.

Tidigare har det mesta lösts med Queries, Macron och VBA-kod i MS Access snurror.

Har han rätt eller borde vi köra något annat?

Det beror väl vad man har tänkt att göra (som alltid) men han har helt klart rätt i att Python är väldigt sexigt.

[jwzrd]

Ursprungligen postat av Trance

Det beror väl vad man har tänkt att göra (som alltid) men han har helt klart rätt i att Python är väldigt sexigt.

O ja. Det är ganska poppis bland kodare också. Många går från perl till Python för helt vanliga hack.

[mikaelj]

Ursprungligen postat av jwzrd

Jag vet att du givit ett exempel för att visa på hur multidispatch fungerar, men hur tänkte du dig att fem olika metoder hitDrum skulle se ut? Fem helt väsensskilda processer som alla ändå är samma sak men som ändå inte kan implementeras på annat vis med mer gemensamma typer?

Fem olika sorters trummor och några olika trumpinnar, snarare. steel-drum, leather-drum, wood-stick, metal-stick, osv.

Ursprungligen postat av jwzrd

apply()-metoden kan överlagras i olika implementationer av en AbstractDrumHitter där du alltså får en subtyp per multi-metod.

Och vips har vi (som du skrev ovan) en hel drös "design pattern" som det inte finns ett behov av i moderna språk. ;-)

Ursprungligen postat av jwzrd

Om din genersiska funktion alltså har en hit(ElectronicDrumKit Spatula) och en hit(KitchenSink SoupLadel) som ju blir fallet - du får skriva en metod per fall, så kan jag ha en: ElectronicDrumKitSpatulaHitter och en KitchenSinkSoupLadelHitter implementation av AbstractLittleDrummerBoy<T, U> (där T är trumtypen; U pinntypen) men "problemet" för mig blir att först delegera anropet rätt.

Japp. Och ju enklare ett problem blir att lösa, desto oftare löser man det. Istället för att göra det med hjälpklasser, fabriker och abstrakta gränssnitt har man det enkelt integrerat i språket, t.ex. multimetoder. En fin vinst.

Från Design Patterns in Dynamic Languages





... för att inte tala om makron ...

[jwzrd]

Ursprungligen postat av mikaelj

Fem olika sorters trummor och några olika trumpinnar, snarare. steel-drum, leather-drum, wood-stick, metal-stick, osv.

Och vips har vi (som du skrev ovan) en hel drös "design pattern" som det inte finns ett behov av i moderna språk. ;-)

Japp. Och ju enklare ett problem blir att lösa, desto oftare löser man det. Istället för att göra det med hjälpklasser, fabriker och abstrakta gränssnitt har man det enkelt integrerat i språket, t.ex. multimetoder. En fin vinst.

Från Design Patterns in Dynamic Languages





... för att inte tala om makron ...

Nu börjar du göra polemik av det här helt i onödan. T ex dissar du först design patterns men sen... ger du egna sådana.

Det är sen inte ett problem du har att din trumslagarfunktion inte låter sig implementeras med Lisp i Java. Det är ett contreived exempel som du använder för att visa hur du inte kan skriva Lisp i Java.

Beroende på _exakt_ hur problemet som t ex kan lösas med dynamic dispatch i ett språk som har den feature:n ser ut, så kan man lösa det i alla språk som finns.