Какое поведение для наследников наследников?

ну если ты не покрыл одного наследника 1го уровня то должен покрыть его наследников

Какое поведение для наследников наследников?

Зная, что там обычный as с проверкой, ты и сам можешь ответить на этот вопрос :)

Зная, что там обычный as с проверкой, ты и сам можешь ответить на этот вопрос :)

А, ну да

Тогда фигня получается

И тебе всё равно всегда в рантайме смогут подсунуть что-нибудь не то, отнаследовавшись от базового класса (если он не приватный какой-нибудь).

@ruzzke_mir С чего ты взял, что это ошибка в struct DU?

(а в DU не смогут)

(заметьте, я не говорю, что фича в C# плохая — она нормальная и полезная, я даже уже использую кой-где)

Нормальная, полезная

@ruzzke_mir С чего ты взял, что это ошибка в struct DU?

как это с чего? вот же глюкописан, ну и сам пробовал https://github.com/Microsoft/visualfsharp/pull/2811

@ruzzke_mir Ты привел пример. [<Struct>] type A = | B of int | C of int

не веришь - попробуй сам, получишь ошибку компиляции))

Он действительно не компилируется. С понятной ошибкой. error FS: If a union type has more than one case and is a struct, then all fields within the union type must be given unique names.

ошибка абсолютно понятная

там конфликтуют конструкторы

из за неправильного сгененрированного IL

два одинаковых конструктора с одним аргументом типа int

@ruzzke_mir Я считаю, что это by design.

да глюк это, вот же https://github.com/Microsoft/visualfsharp/issues/2463

Потому что вот этот код прекрасно компилируется. [<Struct>] type A = | B of b:int | C of c:int

И именно этот случай чинил Сайм.

да, так можно

не думаю, что только этот случай

А в чем смысл этого случая?

Там указаны конкретные issue, которые он починил.

Если разные типы в кейзах, то понятно

для варианта без явного указания параметров DU тоже был ишшуй

Не успел доехать в релиз?

@ruzzke_mir Просто смержили очень давно.

Мне это кажется странным немного.

> Though we won't get this in for 15.2, this seems like a 15.3 fix. 

@ruzzke_mir Был неправ. Спасибо.

@ruzzke_mir Был неправ. Спасибо.

всегда рад помочь

Можно ли на ФШарпе написать меню-бар-апп для макОс?

F# тоже не запретит :(

По моему запретит. Или я что-то пропустил?

Можно ли на ФШарпе написать меню-бар-апп для макОс?

Можно, но придётся немножко с нативным кодом подружиться.

Можно, но придётся немножко с нативным кодом подружиться.

Нативный код? В смысле Swift?

По моему запретит. Или я что-то пропустил?

Не запрещает. Показывает предупреждение, но не ошибку.

Нативный код? В смысле Swift?

Ну а какой там API у этой штуки, которую ты хочешь использовать? Я думаю, C.

В смысле, должна быть системная библиотека, которая предоставляет C-интерфейс для этой рюшечки. Ты можешь эту библиотеку вызывать из F#.

Возможно, кто-то уже нужный тебе API завернул в управляемый код. Это надо в нугете искать.

Можно ли на ФШарпе написать меню-бар-апп для макОс?

Вот тут что-то немножко пишут: https://stackoverflow.com/questions/17625291/creating-a-windowless-menu-bar-icon-application-in-monomac-xamarin-c-sharp Похоже, это нетривиально вообще.

Щас общался с С#-овцами на работе по поводу поддержки паттернматчинга в R#. Говорят, пока не подвезли, но общали скоро. А сейчас чекает PVS studio.

Ну а какой там API у этой штуки, которую ты хочешь использовать? Я думаю, C.

вот dll-ки я умею из ФШарпа вызывть, а как вот с МакОСовым АПИ не пойму с чего начать

Вот тут что-то немножко пишут: https://stackoverflow.com/questions/17625291/creating-a-windowless-menu-bar-icon-application-in-monomac-xamarin-c-sharp Похоже, это нетривиально вообще.

Спасибо почитаю

Кажется, там используют MonoMac. Чёрт его знает, насколько это актуально вообще :(

ну и кстати не вовсех случаях спасают именованные поля. Вот этот код из ишшуя всё ещё не компилится [<Struct>] type Shape = | Circle of radius: float | Square of side: double | Rectangle of sides: double*double

Подтверждаю, упал: Error in pass2 for type Shape, error: duplicate entry '.ctor' in method table

Щас общался с С#-овцами на работе по поводу поддержки паттернматчинга в R#. Говорят, пока не подвезли, но общали скоро. А сейчас чекает PVS studio.

R# - это ROBLOX?

нет, это решарпер

аа

ни у кого тут нет PVS студии затестить проверку полноты паттернматчинга типов сум в C#?

она бесплатна же, вроде

типа триал версии

Решарпер должен построить AST

вовсе нет. достаточно рефлективно найти всех потомков класса и проанализировать проверку их в switch

для меня удивительно что R# этого не делает

У нас такой анализатор есть корпоративный для Roslyn ещё

Чтобы найти рефлективно, надо по идее все скомпилировать, ибо могут быть кейсы с code gen

не забывайте еще про принцип Лискова. Если делать расширяемую архитектуру то Pattern Matching не самый лучший попутчик

Благодаря тому что PM нарушает принцип Лискова в больших проектах при таком подходе не получится докидывать в виде отдельных бинарников плагины

придется вносить изменения в PM и заново все перекомпилировать, что далеко не всегда возможно

расширяемая архитектура и SOLID - я в это не верю) имхо сие есть ересь ООПшная)))

