Открыть список
Как стать автором
Обновить

Комментарии 28

это для метапрограммирования вообще характерно. мы так думаем — поэтому оно проще и наглядней, чем втискивание нестандартной задачи в рамки (будь то императивный код, ООП или еще что)
Доктор, а откуда у вас такие картинки?

(из примера, в смысле).
Картинки из одного из проектов, который у нас в разработке. Это интерактивные детские книжки с анимацией и играми.
Только нужно теперь более простым языком и в примерах все разложить, а то меня уже ругают за сложную лексику.
Я думаю, было бы не плохо если вместо многих страниц с пояснением вы бы сделали демо видео.
Если кто может литературу по этому вопросу насоветовать, то кидайте названия и ссылки, а то обнаружилось, что по этому вопросу очень мало написано. Точнее, по шаблонам, макросам и генерации кода — много чего есть, но интересное же не в этом.
за такой javascript — стрелять.
А что конкретно Вам в нем не нравится?
Действительно, так более доступно для восприятия, но суть то не меняется.
Мои извинения, я сначала было подумал, что Вы имеете что-то против обхода мета-модели и получения из нее параметров поведения. А этого моя гордыня бы не пережила.

Хотя использование эвала может пригодиться даже в этих замках из примера. Представим, что на каждый замок нужно написать свой эффект, тогда этот эффект на js можно поместить в атрибут data-animation- fx и оттуда делать eval. Хотя, если аллергия на эвал, то можно каждый эффект проименовать и писать в атрибут только его имя, это уже на любителя. В других языках я тоже стараюсь без эвала, но на js это как-то естественно.
если у замка будет свой эффект отличный от реализованного во fly,
то не поможет и 'fly("'+Id+'","'+Range+'",'+Duration+',"'+Direction+'")' и все data- атрибуты.
евал не решает эту задачу, метамодель негодная.

ну или делали бы уж сразу пример, демонстрирующий пользу евала и использование кода в метамодели.
Брр, какая-то смесь метапрограммирования, метамоделирования, процесса выполнения программы и облачных вычислений. Всё это хорошо по отдельности, но зачем всё собирать под одну гребёнку?
«Программирование» — означает создание компьютерных программ. «Мета» — означает абстракцию над каким-то набором понятий. Метапрограммирование — это программирование над символами самого языка. Ключевая концепция здесь заключается в том, что вычислитель — это тоже программа.
Тип вычислителя — интерпретатор или компилятор — это ортогональная к метапрограммированию концепция, относящаяся по большей части к реализации.
То же самое с императивностью/декларативностью. Common Lisp включает в себя как императивную парадигму, так и декларативную, в обоих смыслах этого слова. И при этом метапрограммирование может использоваться вместе с любой из них: с императивной и функциональной (т.е. декларативной в первом значении) — это оперирование символами (через quote и eval), в описательной (т.е. декларативной во втором смысле) — это CLOS.
Метаданные — это данные о данных. То, что описывает конкретные значения. Например, названия таблиц в реляционной БД, теги записи в блоге и т.д. Метапрограммирование НЕ относится к метаданным так же, как программирование к данным. В качестве «данных» в метапрограммировании чаще всего выступают символы (хотя это уже некоторое сужение понятия метапрограммирования и более точное название в данном случае — символьное программирование). Есть, правда, пара исключений: например в Clojure любой объект может иметь метаданные, но это уже локальная терминология, которая, тем не менее, не нарушает общую идею — для обычного объекта в Clojure метаданные по сути являются просто дополнительными свойствами.
Метамодель — это, грубо говоря, формальная система для описания некоторых концепций. Она тесно связана с базами знаний и онтологиями и, опять же, опирается на формальный язык, состоящий из символов и правил вывода.
Облачные вычисления, протоколы связи и вообще всё, что связано с физическим местом проведения вычисления к метапрограммирования вообще никакого отношения не имеют. В каком-то конкретном случае — может быть, но в целом — ничего общего.
Согласен со всем кроме «Метапрограммирование НЕ относится к метаданным». Как раз самые интересные решения в метапрограммированим появляются, когда происходит интерпретация метаданных. В ближайшее время опубликую отдельные статьи с примерами и обоснованием.
В данном случае что именно вы подразумеваете под метаданными?
Метаданные это и данные, которые мы получаем из интраспекции (а это напрямую относится к метапрограммированию) и данные, которые мы получаем из модели предметной области, например, вот в примере модель декларативная и мы из нее получаем частоту, амплитуду и направление движения слоев (это тоже чистое метапрограммирование). Еще пример: храним в базе данных служебную таблицу с регулярными выражениями для валидации полей ввода или храним регулярные выражения в комментариях к полям, потом считываем их и используем при построении формы — это прямое применение метаданных в метопрограммировании.
Ну нет, опять не согласен. Метаданные — это по определению данные о данных. Какие данные описывают регулярные выражения? Регэкспы — это вообще часть программы, где бы вы их не хранили: хоть в коде, хоть в БД, хоть в комментариях. Вот считывание комментариев из самой программы — это да, пример метапрограммирования. Именно из самой программы, потому что, например, для компилятора комментарии, выражения, да и вообще всё AST — это всё ещё просто данные, над которыми оперирует программа-компилятор. Важно понимать, что метапрограммирование на одном уровне абстракции (для одной программы) может не являтся метапрограммированием на другом, более высоком уровне (компилятор).

