Является ли стандартной практикой использование псевдонимов типов для обозначения семантики параметров?

Question

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

Например, в этом предвзято союз:

type NetworkEvent = 
| Message of string * string * string 
| ... 

Я хочу, чтобы было ясно, что первый и второй элементы являются отправитель и имена получателей соответственно. Это хорошая практика, чтобы сделать что-то вроде этого:

type SenderName = string 
type RecipientName = string 

type NetworkEvent = 
| Message of SenderName * RecipientName * string 
| ... 

Много библиотек C/C++ имеет распространение типов (например, win32.h), но в этих языках, даже если имена параметров не являются обязательными во многих случаях , это все равно можно сделать. Это не относится к F #.

Answer 1

Я считаю, что использование псевдонимов типа для целей документирования является хорошим и простым способом документирования дискриминируемых союзов.Я использую тот же подход во многих своих демонстрационных версиях (см. for example this one), и я знаю, что некоторые люди используют его и в производственных приложениях. Я думаю, что есть два способа сделать определение больше самопонятно:

Используйте псевдонимы типа: Таким образом, вы добавите документацию, которая видна в IntelliSense, но это не распространяется через систему типа - когда вы использовали значение типа псевдонима, компилятор будет обрабатывать его как string, поэтому вы не увидите всю документацию повсюду.

Использование одноразовых соединений Это шаблон, который использовался в некоторых местах компилятора F #. Это делает информацию более заметным, чем при использовании типа-псевдонимы, так как тип SenderName фактически другой тип, чем string (с другой стороны, это может иметь некоторые небольшие потери производительности):

type SenderName = SenderName of string 
type RecipientName = RecipientName of string 
type NetworkElement = 
    | Message of SenderName * RecipietName * string 

match netelem with 
| Message(SenderName sender, RecipientName recipiet, msg) -> ... 

Используйте записи: Таким образом, вы явно определяете запись для переноса информации о случае объединения. Это более синтаксически многословно, но, вероятно, добавляет дополнительную информацию самым доступным способом. Вы все равно можете использовать сопоставление образцов по записям, или вы можете использовать точечную нотацию для доступа к элементам. Также легче добавлять новые поля во время разработки:

type MessageData = 
    { SenderName : string; RecipientName : string; Message : string } 
type NetworkEvent = 
    | Message of MessageData 

match netelem with 
| Message{ SenderName = sender; RecipientName = recipiet; Message = msg} -> ... 

Answer 2

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

Для чисел, вы можете сделать что-то немного более изящное, используя единицы измерения, но это не работает для строк

Answer 3

Я не вижу ничего плохого в этом, но это может раздражать, имеющие 10 псевдонимов string, например. Если это вас не беспокоит, я говорю, продолжайте. Лично мне хотелось бы получить следующее:

type NetworkEvent = 
| Message of SenderName:string * RecipientName:string * string 
| ... 

Тогда Intellisense может оказать вам помощь. (EDIT: Голосование по этому предложению here.)

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

Answer 4

Я прочитал свою долю в F #, как в Интернете, так и в книгах, но никогда не видел, чтобы кто-либо использовал псевдонимы как форму документации. Поэтому я скажу, что это не стандартная практика. Его также можно рассматривать как форму дублирования кода.

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

Если вы собираетесь использовать дискриминированный союз по нескольким классам, тогда используйте записи, как вы предложили, или сохраните все методы, охваченные дискриминационным объединением, как показано ниже.

type NetworkEvent = 
    | Message of string * string * string 

    static member Create(sender, recipient, message) = 
     Message(sender, recipient, message) 

    member this.Send() = 
     math this with 
     | Message(sender, recipient, message) -> 
      printf "Sent: %A" message 

let message = NetworkEvent.Create("me", "you", "hi") 

Вы можете использовать records in pattern matching, поэтому кортежи действительно вопрос удобства и должны быть заменены записями, как код растет.

Если дискриминационный союз имеет кучу кортежей с одинаковой подписью, то пришло время разбить его на два дискриминируемых объединения. Это также помешает вам иметь несколько записей с одной и той же подписью.

type NetworkEvent2 = 
    | UDPMessage of string * string * string 
    | Broadcast of string * string * string 
    | Loopback of string * string * string 
    | ConnectionRequest of string 
    | FlushEventQueue 

в

type MessageType = 
    | UDPMessage 
    | Broadcast 
    | Loopback 

type NetworkEvent = 
    | Message of MessageType * string * string * string 
    | ConnectionRequest of string 
    | FlushEventQueue