Specs for Resolve

[blond]

Write specs for resolve method: #2.

Input processing

• [x] input params processing — #7

Resolving unordered dependencies

• [x] unordered entities dependencies — #10
• [x] unordered tech dependencies — #12
• [x] unordered dependencies recommended ordering — #13

Resolving ordered dependencies

• [x] ordered entity dependencies — #14
• [x] ordered tech dependencies — #15
• [x] ordered dependencies recommended ordering — #16

Resolving dependency cycles

• [x] Resolving unordered - unordered dependency cycles — #17
• [x] Resolving unordered - ordered dependency cycles — #18
• [x] Resolving ordered - ordered dependency cycles — #19

Other

• [x] Natural BEM entities ordering — #20
• [x] Ordering priority — #21
• [x] Ignoring tech dependencies — #22

[SwinX]

Т.к. решили разбить спецификацию на разделы, неплохо определиться, на какие именно разделы разбивать. От обсуждения хочется получить готовую структуру разделов, которая станет высокоуровневым критерием готовности спеки. Пока писались тесты большим скопом, логическое разделение получилось таким:

• Input processing
• resolving basic dependencies
• basic dependencies recommended ordering
  • recommended ordering for dependencies of dependencies (???)
• basic dependencies explicit ordering
• dependency cycles
• resolving basic dependencies for specific tech
  • ignore tech dependencies when no tech to resolve specified
• tech dependencies grouping
• tech dependencies recommended ordering
• tech dependencies explicit ordering
• resolving tech <- entity dependencies
• resolving tech <- tech dependencies
• ignoring tech dependencies

Структура выглядит не идеальной, но предлагаю её отправной точкой для обсуждения, что должно войти в спеку в конечном итоге. Как первый и самый очевидный вопрос - нужно ли выделять в отдельную группу ignore tech dependencies when no tech to resolve specified или же добавить это в ignoring tech dependencies ?

@blond напиши пожалуйста, что думаешь.

[SwinX]

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

[SwinX]

Пока писал тесты для пункта resolve basic dependencies, сложилось впечатление, что спецификация выходит плохо структурированной. Также на это намекнула путаница с терминологией отсюда: https://github.com/bem-incubator/bem-deps/pull/11#discussion_r33152298 В качестве варианта преодоления этой боли, предлагаю следующее:

1. Определиться с терминологией. Сейчас есть несколько вариантов, как обозначить зависимости, для которых важен и не важен порядок. Мне кажется, что наилучший вариант такой:
   • Зависимость, для которой указан порядок назвать weak
   • Зависимость, для которой не указан порядок назвать strong
2. Переделать структуру спецификации, отталкиваясь от strong и weak зависимостей. Для каждого класса зависимостей сделать разделы касающиеся:
   • зависимостей вне контекста технологий
   • зависимостей в контексте технологии
   • рекомендуемого порядка для этих зависимостей Отдельным разделом вынести разрешение циклических зависимостей с подразделами касающимися weak - weak, weak - strong и strong - strong циклов. Отдельный раздел для описания учёта естественного порядка БЭМ - сущностей. Возможно добавить отдельный раздел, описывающий игнорирование tech - зависимостей в определенных случаях.

Таким образом предлагаемая новая структура спеки следующая

Input processing

• input params processing - описание входных параметров resolve

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

• Resolving weak - weak dependency cycles - включает прямые (A <- B <- A), непрямые (A <- B <- C <- A) и циклы внутри цепочек (A <- B <- C <- B) случаи для weak - weak зависимостей.
• Resolving weak - strong dependency cycles - включает прямые (A <- B <- A), непрямые (A <- B <- C <- A) и циклы внутри цепочек (A <- B <- C <- B) случаи для weak - strong зависимостей.
• Resolving strong - strong dependency cycles - включает прямые (A <- B <- A), непрямые (A <- B <- C <- A) и циклы внутри цепочек (A <- B <- C <- B) случаи для strong - strong зависимостей.

Other

• Natural BEM entities ordering - описывает применение естественного порядка следования БЭМ - элементов (1й - Блок, 2й - Элемент, 3й - модификатор) для weak зависимостей

• Ignoring tech dependencies - описывает случаи, при которых tech - зависимости могут быть проигнорированы

  @blond посмотри пожалуйста, хочется конструктивной критики и, как результат, получить завтра финальный вариант структуры спеки.

[blond]

Мне в целом всё нравится.

По поводу названий, я всё же за strict non strict. У strong и weak несколько другая семантика, и мне не нравится, что вводится 2 термина, вместо одного. Кажется, что из-за этого можно перепутать какие зависимости weak, а какие strong.

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

[SwinX]

Резюме обсуждений голосом, которое может быть интересно всем:

1. Кажется нашли подходящие термины для упорядоченных и неупорядоченных зависимостей: * ordered - зависимость, для которой явно указан порядок следования * unordered - зависимость для которой порядок явно не указан
2. Обговорили новую структуру спеки. Добавился новый пункт, описывающий приоритет упорядочивания зависимостей: ordering priority.
3. Новая структура признана жизнеспособной, решили её пока заморозить и реализовать. В дальнейшем - уже исправлять то, то получится.

[SwinX]

Обновил структуру спеки сверху, также переделал все связанные issues.