Какое соглашение об именах для классов типов в Scala?

Question

В мире Java соглашения об именах для интерфейсов в значительной степени хорошо известны. Например, когда вы говорите, что определенный класс реализует интерфейс Comparable, вы можете сказать, что его объекты сравнимы. Однако соглашения об именах для классов типов не так хорошо установлены. Например, Int имеет неявный доступ Numeric, поэтому вы можете сказать «Int - это тип Numeric». Но есть класс типов Ordering. Я не понимаю, почему это имя было выбрано. «Int - это тип Ordering» не имеет никакого смысла. Возможно, он должен читаться как "Int тип имеет Ordering". Тогда в Скалазе есть Equal и Show. Я совершенно не знаю, почему были выбраны эти имена (кроме того, что они так в Haskell.) Я попытался взглянуть на Haskell, родной язык классов типов, для хорошего соглашения об именах, но обнаружил, что на самом деле их не существует. Парни из Haskell, похоже, не особо заботятся об именах (это то, что я собрал из обсуждений в списке рассылки) Но, исходя из мира Java, я забочусь об именах. Я не совсем могу привыкнуть к парадигме «все говорят».

Вопрос в том, какие соглашения о присвоении имен вы соблюдаете, если вообще используете, для именования классов типов?

Answer 1

На самом деле в Haskell все в основном просто: классы типов обычно называются на основе того, что представляют операции , а не того, что представляет параметр типа *1004*.

Дляпример:

• Read, Show: классы типов, для которых определены стандартные функции сериализации / десериализации строк.
• Eq, Ord: классы типовна котором определяются соотношения равенства и порядка, соответственно.
• Enum: класс типов, определяющих операцию-преемник, т. е. чьи значения могут быть перечислены.
• Monoid, Functor, Monad: классы типов, которые определяют операции, связанные с математическими структурами с одноименными именами.

Некоторые примеры не так хороши: например, Num являетсякласс типов, для которого определяется специальная коллекция неопределенно-арифметически-ориентированных операций, но нет никаких причин, по которым экземпляр Num должен фактически быть числом в любом соглашении.Я чувствую.Возможно, это можно было бы представить как «типы, поддерживающие числовые операции», притворяясь, что «число» на самом деле означает что-либо в этой фразе.имеет только одну функцию (возможно, с несколькими вариантами), почти всегда безопасно называть класс после этой функции, как с show против Show.

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