T
A -> B -> C -> D
это не зависимости а порядок предложенный одним из валидаторов
Size: a a a
2020 October 11
ΑZ
это не зависимости а порядок предложенный одним из валидаторов
ну валидаторы не должны предлагать порядок. Звучит, Как тебе нужно слить все условия в одно
T
Смотря как обходить. Но сложнее, да. Потому я склоняюсь к варианту Алекса больше. У тебя дерево должно строится по одному критерию, а другие критерии уже лишь быть предикатами на вершинах.
если бы был некоторый основной способ сортировки, с локальной приоретизацией потомков, то проблемы бы небыло)
ΑZ
звучит что тебе нужно просто написать
fn merge(a: ValidationCondition, b: ValidationCondition) -> ValidationConditionT
ну валидаторы не должны предлагать порядок. Звучит, Как тебе нужно слить все условия в одно
да, я валидаторами начал называть правила сортировки, сорян. конечно правило сортировки а не валидатор
T
звучит что тебе нужно просто написать
fn merge(a: ValidationCondition, b: ValidationCondition) -> ValidationConditionименно)
T
алекс, ты в ударе сегодня)
ΑZ
я туплю, но в чем сложность? Берешь первое условие
b => c
берешь второе условие c => d
получаешь граф
b => c
берешь второе условие c => d
получаешь граф
ΑZ
Когда валидаторы заканчиваются висящие вершины подсовываешь в начало любой цепочки
ΑZ
Вот так выглядит граф ппосле приенения первого правила
T
вот я тут тоже сейчас пришел к этому, типа правила должны массивы пар зависимостей возвращать, а потом уже из них соберётся граф
T
вопрос в том, можно-ли свести все правила к таким парам
ΑZ
да ты не пары пиши, а граф
ΑZ
графы записыаются в виде или матрицы смешности. или списка рёбер
ΑZ
скорее всего второе тебе будет удобнее
T
ну, пусть несвязный граф
T
те же пары посути
ΑZ
ну, в некотором смысле
T
ну да, я об этом же вроде говорю