2010-06-18 16 views
17

Gli impliciti di Scala sono molto potenti. Sono curioso di sapere se sono una nuova/unica funzionalità di Scala, o il concetto esisteva già in altri linguaggi di programmazione.Altri linguaggi di programmazione che supportano impliciti "a la Scala"

Grazie.

EDIT:

di chiarire la mia domanda, sì, sto parlando di questa implementazione concreta. All'inizio le "cose ​​implicite" sembravano strane, ma dopo averlo usato per un po 'e aver visto come lo usano gli altri, sono impressionato da come funziona.

+0

Penso che dovresti distinguere tra metodi impliciti e valori impliciti. Immagino sia possibile che un linguaggio supporti solo uno di essi. Ovviamente, avere entrambi apre la porta ad ulteriori possibilità, come la già citata soluzione "simulazione di classi di tipi", che è praticamente una combinazione intelligente di queste. –

+0

Sto usando la parola * implicits * per fare riferimento sia a conversioni implicite che a valori/parametri impliciti. Penso che sia l'interpretazione "normale" nel contesto di Scala ma forse mi sbaglio. – gerferra

+0

@Daniel Mille grazie!Ho modificato la domanda rimuovendo la nota e il tuo messaggio. Grazie ancora. – gerferra

risposta

14

Sembra che l'ispirazione è stata classi tipo di Haskell. Almeno un articolo del blog afferma che implicits have their origin in Haskell type classes; l'articolo si riferisce a un documento del 2006 di Martin Odersky dal titolo Poor Man's Type Classes. E Daniel Sobral ha scritto un recente articolo su come simulate type classes with implicits.

+0

In effetti, una delle cose che mi colpisce di più sono le * cose delle classi di tipi * usate in "Ordine" e "Numerico". Grazie per i riferimenti! – gerferra

+6

Tuttavia, gli impliciti sono molto più generali delle classi di tipi. Ad esempio, puoi sempre scegliere di passare esplicitamente un parametro implicito, invece di farlo compilare dal compilatore. Mentre in Haskell i typeclass sono sempre fatti dal compilatore. –

1

Dipende da quanto in generale si desidera allungare la frase "supporta impliciti". Uno dei motivi convincenti per impliciti in Scala consiste essenzialmente nell'aggiungere metodi a una classe esistente (a cui non si ha accesso). Ciò è possibile in altri linguaggi attraverso diversi costrutti: ad esempio, Smalltalk, Ruby e Objective-C supportano l'aggiunta di metodi a classi che non si controllano.

1

Se ho capito implicitamente correttamente da http://patricklogan.blogspot.com/2007/06/scala-implicits.html allora sì, ci sono diverse lingue che lo supportano.

I migliori sono i metodi di estensione C#. Un esempio recente in cui li ho usati:

Spesso ho dovuto fare calcoli a distanza tra due Point s. Un Point non ha un metodo per calcolare la distanza da un altro punto così ho aggiunto il seguente codice per il mio progetto:

class MyPointExtension 
{ 
    public static Double GetDistance(this Point p1, Point p2) 
    { 
    return /* the pythagoras code */ 
    } 
} 

ho potuto poi fare:

Point unitPosition = new Point(x,y); 
Point target = new Point(x2,y2); 
Double distance = unitPosition.GetDistance(target); 
+8

Gli impliciti di Scala sono più potenti dei metodi di estensione C#. Nelle parole di Odersky * "[in C#] puoi solo aggiungere metodi, non campi o interfacce a una classe" *. Vedi qui http://www.artima.com/weblogs/viewpost.jsp?thread=179766 – gerferra

+5

Sono d'accordo con @ german1981, i metodi di estensione sono uno degli usi per impliciti di Scala, ma non ha la meccanica degli stessi impliciti. –

1

Sebbene non così potente come implicito in Scala, C++ aveva già operatori di conversione e costruttori di copie che potevano entrambi portare a conversioni di tipo implicite. In combinazione con la capacità di definire gli operatori binari (qualcosa che Scala non consente) questo ha conferito parte del potere implicito di Scala.

5

Nel 2000 c'era un ottimo articolo su Princples of Programming Lanages (POPL), che ha introdotto implicit parameters. Sono stati implementati in Haskell. Sono sicuro che Martin Odersky, il designer di Scala, fosse a conoscenza di questo lavoro. (Martin è un partecipante frequente e benvenuto e collaboratore di POPL.)

Problemi correlati