2009-07-08, 12:53
|
#1
|
Reg.datum: Apr 2004
Inlägg: 9 123
|
Tråden för oss som programmerar eller sysslar med IT
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.
Citat:
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:
Kod:
(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.
Citat:
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)
|
|
|
|
2009-07-08, 13:19
|
#2
|
Vrickad & älskvard
Reg.datum: Oct 2008
Ort: Nära 2:ans ändhållplats söderut
Inlägg: 21 094
|
Bra initiativ!
Citat:
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.
__________________
Träning! | jwzrd: Efter det där inlägget får du ligga med mig mikaelj!
Scratch89: Du verkar tro att vi alla blir lite hårda i byxan av att dränka oss i sockerlösning. | stevebc: 85 kg extra i dips? Nu är du skäggstark på riktigt! Karlos: Ditt sista marklyft var något av det coolaste jag sett i styrkelyftsväg live. | camilla: du är en extrem teoretiker och totalt känslokall.
|
|
|
2009-07-08, 13:30
|
#3
|
Besserwisser
Reg.datum: Aug 2004
Ort: Västerås
Inlägg: 3 134
|
aa tja, jag gillar kod och tjejer och mat.
__________________
╔╗╔═╦╗
║╚╣║║╚╗
╚═╩═╩═╝
|
|
|
2009-07-08, 13:38
|
#4
|
Mother love bone
Reg.datum: Aug 2006
Inlägg: 1 709
|
select * from tab;
__________________
Citat:
Ursprungligen postat av lectris
Är shut teh face knäpp som klagar över att en tjej skickar porr?
|
|
|
|
2009-07-08, 13:38
|
#5
|
Reg.datum: Apr 2004
Inlägg: 9 123
|
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.
|
|
|
2009-07-08, 13:45
|
#6
|
Banned User
Reg.datum: May 2002
Ort: Skamträsklidn
Inlägg: 22 303
|
Citat:
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.
|
|
|
2009-07-08, 13:54
|
#7
|
Banned User
Reg.datum: May 2002
Ort: Skamträsklidn
Inlägg: 22 303
|
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 ...
}
|
|
|
2009-07-08, 14:00
|
#8
|
Banned User
Reg.datum: May 2002
Ort: Skamträsklidn
Inlägg: 22 303
|
Jag ska lägga till att jag inser att det är två olika features och att det alltså finns en skillnad.
|
|
|
2009-07-08, 14:02
|
#9
|
Vrickad & älskvard
Reg.datum: Oct 2008
Ort: Nära 2:ans ändhållplats söderut
Inlägg: 21 094
|
Citat:
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.
Citat:
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).
__________________
Träning! | jwzrd: Efter det där inlägget får du ligga med mig mikaelj!
Scratch89: Du verkar tro att vi alla blir lite hårda i byxan av att dränka oss i sockerlösning. | stevebc: 85 kg extra i dips? Nu är du skäggstark på riktigt! Karlos: Ditt sista marklyft var något av det coolaste jag sett i styrkelyftsväg live. | camilla: du är en extrem teoretiker och totalt känslokall.
|
|
|
2009-07-08, 14:10
|
#10
|
Living the good life
Reg.datum: Jul 2004
Ort: Hongkong
Inlägg: 1 787
|
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?
__________________
Iron addict for life
|
|
|
2009-07-08, 14:11
|
#11
|
Banned User
Reg.datum: May 2002
Ort: Skamträsklidn
Inlägg: 22 303
|
Citat:
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.
|
|
|
2009-07-08, 14:13
|
#12
|
Reg.datum: Apr 2004
Inlägg: 9 123
|
Citat:
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.
|
|
|
2009-07-08, 14:15
|
#13
|
Banned User
Reg.datum: May 2002
Ort: Skamträsklidn
Inlägg: 22 303
|
Citat:
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.
|
|
|
2009-07-08, 14:42
|
#14
|
Vrickad & älskvard
Reg.datum: Oct 2008
Ort: Nära 2:ans ändhållplats söderut
Inlägg: 21 094
|
Citat:
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.
Citat:
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. ;-)
Citat:
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 ...
__________________
Träning! | jwzrd: Efter det där inlägget får du ligga med mig mikaelj!
Scratch89: Du verkar tro att vi alla blir lite hårda i byxan av att dränka oss i sockerlösning. | stevebc: 85 kg extra i dips? Nu är du skäggstark på riktigt! Karlos: Ditt sista marklyft var något av det coolaste jag sett i styrkelyftsväg live. | camilla: du är en extrem teoretiker och totalt känslokall.
|
|
|
2009-07-08, 16:15
|
#15
|
Banned User
Reg.datum: May 2002
Ort: Skamträsklidn
Inlägg: 22 303
|
Citat:
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.
|
|
|
Ämnesverktyg |
|
Visningsalternativ |
Linjär visning
|
Regler för att posta
|
Du får inte posta nya ämnen
Du får inte posta svar
Du får inte posta bifogade filer
Du får inte redigera dina inlägg
HTML-kod är av
|
|
|
Alla tider är GMT +1. Klockan är nu 03:38.
|
|