?

Нет, спасибо.

Просто код на рабочем компе,а доступа к интернету нет на нем

Я, кажется, понял, что ты делаешь. Это не очень хорошо.

В моем случае нет конкурентного доступа

В твоем случае есть зависимость от глобального состояния.

Это плохо.

Ну и подумываю все же что-то вроде акки туда впилить

В твоем случае есть зависимость от глобального состояния.

Да,есть

Да,есть

В 2к18 так уже не делают. :)

Ну,учитывая, что нужны в основном синглтоны...

Хотя в конечном итоге это все мигрирует на цепочку акторов,похоже

DI нужно там где есть неясность относительно реализации в момент написания. Вот жираф его в первых версиях не заюзал, потом на пусть истинный вышел) Сериализация там через DI делается сейчас. А вот когда DI делается просто на всякий случай, или для тестов, такого фшарп избегает.

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

Типо тут однозначного ответа нет)

Ну, YAGNI это чаще всего хороший принцип, но нужно уметь находить некоторые места где надо подархитектурить на будущее. Это с опытом наверное приходит)

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

Ну мне пока непонятно, где нужен, у меня нет множественных состояний

У меня всегда одна пользовательская сессия

Можно, конечно,на акторах попробовать,но непонятны бенефиты будут

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

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

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

ну хз, по мне так проблема поддержки di через 10 либ не сильно меньше поддержки через 10 интерфейсов)

Интелисенс для жирных type providers скоро станет шустрее - https://github.com/fsprojects/FSharp.TypeProviders.SDK/pull/229

Отлично!

https://twitter.com/JOTB2018/status/999934894368227328

Старый доклад. :(

Rider 2018.1.1 EAP VS 15.7.2

Rider 2018.1.1 EAP VS 15.7.2

не верю

покажи что открыто, какие экстеншены стоят и тд и тп

Открыт маленький солюшн (4 F# проекта, 1 C#), без экстеншнов.

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

Есть протокол обмена сообщениями

Каждое сообщение состоит из заголовка и данных

Каждый ответ состоит также из стандартного заголовка и тела

Теперь вопрос

Какую структуру данных выбрать под сообщения, чтобы их можно было :1. процессить единообразно.2.Единообразно обрабатывать результат

Пока склоняюсь в сторону, как организованы http request

а что в теле?

В теле бинарные данные заранее неизвестной длины

К сожалению

То,как читать,зависит от поля в заголовке

по описанию все это действительно очень похоже на хттп реквест

Ну у него есть размер

Тут я размер не могу заранее определить

А так да,похоже

а в заголовок длину тоже никак не пропихнуть?)

а в заголовок длину тоже никак не пропихнуть?)

Нет

Она плавающая величина,в общем-то

В целом,конечно, можно то, что начитываю,сразу сериализовывать в json,но тут тоже есть моменты

В общем, дилемма

Какую структуру данных выбрать под сообщения, чтобы их можно было :1. процессить единообразно.2.Единообразно обрабатывать результат

Единообразно -- это как?

Я хочу разнести процессы отправки/получения и десериализации в конкретные типы

Т.е. отправка сейчас единообразно

Через BinaryWriter->unit

Начитка сильно зависит от структуры данных

К сожалению

жаба она такая. прожорливая

жаба она такая. прожорливая

Раньше VS больше кушала.

Раньше VS больше кушала.

с решарпером

с решарпером

Я не пользуюсь.

Раньше VS больше кушала.

ну не знаю. наши жабисты больше 1 копии идеи запустить не могли. а студий про три инстанса без проблем ворочалось. года 2 назад еще

ну не знаю. наши жабисты больше 1 копии идеи запустить не могли. а студий про три инстанса без проблем ворочалось. года 2 назад еще

VS2017, F#?

2017 без f#.

или предыдущая. не помню уже

Я в контексте F# сравниваю, его тулинг всегда довольно много кушает. :)

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

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

Открыт маленький солюшн (4 F# проекта, 1 C#), без экстеншнов.

Ну учитывая что в райдере решарпер встроен, то их справедливо будет сравнивать если на студию поставить решарпер

пишет, что не может такой метод найти, хотя другие методы (не реализации интерфейса в этом же классе видит)

this какой тип имеет?

Попробуй скастить к интерфейсу.

This приведи к IMessenger

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

спасибо!

но всё равно это немного странно

А там не работает просто IMessenger<_,_>?

работает

спасибо!

Лучше, наверное, вынести общую реализацию Send из реализации интерфейса.

а какое-то внятное объяснение, почему так и чем это лучше есть? (я про недоступность методов интерфейса без каста)

но всё равно это немного странно

Это нормально) программировать надо на интерфейсах)

а какое-то внятное объяснение, почему так и чем это лучше есть? (я про недоступность методов интерфейса без каста)

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

Лучше, наверное, вынести общую реализацию Send из реализации интерфейса.

type A = let send endpoint msg = ... interface IMessenger<...> with member __.Send endpoint msg = send endpoint msg member __.SendBroadcast msg = send broadcastEndpoint msg @shishkinpavel

да, это понятно

Тайппровайдер для бедных. :) https://marketplace.visualstudio.com/items?itemName=quicktype.quicktype

Тайппровайдер для бедных. :) https://marketplace.visualstudio.com/items?itemName=quicktype.quicktype

А F# нет в списке ?

Надо запилить.

type A = let send endpoint msg = ... interface IMessenger<...> with member __.Send endpoint msg = send endpoint msg member __.SendBroadcast msg = send broadcastEndpoint msg @shishkinpavel

Только там будет не this.send помоему, а просто send

Справедливо.

Сейчас поправлю.