Добавить методы в О7/13

[kkkk]

Вот ссылка на код еще раз (конкретнее некуда): https://github.com/vladfolts/oberonjs/blob/master/src/type.js

В коде я ничего не понял, но подозреваю, что для этой задачи методы не обязательны. Поскольку все типы известны заранее, достаточно расширения типа и CASE - IF-ELSIF. Это имеется ввиду под ужасом?

[valexey_u]

Вот ссылка на код еще раз (конкретнее некуда): https://github.com/vladfolts/oberonjs/blob/master/src/type.js

В коде я ничего не понял, но подозреваю, что для этой задачи методы не обязательны. Поскольку все типы известны заранее, достаточно расширения типа и CASE - IF-ELSIF. Это имеется ввиду под ужасом?

Насколько я понимаю, что с таким решением ровно одна проблема - при добавлении нового типа можно банально забыть CASE/IF-ELSE поправить и добавить еще один вариант. В случае же интерфейсов тут компилятор стукнет по голове - не реализован обязательный метод.

В принципе, в данном конкретном случае, задача могла бы решиться введением enum-типов с проверкой компилятором наличия всех возможных альтернатив в CASE.

[vlad]

В коде я ничего не понял, но подозреваю, что для этой задачи методы не обязательны. Поскольку все типы известны заранее, достаточно расширения типа и CASE - IF-ELSIF. Это имеется ввиду под ужасом?

Видишь ли, принципиальная проблема в IF/ELSIF в том, что я не помню все ли расширения типа представлены в этом модуле или есть какие-то еще за пределами. Да, и я не хочу искать - есть ли такие. А еще я хочу, чтобы все продолжало работать даже если какие-то расширения появятся в будущем. Может быть я хочу слишком большего... Но с другой стороны - что плохого в таком желании?

P.S. И да, я считаю IF/ELSIF по списку типов недостойным написания/чтения человеком. Ибо мусор, скрывающий суть. Даже если бы не было описанной выше принципиальной проблемы расширения системы.

[ilovb]

Вот ссылка на код еще раз (конкретнее некуда): https://github.com/vladfolts/oberonjs/blob/master/src/type.js

В коде я ничего не понял, но подозреваю, что для этой задачи методы не обязательны. Поскольку все типы известны заранее, достаточно расширения типа и CASE - IF-ELSIF. Это имеется ввиду под ужасом?

Насколько я понимаю, что с таким решением ровно одна проблема - при добавлении нового типа можно банально забыть CASE/IF-ELSE поправить и добавить еще один вариант. В случае же интерфейсов тут компилятор стукнет по голове - не реализован обязательный метод.

В принципе, в данном конкретном случае, задача могла бы решиться введением enum-типов с проверкой компилятором наличия всех возможных альтернатив в CASE.

Вот как раз для этого и нужен HALT в CASE   

[kkkk]

Согласен с предыдущим оратором. По моему опыт отсутствие нужной реализации даже без тестов отыскивается быстро.

[kkkk]

Видишь ли, принципиальная проблема в IF/ELSIF в том, что я не помню все ли расширения типа представлены в этом модуле или есть какие-то еще за пределами. Да, и я не хочу искать - есть ли такие. А еще я хочу, чтобы все продолжало работать даже если какие-то расширения появятся в будущем. Может быть я хочу слишком большего... Но с другой стороны - что плохого в таком желании?

P.S. И да, я считаю IF/ELSIF по списку типов недостойным написания/чтения человеком. Ибо мусор, скрывающий суть. Даже если бы не было описанной выше принципиальной проблемы расширения системы.

Я как раз и говорил о случае, когда все типы известны заранее, соответственно ничего не потеряешь и помнить не надо - написал и дело с концом, как в случае с Обероном. Увы, зачастую только редкие и заранее предусмотренные динамические расширения не требуют дополнительного вмешательства в основной код. По поводу IF/ELSE тоже не стоит быть столь категоричным. Иногда общие части кода как раз и видны в таком виде, да в таких комбинациях, что с ООП там голову сломаешь. Если Вы заранее наметили пути расширения и видите четкий план развития, то вполне возможно интерфейсы и пригодятся в большей степени, чем это видится со стороны.

[vlad]

В принципе, в данном конкретном случае, задача могла бы решиться введением enum-типов с проверкой компилятором наличия всех возможных альтернатив в CASE.

Вот как раз для этого и нужен HALT в CASE   

Ненужен. valexey пишет об ошибке компиляции - я с ним согласен.

[valexey_u]

В принципе, в данном конкретном случае, задача могла бы решиться введением enum-типов с проверкой компилятором наличия всех возможных альтернатив в CASE.

Вот как раз для этого и нужен HALT в CASE   

Ненужен. valexey пишет об ошибке компиляции - я с ним согласен.

Я даже согласен на ошибку исполнения, но только такую которая будет вылетать сразу после загрузки модуля и до использования. Гарантированно будет выскакивать. Эдакий self test. Причем код этого self test'a не должен требовать изменения при добавлении новых типов. Такое вот решение вполне было бы приемлемо, я так делал несколько раз, когда у меня то ли мозгов нехватало на ошибку компиляции, то ли ограничения были какие-то. В результате прога, если допущена ошибка, просто отказывалась запускаться с четким указанием кто тут идиот и где ошибку искать.

А вот надеяться что при тестовых прогонах/запусках которые делает девелопер, будут проверены все ветки (в данном случае это означает, что там будут присутствовать все типы) - очень наивно. Неоднократно в продакшине сталкивались с ситациями когда хитрый пользователь-выдумщик такие входные данные дает, и в таких условиях запускает приложение, каких никогда не было у девелопера на прогонах, и там начинали играть всеми красками те самые, не оттестированные ветки кода.

