Gå til innhold

Symmetric multiple dispatch


Anbefalte innlegg

Hei, jeg har enda en skoleoppgave som jeg behøver litt hjelp til, dessverre.. Skriver inn hele oppgaven og lar den være på engelsk, da jeg tror det blir enklere å forstå på den måten:

 

Some research languages have symmetric multiple dispatch - methods are dened outside classes, and dispatch dynamically on all arguments regardless of order (no overloading at all). There is no designated receiver for a method but rather all arguments are of the same priority - this is intended to handle binary methods better which are often naturally symmetric. The runtime selects the most specic method to dispatch according to all arguments, and so there must be a single best implementation for each possible invocation of a method. The return type is not considered in the implementation selection. When compiling a package the compiler analyzes all types used in the package and all methods and makes sure that for each method and argument types combination there is a single best method to be called - or issues an error if that is not the case. Assume the following three classes in such a language:
package integer
class Integer
{
...
}
Integer add(Integer x,Integer y){...}

package natural
import integer.Integer
class Natural extends Integer
{
...
}
Integer add(Natural x,Integer y){...}
Integer add(Integer x,Natural y){...}
Natural add(Natural x,Natural y){...}

package even
import integer.Integer
class Even extends Integer
{
...
}
Integer add(Even x,Integer y){...}
Integer add(Integer x,Even y){...}
Even add(Even x,Even y){...}

The elipsis in each class body represents (possibly) private data but no other methods. Each package compiles successfully on its own. A user has now written the following client:
package client
import even.Even
import natural.Natural
  void f(Integer x,Integer y) {
     Integer z = add(x,y);
  }
  1. What would be the problem in allowing this client to compile in a type safe multiple dispatch language? Show code that would expose the problem.
  2. Which requirement could we relax so that this call is valid. Dispatch must remain completely symmetric.
  3. What could we do in the client package, in order to resolve the problem, without modifying other packages and without relaxing the requirement mentioned above? What is the conceptual problem with this resolution?

 

  1. Jeg tenker at ut i fra innledningen til oppgaven, vil bli error pga at det ikke er en implementasjon som er bedre enn de andre. Er dette korrekt?
  2. Her er jeg litt usikker, men kanskje man kan endre void metoden i client slik at den tar inn noe annet enn Integer på x eller y?
  3. package client kan importere integer.Integer?

Takker for all hjelp! :)

 

Lenke til kommentar
Videoannonse
Annonse

1. Korrekt, det vil bli error. Men kode som viser problemet vet jeg ingenting om

2. Du kan endre på en av add metodene i enten Even eller Natural, slik at de tar inn Integer både på x og y, det vil løse problemet.

3. mener jeg er korrekt, men vet ikke hvilket konseptuelt problem denne løsningen gir. Mulig noen andre vet.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...