real tech inheritance

[escaton]

Из-за _copyAnd красивое решение не придумалось, так что насчет вот такого:

module.exports = require('someTech').buildFlow()
    .builder(function() {
        return this.__base.apply(this, arguments);
    })
    .methods({
        append: function() {
            return this.__base.apply(this, arguments)
        }
    })
    .createTech(require('someTech'));

?

UPD
таки придумалось, в конце не надо снова прокидывать ту же технологию.

[escaton]

cc @blond
Код выглядел так, будето наследование намеренно хотели запретить. Может что-то ломается? Проверял на сборке совего проекта, вроде все ок.

[blond]

Привет!

Код выглядел так, будето наследование намеренно хотели запретить. Может что-то ломается? Проверял на сборке совего проекта, вроде все ок.

Мне кажется, что это могло быть сделано для builder из-за работы с кешом.

Причин для того, чтобы запрещать __base для обычных методов я не вижу.

@mdevils, не вспомнишь, было ли это сделано специально, и если да, то для чего?

[escaton]

Все-таки прокидываю inheritTech через все copy так что в конец не надо добавлять .createTech(require('someTech'));

[escaton]

Если что, отдельно builder можно не наследовать. Вообще, кажется, build-flow можно хорошо порефачить и сделать проще. Осталось только понять, зачем на каждый чейнинг нужно создавать копию?

[mdevils]

Копирование было сделано для того, чтобы можно было создавать новые технологии конфигурированием существующих. Вот пример: https://github.com/enb-make/enb/blob/master/techs/css-ie6.js

[escaton]

@mdevils если в коде этого pr убрать копирование build-flow, вроде не должно ничего сломаться?

[mdevils]

Все должно сломаться.

Копирование — это и есть механизм наследования. Он просто был не доделан (нельзя было вызвать __base).

[escaton]

а зачем копировать до вызова createTech ? Ведь в нем все равно есть вызов inherit? Соответственно если в buildFlow поменять base-tech на текущую, наследование произойдет от нее?

[mdevils]

Хм, до вызова, наверное, незачем. Можете попробовать выпилить.

[blond]

Я попробую написать тесты (#231) на базовую функциональность build-flow, а так же на механизмы наследования и кэширования, т.к. они задеваются в данном PR.

Считаю, что вливать PR без таких тестов довольно опасно.

[blond]

@escaton, начал писать тесты — #234.

За статусом можно следить по мета задаче — #231.

[blond]

Я закончил писать тесты на build-flow: https://github.com/enb-make/enb/blob/master/test/lib/build-flow.js.

@escaton, можешь разбить PR на подзадачи или сформулировать задачу, которую тебе необходимо сделать, и прислать PR с тестами?

Написать тесты по аналогии с существующими должно быть не сложно. Если будут возникать проблемы — я буду помогать.

[blond]

@escaton, проблема ещё актуальна?

[blond]

@escaton, ping!

[blond]

@escaton, ping!

[escaton]

@blond сорри, вот из отпуска вернулся.
Разбивать этот PR на подзадачи мне кажется не нужно, тут только один реквест — реализовать вызов __base

[blond]

@escaton, извини был немного занят

Можешь отребейзить PR и добавить к нему тестов?

[blond]

Closed in favor of #422.