Здравствуйте, Ночной Смотрящий, Вы писали:

V>>В том дизайне приватное поле только одно
НС>Одно не считается?

Сужает сценарии до вызова публичных методов того объекта.
Причём, о реализации интерфейса там речи нет, т.е. нет непреодолимого требования инкапсуляции.

OCP не только запрещает изменение уже "готовых" классов, настаивая на альтернативе — их расширении.
Оно прямо поощряет такой подход, в т.ч. с помощью внешних ф-ий.


V>>, всё вместе выглядит как фасад над объектом, который уже обладает нужной функциональностью.
НС>Как слой абстракции.

Где не происходит оперирования абстрактными типами (т.е. семейством их реализаций).

Я хорошо понимаю эти рассуждения, поэтому и начал с contra, т.е. с недостатков лишних слоёв абстракций в донете.

Есть и еще соображения — вся библиотека не выглядит как предназначенная для новичков, которым на месяц-другой дают вылизывать одну GUI-форму или код серверной веб-страницы. Библиотека выглядит как хелпер для фремворковых (ядерных) разработчиков, которые окучивают инфраструктурные и логические слои проектов.

При таких раскладах открывать подробности реализации бывает даже полезно — ведь проект открыт для доработок.
Например, та подробность, что асинхронный мьютекс выполнен поверх слим-семафора является своеобразным TODO для любого использующего библиотеку или просто любопытствующего. Заметь, как резко скакнул дотнет (Core) в кач-ве реализаций инфраструктурных типов после открытия исходников сообществу.
Пару вещей и я туда постил и они вошли в релизы (исправление документации над семейством Vector<N> и решение бага с оптимизацией локальных полей в компиляторе).


НС>2) Текущий дизайн, возможно, тоже не идеален. И тут довольно странно переключать акцент на мою личность и мое мнение, потому что этот код писал не я.

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


НС>3) Дизайн в виде extension-методов к SemaphoreSlim точно неудачный, потому что попытка заменить семафор на какую то другую реализацию приведет к полностью разломанной совместимости.

Предлагалось для всех этих структур создать единый публичный АПИ, в т.ч. не было бы проблем, если у одних методов этот АПИ был в виде методов-расширений, а у других через экземплярные методы. В таком случае в использующем коде (которого много) на уровне исходников ничего не изменилось бы, если тип переменной-"мьютекса" был бы изменён для некоего объекта (в одном месте). Защищаемых подобными мьютексами объектов обычно очень даже счётное количество в реальных проектах, ведь речь тут о длинных блокировках.

Предложение заменить единственную его реализацию на "пространственную блокировку" тут выглядит даже пугающей — поэтому и напрашивается семейтсво с унифицированным АПИ.

Навскидку, даже для озвученной своей альтернативы слим-семафору было бы неплохо попробовать нарисовать сходу парочку реализаций — простой нерекурсивный такой мьютекс и попробовать реализовать рекурсивный, который будет работать из только пользовательских задач, где задача верхнего уровня выполняеется из шедуллера (т.к. потребует валидный Task.CurrentId).


V>>На досуге нарисую легковесную реализацию и выложу сюда, т.к. судя по активности коллег оно может быть народу полезно.
НС>Проще и удобнее для всех сделать PR в CJ.

Это примерно втрое больший объем работы, включая всеобъемлющие тесты и документирование.
Начну, пожалуй, с того, что пообещал. А остальное будет видно... или у меня, или у кого-то из коллег, реально использующих либу, могут дойти руки.
(я эту CJ не использую, но на самописных легковесных awaitable-объектах съел небольшую собаку, поэтому и высказывался по теме)

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>В том дизайне приватное поле только одно
НС>Одно не считается?

Сужает сценарии до вызова публичных методов того объекта.
Причём, о реализации интерфейса там речи нет, т.е. нет непреодолимого требования инкапсуляции.

OCP не только запрещает изменение уже "готовых" классов, настаивая на альтернативе — их расширении.
Оно прямо поощряет такой подход, в т.ч. с помощью внешних ф-ий.


V>>, всё вместе выглядит как фасад над объектом, который уже обладает нужной функциональностью.
НС>Как слой абстракции.

Где не происходит оперирования абстрактными типами (т.е. семейством их реализаций).

Я хорошо понимаю эти рассуждения, поэтому и начал с contra, т.е. с недостатков лишних слоёв абстракций в донете.

Есть и еще соображения — вся библиотека не выглядит как предназначенная для новичков, которым на месяц-другой дают вылизывать одну GUI-форму или код серверной веб-страницы. Библиотека выглядит как хелпер для фремворковых (ядерных) разработчиков, которые окучивают инфраструктурные и логические слои проектов.

При таких раскладах открывать подробности реализации бывает даже полезно — ведь проект открыт для доработок.
Например, та подробность, что асинхронный мьютекс выполнен поверх слим-семафора является своеобразным TODO для любого использующего библиотеку или просто любопытствующего. Заметь, как резко скакнул дотнет (Core) в кач-ве реализаций инфраструктурных типов после открытия исходников сообществу.
Пару вещей и я туда постил и они вошли в релизы (исправление документации над семейством Vector<N> и решение бага с оптимизацией локальных полей в компиляторе).


НС>2) Текущий дизайн, возможно, тоже не идеален. И тут довольно странно переключать акцент на мою личность и мое мнение, потому что этот код писал не я.

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


НС>3) Дизайн в виде extension-методов к SemaphoreSlim точно неудачный, потому что попытка заменить семафор на какую то другую реализацию приведет к полностью разломанной совместимости.

Предлагалось для всех этих структур создать единый публичный АПИ, в т.ч. не было бы проблем, если у одних методов этот АПИ был в виде методов-расширений, а у других через экземплярные методы. В таком случае в использующем коде (которого много) на уровне исходников ничего не изменилось бы, если тип переменной-"мьютекса" был бы изменён для некоего объекта (в одном месте). Защищаемых подобными мьютексами объектов обычно очень даже счётное количество в реальных проектах, ведь речь тут о длинных блокировках.

Предложение заменить единственную его реализацию на "пространственную блокировку" тут выглядит даже пугающей — поэтому и напрашивается семейтсво с унифицированным АПИ.

Навскидку, даже для озвученной своей альтернативы слим-семафору было бы неплохо попробовать нарисовать сходу парочку реализаций — простой нерекурсивный такой мьютекс и попробовать реализовать рекурсивный, который будет работать только из пользовательских задач, где задача верхнего уровня выполняеется из шедуллера (т.к. потребует валидный Task.CurrentId).


V>>На досуге нарисую легковесную реализацию и выложу сюда, т.к. судя по активности коллег оно может быть народу полезно.
НС>Проще и удобнее для всех сделать PR в CJ.

Это примерно втрое больший объем работы, включая всеобъемлющие тесты и документирование.
Начну, пожалуй, с того, что пообещал. А остальное будет видно... или у меня, или у кого-то из коллег, реально использующих либу, могут дойти руки.
(я эту CJ не использую, но на самописных легковесных awaitable-объектах съел небольшую собаку, поэтому и высказывался по теме)