¿Hay algún lenguaje estático de tipo pato?

Question

Can I specify interfaces when I declare a member?

Después de pensar en esta cuestión por un tiempo, se me ocurrió que un lenguaje de pato estático podría funcionar. ¿Por qué las clases predefinidas no pueden vincularse a una interfaz en tiempo de compilación? Ejemplo:

public interface IMyInterface 
{ 
    public void MyMethod(); 
} 

public class MyClass //Does not explicitly implement IMyInterface 
{ 
    public void MyMethod() //But contains a compatible method definition 
    { 
    Console.WriteLine("Hello, world!"); 
    } 
} 

... 

public void CallMyMethod(IMyInterface m) 
{ 
    m.MyMethod(); 
} 

... 

MyClass obj = new MyClass(); 
CallMyMethod(obj);  // Automatically recognize that MyClass "fits" 
         // MyInterface, and force a type-cast. 

¿Conoce algún idioma que admita esta función? ¿Sería útil en Java o C#? ¿Es fundamentalmente defectuoso de alguna manera? Entiendo que podría subclase MyClass e implementar la interfaz o usar el patrón de diseño del Adaptador para lograr lo mismo, pero esos enfoques simplemente parecen un código repetitivo innecesario.

Answer 1

lenguajes de tipo estático, por definición, comprobar tipos en tiempo de compilación , no tiempo de ejecución. Uno de los problemas obvios con el sistema descrito anteriormente es que el compilador comprobará los tipos cuando se compile el programa, no en tiempo de ejecución.

Ahora, se podría construir más inteligencia en el compilador por lo que podría derivar tipos, en lugar de tener el programador explícitamente declaran tipos; el compilador podría ver que MyClass implementa un método MyMethod(), y manejar este caso en consecuencia, sin la necesidad de declarar explícitamente las interfaces (como usted sugiere). Tal compilador podría utilizar la inferencia de tipo, como Hindley-Milner.

Por supuesto, algunos lenguajes estáticos como Haskell ya hacen algo similar a lo que sugiere; el compilador Haskell puede inferir tipos (la mayoría de las veces) sin la necesidad de declararlos explícitamente. Pero obviamente, Java/C# no tiene esta habilidad.

Answer 2

No veo el punto. ¿Por qué no ser explícito de que la clase implementa la interfaz y ha terminado con ella? La implementación de la interfaz es lo que le dice a otros programadores que se supone que esta clase se comporte de la forma que define la interfaz. Simplemente tener el mismo nombre y firma en un método no transmite ninguna garantía de que la intención del diseñador fue realizar acciones similares con el método. Eso puede ser, pero ¿por qué dejarlo para la interpretación (y el mal uso)?

La razón por la que puede "escaparse" con éxito en idiomas dinámicos tiene más que ver con TDD que con el idioma en sí. En mi opinión, si el lenguaje ofrece la posibilidad de dar este tipo de orientación a otras personas que usan/ven el código, debe usarlo. En realidad, mejora la claridad y vale la pena los pocos caracteres adicionales. En el caso donde no tenga acceso para hacer esto, entonces un Adaptador tiene el mismo propósito de declarar explícitamente cómo se relaciona la interfaz con la otra clase.

Answer 3

Un diseño de prelanzamiento para Visual Basic 9 tenía soporte para el tipado de pato estático usando interfaces dinámicas pero cortaban la característica * para enviar a tiempo.

Answer 4

Boo definitivamente es un pato-mecanografiado lenguaje estático: http://boo.codehaus.org/Duck+Typing

un extracto:

Boo is a statically typed language, like Java or C#. This means your boo applications will run about as fast as those coded in other statically typed languages for .NET or Mono. But using a statically typed language sometimes constrains you to an inflexible and verbose coding style, with the sometimes necessary type declarations (like "x as int", but this is not often necessary due to boo's Type Inference) and sometimes necessary type casts (see Casting Types). Boo's support for Type Inference and eventually generics help here, but...

Sometimes it is appropriate to give up the safety net provided by static typing. Maybe you just want to explore an API without worrying too much about method signatures or maybe you're creating code that talks to external components such as COM objects. Either way the choice should be yours not mine.

Along with the normal types like object, int, string...boo has a special type called "duck". The term is inspired by the ruby programming language's duck typing feature ("If it walks like a duck and quacks like a duck, it must be a duck").

Answer 5

F # apoya la tipificación de pato estática, aunque con un inconveniente: hay que utilizar restricciones miembros. Los detalles están disponibles en este blog entry.

Ejemplo del blog citado:

let inline speak (a: ^a) = 
    let x = (^a : (member speak: unit -> string) (a)) 
    printfn "It said: %s" x 
    let y = (^a : (member talk: unit -> string) (a)) 
    printfn "Then it said %s" y 

type duck() = 
    member x.speak() = "quack" 
    member x.talk() = "quackity quack" 
type dog() = 
    member x.speak() = "woof" 
    member x.talk() = "arrrr" 

let x = new duck() 
let y = new dog() 
speak x 
speak y 

Answer 6

Cómo sobre el uso de plantillas en C++?

class IMyInterface // Inheritance from this is optional 
{ 
public: 
    virtual void MyMethod() = 0; 
} 

