Ну т.е. type MyClass() as this = ...

https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/classes#self-identifiers

По-моему, для таких случаев нужно self-identifier объявлять на уровне типа

Да здесь локального должно хватать. К тому же это расширение типа.

оо, тоже проперти

Контрастная подсветка или наведение курсора всегда подскажет что получится. Мне бы вот понять как обернуть структуру, чтобы как в рекордах через with вставлять изменения. Оператор неявного преобразования?

@Kleidemos а в каких тогда случаях нужен (обязателен) "само-идентификатор" на уровне типа? А то я что-то и не припоминаю

@Kleidemos а в каких тогда случаях нужен (обязателен) "само-идентификатор" на уровне типа? А то я что-то и не припоминаю

Обычно когда нужно вызвать member из основного конструктора.

А, ну да, логично, спасибо

Ну тогда я и не знаю, что неправильно в вышеприведённом примере

Hi

Where are you from?

Да здесь локального должно хватать. К тому же это расширение типа.

Извиняюсь, не так прочитал, это же имплементация интерфейса, а не расширение.

> member this.Update entity = this.Delete entity entity - почему здесь ошибка? я не могу сослаться на методы, который объявил?

решилась проблема?

решилась проблема?

Не-а

попробуй this привести к IRepository

> member this.Update entity = this.Delete entity entity - почему здесь ошибка? я не могу сослаться на методы, который объявил?

Какая ошибка?

и потом у него уже вызвать Delete

> member this.Update entity = this.Delete entity entity - почему здесь ошибка? я не могу сослаться на методы, который объявил?

Попробуй (this :> IRepositry<_>).Delete.

Попробуй (this :> IRepositry<_>).Delete.

Я первый сказал!

?

Сори, уже отошёл от компа

Но спасибо!

Я первый сказал!

Я код писал, так нечестно!

Попробуй (this :> IRepositry<_>).Delete.

Точняк, вроде, когда-то так и делал

Была проблема

Зато я параллельно зарадил следующие вопросы: Как нужно приводить тип к типу? Почему нужно именно так? Сразу возникает вопрос "почему так не красиво"? А потом приходит понимание насколько это круто

Вообще, такая себе необходимость. Неплохо бы это было подправить, наверное. Но это не точно, т.к. я не эксперт. :) Вероятно, есть у такого подхода плюсы

Вообще, такая себе необходимость. Неплохо бы это было подправить, наверное. Но это не точно, т.к. я не эксперт. :) Вероятно, есть у такого подхода плюсы

Это важнейший плюс

в итоге ты перестаешь передвать class,

Не смешивается всё в кучу? В том же автокомплите всегда ясно, где чьи методы?

в методы\функции, а передаешь Интерфейсы, язык подталкивает к прогрммироаванию на интерфейсах

т.е. даже ооп у F# лучше чем у C#

Пока не вернут protected, однозначного знака не будет.

нуок(

Попробуй (this :> IRepositry<_>).Delete.

На C# точно также надо.

в методы\функции, а передаешь Интерфейсы, язык подталкивает к прогрммироаванию на интерфейсах

А вы так не делаете?

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

А вы так не делаете?

как?

как?

Хранить ссылки как интерфейсы, например

На C# точно также надо.

Не припомню.

На C# точно также надо.

Нет, в C# это неявно работает.

(this as IRepositry<T>).Delete

Это может быть необходимо при явной имплементации интерфейса.

Нет, в C# это неявно работает.

Смотря как реализовать интерфейс!

Это может быть необходимо при явной имплементации интерфейса.

Вот-вот ^ @gsomix (кажется это лишнее в контексте вышесказанного)

У F# более строгий вывод типов. так что тут это необходимость, в C# - шанс отстрелить ногу

ну не ногу, но мизинчик поранить)

Вот-вот ^ @gsomix (кажется это лишнее в контексте вышесказанного)

Пример кода, пожалуйста. Я плохо представляю.

Пример кода, пожалуйста. Я плохо представляю.

Тогда как доберусь до дома, если кто за меня не сделает.

Пример кода, пожалуйста. Я плохо представляю.