То же самое с примером: декларативная модель, описанная в HTML, подаётся на вход JS скрипту в виде данных, то есть просто в виде набора каких-то сторонних объектов, не имеющих к JS никакого отношения. Сравните с CLOS: вы также описываете модель будущего объекта декларативно, однако делаете это на самом языке и подаёте на вход макроса список символов, то есть элементов самого этого языка.

Судя по всему, вы хотите показать что-то вроде аннотаций в Java, где сами аннотации являются метаданными по отношению к конструкциям языка, а механизмы рефлексии позволяют получить к ним доступ. Но это всё ещё частный случай, где сходятся метаданные и метапрограммирование. В целом метаданные не ограничиваются аннотациями, а метапрограммирование — рефлексией. И если программа без данных по сути не имеет смысла, то метапрограмма прекрасно может существовать и без метаданных (равно как метаданные без метапрограммы).
Регулярные выражения описывают тип данных для поля базы. Это метаданные о типе поля. Пока они находятся в комментариях к полю, то они хранятся как строка, а при попадании в программу они интерпретируются и начинают влиять, например: на валидацию в формах. Если бы я писал регулярные выражения как комментарий к строковой переменной так: s = "+=10"; // [-+]=?[0-9]*
и потом бы проверял при каждом присвоении значения в s, удовлетворяет ли значение регулярному выражению и если нет, то оставлял бы старое значение. В этом случае Вы бы согласились, что это можно это считать метапрограммированием и метаданными одновременно?

Структура данных в памяти есть частью программы, точно так же, структура данных в БД есть частью информационной системы. Поэтому нет принципиальной разницы где хранить метаданные, в комментариях кода или в комментариях к полям в БД, главное, что они динамически интерпретируются и влияют на ход выполнения программы.

Вот-вот, мета-анотация в Java, пожалуй самый близкий случай. Согласен, это частный случай метапрограммирования, поэтому я и отношу его к гибриду, где пересекаются метаданные и метапрограммирование.
> В этом случае Вы бы согласились, что это можно это считать метапрограммированием и метаданными одновременно?

Месье знает толк в извращениях ;)

> Поэтому нет принципиальной разницы где хранить метаданные, в комментариях кода или в комментариях к полям в БД, главное, что они динамически интерпретируются и влияют на ход выполнения программы.

Во-первых, вы снова смешиваете разные уровни абстракции. Понятия метапрограммирования и метаданных имеют смысл только в каком-то конкретном контексте. Регулярные выражения, описывающие поле, являются метаданными только в контексте самого этого поля. В контексте базы данных (файла на диске, памяти программы, комментария самого по себе — не важно) то же самое регулярное выражение является просто данными. Это именно вопрос разных абстракций над одними и теми же (или пересекающимися) объектами реального мира.
Во-вторых, я и не говорил, что метаданные не могут быть использованы в метапрограммировании. Но точно так же в метапрограммировании могут использоваться строки, переменные, open source и покрышка от колеса. То есть непосредственной связи между метапрограммированием и метаданными нет, и единственная общее у них — это приставка «мета».
Интерпретация того что вы называете «метаданными», как в вашем примере — это называется Data Driven Programming.

Метаданные — это данные о данных. Напирмер, если данные — это картинка, до метаданными будут размер картинки, глубина цвета, формат хранения и т.д. Но никак не направление или частота движения.

Метапрограммирование — это программирование программ :) Когда программы создают сами себя. В вашем примере этого нет, к сожалению.
Понятие Data-driven programming еще не настолько устоялось, чтобы все понимали его одинаково.
Чтобы его проиллюстрировать, обычно приводят пример, что на всход программы идет поток инструкций из заранее определенного набора, например: UP, DOWN, UP, LEFT, DOWN, RIGHT… И мы заранее не знаем, какой эта последовательность будет. Это по сути управление поведением программы с помощью потока данных. Но это же разновидность метапрограммирования.

Что до моего маленького примера — в нем неявно используется eval, функция setInterval вызывает eval для переданной строки с вызовом. И даже в том коде, который предложил наш коллега выше, происходит нечто очень похожее. Разве это не напоминает Вам шаблоны или макросы? А если они относятся к метапрограммированию, то почему бы не относить к нему и этот подход и тот же Data-driven programming.
Размер и глубина цвета для картинки, как метаданные о картинке, ни чем принципиально не отличаются от частоты и направления движения слоя, как метаданные о слое.
принципиальное отличие:

картинка обладает глубиной цвета независимо от того, указан он или нет — это мета данные об уже существующих данных.

а у слоя направление движения не существует, пока не указано — это обычные данные, привязанные к слою. это просто параметры создаваемой скриптом анимации.
метаданными они бы стали, еслибы вы саму анимацию (например, замыкание) передали в другую часть программы вместе с этими параметрами.
Оффтопик —
что подразумевается под «доставкой приложения пользователю»?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.