VS
когда таких коллизий как Individual/Single накапливается достаточно, начинаешь путаться в своих же синонимах
Я у себя коллизию убрал как раз) Single который System в кодобазе не юзается
Size: a a a
2021 January 18
AT
Я у себя коллизию убрал как раз) Single который System в кодобазе не юзается
Возвращаясь к теме конфликтов одинаковых имен полей в разных type. Имхо такое исключает обломинго конфликтов имен и архифаршеидиоматично
AT
Почувствуй себя лиспером
YT
Мне кажется это проще сделать через function
YT
Ну или придумать Age.map
YT
(Хотя это наверное лишнее)
YT
Возвращаясь к теме конфликтов одинаковых имен полей в разных type. Имхо такое исключает обломинго конфликтов имен и архифаршеидиоматично
Кстати может вам будет интересно прикрутить такое вот
https://docs.microsoft.com/ru-ru/dotnet/fsharp/language-reference/units-of-measure
https://docs.microsoft.com/ru-ru/dotnet/fsharp/language-reference/units-of-measure
AT
Кстати может вам будет интересно прикрутить такое вот
https://docs.microsoft.com/ru-ru/dotnet/fsharp/language-reference/units-of-measure
https://docs.microsoft.com/ru-ru/dotnet/fsharp/language-reference/units-of-measure
они не поддерживают uint16
YT
Юинт вообще плохой тип, к сожалению
AT
Юинт вообще плохой тип, к сожалению
У меня нет предубеждений к нему, а вот у компилера-есть :)
VS
они не поддерживают uint16
бери Fsharp.UMX, там поддерживают
VS
Возвращаясь к теме конфликтов одинаковых имен полей в разных type. Имхо такое исключает обломинго конфликтов имен и архифаршеидиоматично
В последнем кейсе у тебя стракт овер класс) там вельютупл тогда нужен
AT
бери Fsharp.UMX, там поддерживают
Да я в курсе, только measure можно пристегнуть к любому типу, а жестко хочу иметь две шутки-без эзотерики компоновать несколько measure в одну структуру и запретить использовать с неподходящими типами measure
YT
У меня нет предубеждений к нему, а вот у компилера-есть :)
Потому что с ними есть косяк
AT
В последнем кейсе у тебя стракт овер класс) там вельютупл тогда нужен
Расшифруй пжлст
R
Возвращаясь к теме конфликтов одинаковых имен полей в разных type. Имхо такое исключает обломинго конфликтов имен и архифаршеидиоматично
как это предотвращает от существования двух юнионов в разных модулях, у которых одинаково называется один из кейсов?
VS
XCoordinate*YCoordinate это Tuple<> дотнетовский, который референс тайп
AT
XCoordinate*YCoordinate это Tuple<> дотнетовский, который референс тайп
Хы, я думал дефолтно используется ValueTuple
VS
нет) это в сишорпе валью тупл
AT
как это предотвращает от существования двух юнионов в разных модулях, у которых одинаково называется один из кейсов?
Мне достаточно, чтобы в рамках одного модуля не скрывались имена, ну и спецификация через пространства имен и модули поможет