interface ILog { void Log(object) }; interface ILogger {void Log(object)}; class LoggerLog : ILog, ILogger { public void ILog.Log(object o) => Console.WriteLine("Log"): public void ILogger.Log(object o) => Console.WriteLine("Logger"): }

interface ILog { void Log(object) }; interface ILogger {void Log(object)}; class LoggerLog : ILog, ILogger { public void ILog.Log(object o) => Console.WriteLine("Log"): public void ILogger.Log(object o) => Console.WriteLine("Logger"): }

Паблик при явности не нужен

Ты знаешь, что знание C# тут не моде? ?

Ты знаешь, что знание C# тут не моде? ?

Не выбрасывать же из багажа родственника (пусть и баба с возу..)

Я больше про себя)

У F# более строгий вывод типов. так что тут это необходимость, в C# - шанс отстрелить ногу

На числах всё же подбешивает немного

На числах всё же подбешивает немного

немного

Математика засоряется приведениями типов

есть немного

Ну и по-быстрому скриптик набросать посложнее получается

В принципе, в Хаскелле похожая проблема

мне казлось что нет

На числах всё же подбешивает немного

Вот тут вопрос, что эффективнее использовать для числового ключа карты, если значений не очень много, например, не будет ли byte/uint16 конвертиться внутри логики поиска в тот же int?

Ну там, насколько вспоминаю, приходилось-таки что-то приводить. Хотя засчёт тайпклассов, вроде, попроще, чем в F#

здесь я думаю тоже проблем не должно быть перегрузить операторы, не?

interface ILog { void Log(object) }; interface ILogger {void Log(object)}; class LoggerLog : ILog, ILogger { public void ILog.Log(object o) => Console.WriteLine("Log"): public void ILogger.Log(object o) => Console.WriteLine("Logger"): }

Ок, редкая фича. ?

Спасибо.

Я сегодня себе мозг сломал. Накидайте идей по десериализации объекта произвольного типа

Используй animate.css

ты о каких идеях?

Да я все хочу написать какой-то билдер, который будет представлять граф сериализации и десериализации объекта

Точнее, два билдера

А что в этом графе будет?

Но чтобы билдеры не знали, куда и как, а просто имели информацию о типе

В графе фактически последовательность записи/чтения типа

Но чтобы билдеры не знали, куда и как, а просто имели информацию о типе

рефлексия?

О рефлексии думал, но пока неясно, поможет ли это задачу решить

В целом, квотейшны могут помочь для скрытия информации о типе

Потому как если врайтер можно спрятать за 'ctx->unit,то с ридером надо что - то думать

Ибо 'ctx->'a

Ну и чтение на конкретные типы завязано

Можно портировать в слоты и читать/писать в них. Как-то раз хотел сделать https://m.habrahabr.ru/post/229035/

ну для начала могу предложить пример из кое-какой книги:

если что, книга об AspNetCore

Данный пример тут не особо поможет, к сожалению

В целом, статья на Хабре навела на определённые размышления, проблема только в том, что там подход основан на erased types,похоже

И можно в рантайме один тип другим подменить

ну для начала могу предложить пример из кое-какой книги:

А что за книга

Я сегодня себе мозг сломал. Накидайте идей по десериализации объекта произвольного типа

Смотрел FsPickler?

А что за книга

хмм... а я так сразу не скажу. Книжке вроде 2-3 года, она писалась еще на первый .Net Core, примеры там на C#

Смотрел FsPickler?

Угу, в целом похоже на то, что хочется, так что, может, в итоге его заюзаю

Угу, в целом похоже на то, что хочется, так что, может, в итоге его заюзаю

Тогда, наверное, тебе нужен TypeShape.

Там есть пример с сериализацией в Json. https://github.com/eiriktsarpalis/TypeShape/blob/master/samples/json-serializer.fsx

И еще презентация про реализацию библиотеки. Existential types, rank-n polymorphism. Все то, чего нет в F#. %) https://eiriktsarpalis.github.io/typeshape/

@vshapenko Видел же?

Ну вот про existential types пока не видел

Вопрос, кстати - что это за грязный трюк?https://github.com/eiriktsarpalis/TypeShape/blob/master/samples/json-serializer.fsx#L254