Каковы аргументы как за, так и против как эквивалентности имени, так и структурной эквивалентности?

Question

В кругах по языковому дизайну долгое время велись споры о том, должны ли языки использовать структурную эквивалентность или эквивалентность имени . В таких языках, как ALGOL, ML или Modula-3, используется структурная эквивалентность, в то время как ... ну, в большинстве случаев в языках программирования используется именованная эквивалентность (включая Modula-2).

Каковы типичные аргументы в пользу структурной эквивалентности? Каковы типичные аргументы против этого? Каковы типичные аргументы в пользу эквивалентности имени? Каковы типичные аргументы против этого?

Answer 1

Я думаю, что преимущество систем структурного типа состоит в том, что они побуждают вас создавать детализированные интерфейсы, ориентированные на то, что нужно пользователю интерфейса, а не на то, что обеспечивает разработчик.

В системе именительного типа вам нужна общая зависимость от интерфейса. В системе структурных типов это требование устраняется: вы можете создать слабо связанную систему без необходимости создавать ту общую библиотеку, в которую вы помещаете все интерфейсы. Каждый клиент может независимо объявить интерфейс, который он ожидает от соавтора.

Недостатком систем структурных типов является то, что они сопоставляют классы с интерфейсами, которые могут не реализовывать правильный контракт. Например, если у вас есть этот интерфейс:

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

тогда неявно будет рассмотрен следующий класс для реализации IBananaProvider в системе структурных типов. Однако класс нарушает условие post, что возвращаемый банан никогда не будет нулевым:

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;
        }
    }
} 

Это может быть исправлено, если договор был каким-то образом определен формально и считается частью структуры типа. Я думаю, что вещи движутся в этом направлении, например, System.Diagnostics.Contracts в .NET 4.0.

Answer 2

Один хороший аргумент в пользу строгой эквивалентности имен (как, например, доступно в Ada) заключается в том, что это позволяет компилятору отклонять код, который случайно смешивает разные единицы, например, сантиметры и дюймы, градусы Цельсия и Фаренгейта.

В языке со строгой эквивалентностью имен вы можете иметь два типа

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

var c : celsius; var f : fahrenheit;

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

В то время как в языке с потерей эквивалентности имени и в языке со структурной эквивалентностью ...

type celsius is float;
type fahrenheit is float;

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

... в результате вы получите неправильный расчет, который приведет к непредсказуемому поведению, в зависимости от типа приложения и системы, это может привести к серьезным финансовым потерям или даже смерти.Подобную логическую ошибку также очень трудно отследить без строгой эквивалентности имен.