[vlad]

Я как раз и говорил о случае, когда все типы известны заранее, соответственно ничего не потеряешь и помнить не надо - написал и дело с концом, как в случае с Обероном.

В таком случае лучше иметь CASE по енуму (с проверкой всех альтернатив на этапе компиляции), а не IF/ELSIF по произвольным типам...

Увы, зачастую только редкие и заранее предусмотренные динамические расширения не требуют дополнительного вмешательства в основной код. По поводу IF/ELSE тоже не стоит быть столь категоричным. Иногда общие части кода как раз и видны в таком виде, да в таких комбинациях, что с ООП там голову сломаешь. Если Вы заранее наметили пути расширения и видите четкий план развития, то вполне возможно интерфейсы и пригодятся в большей степени, чем это видится со стороны.

Я не хочу показаться одиозным адептом ООП. Я видел очень много применений механизмов ООП не там где надо (да че там, почти каждый день вижу). И, конечно, я не верю в беспроблемное расширение систем "если заранее все обдумать" (с этим к товарищу Усову). Я всего лишь хочу инструмент, позволяющий быстро и эффективно расширять систему с минимальными регрессионными ошибками и с возможностью легко избавляться от ставших неактуальными кусков. И интерфейс, как декларацию контракта с одной стороны и средство сокрытия реализации с другой - мне заменить нечем. Модули, как я говорил, решают эту же задачу, но статически и крупномасштабно. А очень часто нужна динамика и по месту.

[adva]

Я конечно плохо понял суть разговора. Поэтому такой вопрос: паттерн   DIR разве не решает проблему? В крайнем случае можно написать интерфейсный модуль я думаю даже, на основе нескольких других, используя dir. А его генерацию можно сделать внеязыковыми средствами (просто надо их продумать). Вон в 1С конструктор запросов очень удачно генерит тексты запросов, и с ним удобно работать. В данном случае думаю можно сделать что-либо подобное.

Мне например, на текущий момент вполне хватило бы следующей генерации:

Имеем:

Код: [Выделить]

TYPE
    typ1 = RECORD
END;



[adva]

Отправил раньше, чем надо. Заново теперь :

Я конечно плохо понял суть разговора. Поэтому такой вопрос: паттерн   DIR разве не решает проблему? В крайнем случае можно написать интерфейсный модуль я думаю даже, на основе нескольких других, используя dir. А его генерацию можно сделать внеязыковыми средствами (просто надо их продумать). Вон в 1С конструктор запросов очень удачно генерит тексты запросов, и с ним удобно работать. В данном случае думаю можно сделать что-либо подобное. Тогда ошибки будут сыпаться по прежнему при компиляции

Мне например, на текущий момент вполне хватило бы следующей генерации (тут конечно просто блокнота мало будет, но кто ж их сейчас использует):

Имеем до генерации:

Код: [Выделить]

TYPE
   
    typ1 = RECORD
    END;
   
PROCEDURE typ1Proc1 ();     


Код: [Выделить]

TYPE
   
    typ1 = RECORD
        Proc1: PROCEDURE ()
    END;
   
PROCEDURE typ1Proc1 ();     

Название типа, в процедуре для упрощения (а зачем собственно усложнять , к тому же вложенные процедуры все равно нельзя использовать )

Ну и где-нибудь в комментарии (где тип, или в секции БЕГИН, или еще где), добавить код присвоения (чтобы его потом просто скопировать). Или даже так, стоя на типе, указываем, что надо сгенерить присвоения.

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

[vlad]

Я конечно плохо понял суть разговора. Поэтому такой вопрос: паттерн   DIR разве не решает проблему? В крайнем случае можно написать интерфейсный модуль я думаю даже, на основе нескольких других, используя dir. А его генерацию можно сделать внеязыковыми средствами (просто надо их продумать).

Не очень понимаю, что ты имеешь ввиду под интерфейсным модулем и как это поможет иметь одновременно (в рантайме) множество реализаций (в виде модулей?) нужного интерфейса.

[adva]

В данном случае под интерфейсным модулем я имею в виду сгенеренный автоматом модуль, в котором будут реализованы нужные процедуры и чего там еще нужно из других модулей (просто как их вызов). Думаю так же думаю, и типы можно скомпилировать. Но уже на основе процедур данного модуля. Но для этого нужен какой-то удобный конструктор.

По сути это будет обычный модуль.

Про одновременно множество реализаций ничего сказать не могу.
А как директории динамически подменяются? Это не то, чего в итоге требуется? Зачем множество реализаций? Подменил директорию на нужную, и использовал. Более "внятно" ответить вряд ли смогу, т.к. плохо разбираюсь в вопросе.

[vlad]

Подменил директорию на нужную, и использовал.

Так. Давай по порядку. Что такое "подменил директорию"?

[ilovb]

В принципе, в данном конкретном случае, задача могла бы решиться введением enum-типов с проверкой компилятором наличия всех возможных альтернатив в CASE.

Вот как раз для этого и нужен HALT в CASE   

Ненужен. valexey пишет об ошибке компиляции - я с ним согласен.

А чем конкретно в данном случае ошибка компиляции лучше?
HALT в CASE вылетает в 90 процентах случаев при первом же запуске. (проверено на практике неоднократно) Это на пару секунд позже компиляции. Эти пара секунд так важны?