Closed blond closed 9 years ago
Т.к. решили разбить спецификацию на разделы, неплохо определиться, на какие именно разделы разбивать. От обсуждения хочется получить готовую структуру разделов, которая станет высокоуровневым критерием готовности спеки. Пока писались тесты большим скопом, логическое разделение получилось таким:
Структура выглядит не идеальной, но предлагаю её отправной точкой для обсуждения, что должно войти в спеку в конечном итоге. Как первый и самый очевидный вопрос - нужно ли выделять в отдельную группу ignore tech dependencies when no tech to resolve specified или же добавить это в ignoring tech dependencies ?
@blond напиши пожалуйста, что думаешь.
Поговорили с @blond , решили, что не нужна отдельная категория для тестов, описывающих игнорирование зависимостей для конкретной технологии в случае сборки без указания технологии.
Пока писал тесты для пункта resolve basic dependencies
, сложилось впечатление, что спецификация выходит плохо структурированной. Также на это намекнула путаница с терминологией отсюда: https://github.com/bem-incubator/bem-deps/pull/11#discussion_r33152298
В качестве варианта преодоления этой боли, предлагаю следующее:
weak
strong
strong
и weak
зависимостей. Для каждого класса зависимостей сделать разделы касающиеся:
weak
- weak
, weak
- strong
и strong
- strong
циклов.
Отдельный раздел для описания учёта естественного порядка БЭМ - сущностей.
Возможно добавить отдельный раздел, описывающий игнорирование tech
- зависимостей в определенных случаях.Таким образом предлагаемая новая структура спеки следующая
Input processing
Resolving weak dependencies
weak
entities dependencies - описывает отношения entity - entity для зависимостей без указания порядка следованияweak
tech dependencies - описывает отношения entity <- tech
, tech <- entity
и tech <- tech
для зависимостей без указания порядка следованияweak
tech dependencies recommended ordering - описывается рекомендуемый порядок для зависимостей без указания порядка следованияResolving strong dependencies
strong
entity dependencies - описывает отношения entity - entity для зависимостей с указанием порядка следованияstrong
tech dependencies - описывает отношения entity <- tech
, tech <- entity
и tech <- tech
для зависимостей с указанием порядка следованияstrong
tech dependencies recommended ordering - описывается рекомендуемый порядок для зависимостей с указанием порядка следования (Возможно раздел излишний, тут предполагается показать, что рекомендуемый порядок сохраняется для всего, кроме явно указанного)Resolving dependency cycles
weak - weak
dependency cycles - включает прямые (A <- B <- A), непрямые (A <- B <- C <- A) и циклы внутри цепочек (A <- B <- C <- B) случаи для weak - weak
зависимостей.weak - strong
dependency cycles - включает прямые (A <- B <- A), непрямые (A <- B <- C <- A) и циклы внутри цепочек (A <- B <- C <- B) случаи для weak - strong
зависимостей.strong - strong
dependency cycles - включает прямые (A <- B <- A), непрямые (A <- B <- C <- A) и циклы внутри цепочек (A <- B <- C <- B) случаи для strong - strong
зависимостей.Other
weak
зависимостейIgnoring tech dependencies - описывает случаи, при которых tech
- зависимости могут быть проигнорированы
@blond посмотри пожалуйста, хочется конструктивной критики и, как результат, получить завтра финальный вариант структуры спеки.
Мне в целом всё нравится.
По поводу названий, я всё же за strict
non strict
. У strong
и weak
несколько другая семантика, и мне не нравится, что вводится 2 термина, вместо одного. Кажется, что из-за этого можно перепутать какие зависимости weak
, а какие strong
.
Но, из такой структуры не понятно где будут тесты, которые покажут что строгие зависимости имеют больший приоритет, чем не строгие зависимости, и чам естественный порядок.
Резюме обсуждений голосом, которое может быть интересно всем:
ordered
- зависимость, для которой явно указан порядок следования
* unordered
- зависимость для которой порядок явно не указанОбновил структуру спеки сверху, также переделал все связанные issues.
Write specs for
resolve
method: #2.Input processing
Resolving unordered dependencies
unordered
entities dependencies — #10unordered
tech dependencies — #12unordered
dependencies recommended ordering — #13Resolving ordered dependencies
ordered
entity dependencies — #14ordered
tech dependencies — #15ordered
dependencies recommended ordering — #16Resolving dependency cycles
unordered - unordered
dependency cycles — #17unordered - ordered
dependency cycles — #18ordered - ordered
dependency cycles — #19Other