¿Cuáles son los argumentos a favor y en contra de la equivalencia de nombres y la equivalencia estructural?

Question

En los círculos de diseño de idiomas solía haber un largo debate sobre si los idiomas deberían usar structural equivalence o name equivalence. Los lenguajes como ALGOL o ML o Modula-3 usaban equivalencia estructural mientras ... bueno, casi todos los lenguajes de programación emplean equivalencia nombrada (incluyendo Modula-2).

¿Cuáles son los argumentos típicos a favor de la equivalencia estructural? ¿Cuáles son los argumentos típicos en oposición a esto? ¿Cuáles son los argumentos típicos a favor de la equivalencia de nombres? ¿Cuáles son los argumentos típicos en oposición a esto?

Answer 1

Creo que la ventaja de los sistemas de tipo estructural es que lo alientan a crear interfaces de grano fino orientadas hacia lo que el usuario de la interfaz necesita, en lugar de lo que el implementador proporciona.

En un sistema de tipo nominativo necesita una dependencia común en la interfaz. En un sistema de tipo estructural, ese requisito se elimina: puede construir un sistema débilmente acoplado sin necesidad de crear esa biblioteca común donde coloca todas las interfaces. Cada cliente puede declarar independientemente la interfaz que espera de un colaborador.

La desventaja de los sistemas de tipo estructural es que combinan clases con interfaces que pueden no implementar el contrato correcto. Por ejemplo, si usted tiene esta interfaz:

public interface IBananaProvider 
{ 
    /// Returns a banana, never null. 
    Banana GetBanana(); 
} 

entonces implícitamente se considerará lo siguiente clase para implementar IBananaProvider en un sistema de tipo estructural. Sin embargo, la clase viola la condición post que el plátano regresado nunca es nula:

public class SomeBananaProvider 
{ 
    // returns a banana or null if we're all out 
    public Banana GetBanana() 
    { 
     if (bananas.Count > 0) 
     { 
      return bananas.RemoveLast(); 
     } 
     else 
     { 
      return null; 
     } 
    } 
} 

Esto podría fijarse si el contrato se especifica alguna manera formal y considera parte de la estructura de tipo. Creo que las cosas se están moviendo en esa dirección, p. System.Diagnostics.Contracts en .NET 4.0.

Answer 2

Un buen argumento a favor de la equivalencia de nombres estrictos (como está disponible en Ada por ejemplo) es que hace posible que el compilador rechace código que accidentalmente mezcla diferentes unidades, como por ejemplo centímetros y pulgadas, o celsius y fahrenheit .

En un lenguaje con el nombre de equivalencia estricta puede tener dos tipos

type celsius based on float; 
type fahrenheit based on float; 

var c : celsius; var f : fahrenheit; 

c := f; /* compile time error: incompatible types */ 

tiempo, en un lenguaje con el nombre de equivalencia perder y en uno con la equivalencia estructural ...

type celsius is float; 
type fahrenheit is float; 

c := f; /* no error and no warning here */ 

.. Usted terminaría con un error de cálculo que conducirá a un comportamiento impredecible, dependiendo del tipo de aplicación y el sistema esto podría conducir a una grave pérdida financiera o incluso a la muerte. Tal error lógico también es muy difícil de rastrear sin una equivalencia de nombre estricta en su lugar.