Предложения для причесывания ОСи.

[Чуйкин Андрей]

Привет.

Раз пошла такая пьянка чистка, то есть предложение послать гонца сделать следующее:

1. Переименовать пространство имен 'usr' в 'details' (ну и файлы userlib соответственно). 

Ведь по факту, все что там находится - это детали реализации сервисов. Эти детали не требуют публикации их API. Это меньше забивает голову ненужной информацией новому пользователю, а старый пользователь без проблем может использовать классы из этого пространства, понимая, что это именно 'детали' и они могут когда-либо поменяться. Меня, например, вначале имя usr ввело в небольшое заблуждение.

2. Добавить рекурсивный мьютекс.

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

[Harry Zhurov]

08.10.2015 12:50, Чуйкин Андрей пишет:

> 1. Переименовать пространство имен 'usr' в 'details' (ну и файлы
> userlib соответственно). Ведь по факту, все что там находится - это
> детали реализации сервисов. Эти детали не требуют публикации их API.
> Это меньше забивает голову ненужной информацией новому пользователю,
> а старый пользователь без проблем может использовать классы из этого
> пространства, понимая, что это именно 'детали' и они могут когда-либо
> поменяться. Меня, например, вначале имя usr ввело в небольшое
> заблуждение.

За usr не стою, не нравится имя, можно переименовать, хотя это потянет
уже несоместимость на уровне исходников, а не только на уровне
организации проекта, что, на мой взгляд, заметно тяжелее - т.к. это уже
API.

Имя details мне не нравится. Оно ни о чём. Если уж хочется отразить
названием суть, то тогда что-то вроде oslib - библиотека ОС.

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

Это можно. Но я бы это делал в виде расширения. Заодно и посмотрим, как
оно получается.

P.S. На данном этапе переезд на гитхаб почти закончен, проект самой ОС и
проекты примеров перекомпонованы, доведены до собираемости. Созданы
репозитории на гитхабе. Ещё чуть-чуть (полагаю, начало следющей недели)
и можно пробовать продолжать работу в боевом режиме.

--
HZ

[Чуйкин Андрей]

Привет.

Имя detail используется многими проектами и во многих книгах. Встречая его, однозначно понимаешь, что за ним находится. В том смысле какого рода код находится в namespace detail.

usr в oslib вроде как шило на мыло. Раз detail не нравится, то трогать не будем.

А мьютекс добавлю как только правила работы будут определены.

четверг, 8 октября 2015 г., 15:15:42 UTC+6 пользователь Harry Zhurov написал:

[Anton Gusev]

Чуйкин Андрей пишет 12.10.2015 13:33:

> Привет.
>
> Имя detail используется многими проектами и во многих книгах.

Имхо, detail (как и private) - это для внутренних деталей реализации. А
в userlib - вполне себе полезная для самостоятельного использования либа.

[Чуйкин Андрей]

Когда происходят какие-либо изменения в scmRTOS, я всегда смотрю на это с точки зрения пользователя, только только собирающегося ее использовать. Который в свободное время просматривает доки и исходники. Формирует, так сказать, модель ОСи у себя в голове.

С этой точки зрения, любая лишняя информация не по делу, замыливает взгляд и мысли. А наличие публичной usrlib - это как раз лишняя для новичка информация. Тем более, что весь состав usrlib - это только класс FIFO. Думаю не ошибусь, что у каждого программиста уже есть реализация FIFO, которую он давно и успешно использует. И предпочесть реализацию из нутра ОСи своей ...

Мне кажется, с точки зрения новичка, usrlib - это деталь реализации.

12 октября 2015 г., 14:47 пользователь Anton Gusev <anto...@mail.ru> написал:

--
--
Страница группы -- http://groups.google.com/group/scmrtos-ru
--- Вы получили это сообщение, так как подписаны на группу "scmrtos-ru".
Чтобы отменить подписку на эту тему, перейдите по ссылке https://groups.google.com/d/topic/scmrtos-ru/-3NThV-8sto/unsubscribe.
Чтобы отменить подписку на эту группу и все ее темы, отправьте письмо на электронный адрес scmrtos-ru+...@googlegroups.com.

Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--

_________________________

С уважением, Андрей Чуйкин.

ООО "Термэкс", г. Томск.

(3822) 49-28-91

chuykin.termex@gmail.com

http://termexlab.ru

[Harry Zhurov]

12.10.2015 14:33, Чуйкин Андрей пишет:

> Имя detail используется многими проектами и во многих книгах.
> Встречая его, однозначно понимаешь, что за ним находится. В том
> смысле какого рода код находится в namespace detail.

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

Кстати, в stl есть хорошая реализация этой вещи (std::queue), но stl
требует аллокации, что тащит за собой работу со свободной памятью, а это
не радует. Можно или нет написать свой аллокатор, который будет
размещать объект статически, не знаю, на это моих умений на данный
момент не хватает. А вообще, цель более, чем достойная: убрать этот
кольцевой буфер и заменить его стандартным.

>
> usr в oslib вроде как шило на мыло. Раз detail не нравится, то
> трогать не будем.

Можно, например, просто сделать lib. Коротко и понятно. Но мне не
нравится изменение API - пользовательский код перестанет
компилироваться. Если бы это несло какую-то новую функциональность,
тогда на это имел бы смысл пойти на это. Будет новая функциональность,
можно будет озаботиться и именами. Имхо.

--
HZ