class MyClass // Does not explicitly implement IMyInterface 
{ 
public: 
    void MyMethod() // But contains a compatible method definition 
    { 
    std::cout << "Hello, world!" "\n"; 
    } 
} 

template<typename MyInterface> 
void CallMyMethod(MyInterface& m) 
{ 
    m.MyMethod(); // instantiation succeeds iff MyInterface has MyMethod 
} 

MyClass obj; 
CallMyMethod(obj);  // Automatically generate code with MyClass as 
         // MyInterface 

realidad no he compilado el código, pero yo creo que es viable y una bastante trivial C++ - zación del código original propuesto (pero no laborable).

Answer 7

Suena como Mixins o rasgos:
http://en.wikipedia.org/wiki/Mixin
http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf

Answer 8

tipos estructurales en Scala hace algo como esto.

Ver Statically Checked “Duck Typing” in Scala

Answer 9

La mayoría de los idiomas en el apoyo a la familia ML tipos estructurales con la inferencia y esquemas de tipo restringidos, que es la terminología del lenguaje diseñador de geek que parece más probable es que lo que quiere decir con la frase "estático pato-tipado "en la pregunta original.

Los idiomas más populares en esta familia que vienen a la mente incluyen: Haskell, Objective Caml, F # y Scala. El que más se acerque a tu ejemplo, por supuesto, sería Objective Caml. He aquí una traducción de su ejemplo:

open Printf 

class type iMyInterface = object 
    method myMethod: unit 
end 

class myClass = object 
    method myMethod = printf "Hello, world!" 
end 

let callMyMethod: #iMyInterface -> unit = fun m -> m#myMethod 

let myClass = new myClass 

callMyMethod myClass 

Nota: algunos de los nombres que ha utilizado tienen que ser cambiados para cumplir con la noción de la semántica de casos identificador de OCaml, pero por lo demás, se trata de una traducción bastante sencillo.

También, vale la pena señalar, ni la anotación de tipo en la función callMyMethod ni la definición del tipo de clase iMyInterface es estrictamente necesaria. Objetivo Caml puede inferir todo en su ejemplo sin ninguna declaración de tipo.

Answer 10

Una nueva respuesta a esta pregunta, Go has exactly this feature. Creo que es genial & inteligente (aunque me interesará ver cómo se desarrolla en la vida real) y felicitaciones al pensar en ello.

como se documenta in the official documentation (as part of the Tour of Go, with example code):

Interfaces are implemented implicitly

A type implements an interface by implementing its methods. There is no explicit declaration of intent, no "implements" keyword.

Implicit interfaces decouple the definition of an interface from its implementation, which could then appear in any package without prearrangement.

Answer 11

En la última versión de mi lenguaje de programación que soporta Heron algo similar a través de una coacción-subtipificación estructural operador llama as. Así que en lugar de:

MyClass obj = new MyClass(); 
CallMyMethod(obj); 

lo tanto se escribe:

MyClass obj = new MyClass(); 
CallMyMethod(obj as IMyInterface); 

Al igual que en el ejemplo, en este caso MyClass no tiene que poner en práctica de manera explícita IMyInterface, pero si lo hizo el reparto podría suceder de forma implícita y el operador as podría omitirse.

Escribí un poco más sobre la técnica que llamo subtipificación estructural explícita en this article.

Answer 12

D (http://dlang.org) es un lenguaje estáticamente compilado y proporciona pato-tipado a través de wrap() y unwrap() (http://dlang.org/phobos-prerelease/std_typecons.html#.unwrap).

Answer 13

Las nuevas versiones de C++ se mueven en la dirección de tipado estático de patos. Puede que algún día (? Hoy) escribir algo como esto:

auto plus(auto x, auto y){ 
    return x+y; 
} 

y éste deje de recopilar si no hay llamada de función correspondiente para x+y.

cuanto a su crítica:

A new "CallMyMethod" is created for each different type you pass to it, so it's not really type inference.

pero es la inferencia de tipos (que se puede decir foo(bar) donde foo es una función de plantilla), y tiene el mismo efecto, excepto que es más eficiente en tiempo y necesita más espacio en el código compilado.

De lo contrario, tendría que buscar el método durante el tiempo de ejecución. Tendría que encontrar un nombre, luego verificar que el nombre tenga un método con los parámetros correctos.

O tendría que almacenar toda esa información sobre las interfaces que coinciden, y examinar cada clase que coincida con una interfaz, y luego agregar automáticamente esa interfaz.

En cualquier caso, eso le permite romper implícita y accidentalmente la jerarquía de clases, lo que es malo para una nueva característica porque va en contra de los hábitos de los programadores de C#/Java. Con las plantillas C++, ya sabes que estás en un campo minado (y también están agregando características ("conceptos") para permitir restricciones en los parámetros de la plantilla).

Answer 14

TypeScript!

Bien, bien ... Así que es un superconjunto javascript y puede que no constituye una "lengua", pero este tipo de pato tipos estáticos es vital a máquina de escribir.

Answer 15

Crystal es un lenguaje estáticamente pato-mecanografiado. Example:

def add(x, y) 
    x + y 
end 

add(true, false) 

la llamada a add causas de este error de compilación:

Error in foo.cr:6: instantiating 'add(Bool, Bool)' 

add(true, false) 
^~~ 

in foo.cr:2: undefined method '+' for Bool 

    x + y 
    ^