В смысле? А по каким принципам реализуете архитектуру больших проектов?

Вообще как бы функциональное программирование не противоречит принципу Лискова

ERROR: S client not available

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

у нас сейчас код который переиспользуется в трех проектах + часть этого кода переиспользуется на сервере

и если не соблюдать принципы SOLID то проект моментально превратится в хлам. Если думаете что F# и SOLID не софместимы то это не так

есть большое заблуждение что F# магическим образом сделает код лучше и говнокода не будет. Это не так. F# как и любой другой функциональный язык программирования потребует соблюдения принципов SOLID в больших проектах - или очень быстро проект похоронит разработчиков

при чем F# гораздо лучше подходит для соблюдения этих принципов

Interface Segregation - говорит о том что в идеале в одном интерфейсе должен быть только один метод. Собственно одна функция - один интерфейс

ну и по остальным то же самое

"Если думаете что F# и SOLID не софместимы то это не так" - не думаю. SOLID можно трактовать двояко. То, что Вы предлагаете, например, создаёт бОльшую неопределенность, поскольку снижает стат. гарантии. Что так же противоречит SOLID. Я к тому, что SOLID - это не спецификация, не тех. требованя, а прсто некоторые общие рекомендации

Хочу подчеркнуть - спор о SOLId ещё более абсурдный чем о монадах))

Погодите. SOLID это не нечто абстрактное и недостежимое. Дядюшка Боб в своих книгах очень подробно и детально расписал про применение принципов SOLID на практике

Благодаря тому что PM нарушает принцип Лискова в больших проектах при таком подходе не получится докидывать в виде отдельных бинарников плагины

там где не надо интегрироваться, внутри приложения, можно и нужно использовать.

в F# просто есть четкое деление данных и функций

и вообще SOLID - это про ООП, DI и т.п. Дядюшка Боб - я его мягко говоря не уважаю и он точно не функциональщик. Фаулер, главный патриарх SOLID - определённо идиот

https://github.com/polytypic/blog/blob/master/posts/2014-08-18-solid.md

Про SOLID и ФП.

это не тот ли фин, который контрибъютит Hopac ?

и вообще SOLID - это про ООП, DI и т.п. Дядюшка Боб - я его мягко говоря не уважаю и он точно не функциональщик. Фаулер, главный патриарх SOLID - определённо идиот

Если вы позволяете себе высказать о них в таком духе я бы сказал что это не они а именно Вы являетесь идиотом. Они гораздо больше функциональщики чем вы. Судя по тем оскорблением что вы пишете то вы как в том анекдоте. "Фигня этот ваш Битлз. Я не слушал но мне Вася напел". Сначала ознакомтесь с их трудами а потом оскорбляйте кого то. Пока что идиотом выглядете только вы

https://fsharpforfunandprofit.com/fppatterns/

Может и Скотт для вас идиот? Хотя бы его доклады послушайте

@ruzzke_mir @SherievAkhmed Ну, вы чего? :(

слушайте, я знаком. Нравится вам это или нет, мне без разницы. Тема глупая, обсуждать смысла не вижу

Дядюшка Боб читал доклад про будущее языков программирования и он сам говорил о важности функционального программирования. Вы просто в силу того что не знаете то о чем говорите думаете что они убивают ФП. Это не так.

вот статья три года наза

http://blog.cleancoder.com/uncle-bob/2014/11/24/FPvsOO.html

@SherievAkhmed Справедливости ради, последние записи Боба про ненужность статической типизации расстраивают.

@SherievAkhmed Справедливости ради, последние записи Боба про ненужность статической типизации расстраивают.

Ты про “the dark path”, про kotlin/swift? Говорят он на clojure кодит.

Ух ты, такие стикеры я одобряю.

Ух ты, такие стикеры я одобряю.

И стёр :(

Ты про “the dark path”, про kotlin/swift? Говорят он на clojure кодит.

Да, про это.

И стёр :(

Не я. :С

Ты про “the dark path”, про kotlin/swift? Говорят он на clojure кодит.

Мне кажется, что та статья была полушутливая.