Comments 28
Очень изящный пример
Доктор, а откуда у вас такие картинки?
(из примера, в смысле).
(из примера, в смысле).
За этим будущее.
Я думаю, было бы не плохо если вместо многих страниц с пояснением вы бы сделали демо видео.
Если кто может литературу по этому вопросу насоветовать, то кидайте названия и ссылки, а то обнаружилось, что по этому вопросу очень мало написано. Точнее, по шаблонам, макросам и генерации кода — много чего есть, но интересное же не в этом.
за такой javascript — стрелять.
А что конкретно Вам в нем не нравится?
eval вместо замыканий, например так: pastebin.com/69WJ5ds4
Действительно, так более доступно для восприятия, но суть то не меняется.
Мои извинения, я сначала было подумал, что Вы имеете что-то против обхода мета-модели и получения из нее параметров поведения. А этого моя гордыня бы не пережила.
Хотя использование эвала может пригодиться даже в этих замках из примера. Представим, что на каждый замок нужно написать свой эффект, тогда этот эффект на js можно поместить в атрибут data-animation- fx и оттуда делать eval. Хотя, если аллергия на эвал, то можно каждый эффект проименовать и писать в атрибут только его имя, это уже на любителя. В других языках я тоже стараюсь без эвала, но на js это как-то естественно.
Хотя использование эвала может пригодиться даже в этих замках из примера. Представим, что на каждый замок нужно написать свой эффект, тогда этот эффект на js можно поместить в атрибут data-animation- fx и оттуда делать eval. Хотя, если аллергия на эвал, то можно каждый эффект проименовать и писать в атрибут только его имя, это уже на любителя. В других языках я тоже стараюсь без эвала, но на js это как-то естественно.
если у замка будет свой эффект отличный от реализованного во fly,
то не поможет и 'fly("'+Id+'","'+Range+'",'+Duration+',"'+Direction+'")' и все data- атрибуты.
евал не решает эту задачу, метамодель негодная.
ну или делали бы уж сразу пример, демонстрирующий пользу евала и использование кода в метамодели.
то не поможет и 'fly("'+Id+'","'+Range+'",'+Duration+',"'+Direction+'")' и все data- атрибуты.
евал не решает эту задачу, метамодель негодная.
ну или делали бы уж сразу пример, демонстрирующий пользу евала и использование кода в метамодели.
Брр, какая-то смесь метапрограммирования, метамоделирования, процесса выполнения программы и облачных вычислений. Всё это хорошо по отдельности, но зачем всё собирать под одну гребёнку?
«Программирование» — означает создание компьютерных программ. «Мета» — означает абстракцию над каким-то набором понятий. Метапрограммирование — это программирование над символами самого языка. Ключевая концепция здесь заключается в том, что вычислитель — это тоже программа.
Тип вычислителя — интерпретатор или компилятор — это ортогональная к метапрограммированию концепция, относящаяся по большей части к реализации.
То же самое с императивностью/декларативностью. Common Lisp включает в себя как императивную парадигму, так и декларативную, в обоих смыслах этого слова. И при этом метапрограммирование может использоваться вместе с любой из них: с императивной и функциональной (т.е. декларативной в первом значении) — это оперирование символами (через quote и eval), в описательной (т.е. декларативной во втором смысле) — это CLOS.
Метаданные — это данные о данных. То, что описывает конкретные значения. Например, названия таблиц в реляционной БД, теги записи в блоге и т.д. Метапрограммирование НЕ относится к метаданным так же, как программирование к данным. В качестве «данных» в метапрограммировании чаще всего выступают символы (хотя это уже некоторое сужение понятия метапрограммирования и более точное название в данном случае — символьное программирование). Есть, правда, пара исключений: например в Clojure любой объект может иметь метаданные, но это уже локальная терминология, которая, тем не менее, не нарушает общую идею — для обычного объекта в Clojure метаданные по сути являются просто дополнительными свойствами.
Метамодель — это, грубо говоря, формальная система для описания некоторых концепций. Она тесно связана с базами знаний и онтологиями и, опять же, опирается на формальный язык, состоящий из символов и правил вывода.
Облачные вычисления, протоколы связи и вообще всё, что связано с физическим местом проведения вычисления к метапрограммирования вообще никакого отношения не имеют. В каком-то конкретном случае — может быть, но в целом — ничего общего.
«Программирование» — означает создание компьютерных программ. «Мета» — означает абстракцию над каким-то набором понятий. Метапрограммирование — это программирование над символами самого языка. Ключевая концепция здесь заключается в том, что вычислитель — это тоже программа.
Тип вычислителя — интерпретатор или компилятор — это ортогональная к метапрограммированию концепция, относящаяся по большей части к реализации.
То же самое с императивностью/декларативностью. Common Lisp включает в себя как императивную парадигму, так и декларативную, в обоих смыслах этого слова. И при этом метапрограммирование может использоваться вместе с любой из них: с императивной и функциональной (т.е. декларативной в первом значении) — это оперирование символами (через quote и eval), в описательной (т.е. декларативной во втором смысле) — это CLOS.
Метаданные — это данные о данных. То, что описывает конкретные значения. Например, названия таблиц в реляционной БД, теги записи в блоге и т.д. Метапрограммирование НЕ относится к метаданным так же, как программирование к данным. В качестве «данных» в метапрограммировании чаще всего выступают символы (хотя это уже некоторое сужение понятия метапрограммирования и более точное название в данном случае — символьное программирование). Есть, правда, пара исключений: например в Clojure любой объект может иметь метаданные, но это уже локальная терминология, которая, тем не менее, не нарушает общую идею — для обычного объекта в Clojure метаданные по сути являются просто дополнительными свойствами.
Метамодель — это, грубо говоря, формальная система для описания некоторых концепций. Она тесно связана с базами знаний и онтологиями и, опять же, опирается на формальный язык, состоящий из символов и правил вывода.
Облачные вычисления, протоколы связи и вообще всё, что связано с физическим местом проведения вычисления к метапрограммирования вообще никакого отношения не имеют. В каком-то конкретном случае — может быть, но в целом — ничего общего.
Согласен со всем кроме «Метапрограммирование НЕ относится к метаданным». Как раз самые интересные решения в метапрограммированим появляются, когда происходит интерпретация метаданных. В ближайшее время опубликую отдельные статьи с примерами и обоснованием.
В данном случае что именно вы подразумеваете под метаданными?
Метаданные это и данные, которые мы получаем из интраспекции (а это напрямую относится к метапрограммированию) и данные, которые мы получаем из модели предметной области, например, вот в примере модель декларативная и мы из нее получаем частоту, амплитуду и направление движения слоев (это тоже чистое метапрограммирование). Еще пример: храним в базе данных служебную таблицу с регулярными выражениями для валидации полей ввода или храним регулярные выражения в комментариях к полям, потом считываем их и используем при построении формы — это прямое применение метаданных в метопрограммировании.
Ну нет, опять не согласен. Метаданные — это по определению данные о данных. Какие данные описывают регулярные выражения? Регэкспы — это вообще часть программы, где бы вы их не хранили: хоть в коде, хоть в БД, хоть в комментариях. Вот считывание комментариев из самой программы — это да, пример метапрограммирования. Именно из самой программы, потому что, например, для компилятора комментарии, выражения, да и вообще всё AST — это всё ещё просто данные, над которыми оперирует программа-компилятор. Важно понимать, что метапрограммирование на одном уровне абстракции (для одной программы) может не являтся метапрограммированием на другом, более высоком уровне (компилятор).
То же самое с примером: декларативная модель, описанная в HTML, подаётся на вход JS скрипту в виде данных, то есть просто в виде набора каких-то сторонних объектов, не имеющих к JS никакого отношения. Сравните с CLOS: вы также описываете модель будущего объекта декларативно, однако делаете это на самом языке и подаёте на вход макроса список символов, то есть элементов самого этого языка.
Судя по всему, вы хотите показать что-то вроде аннотаций в Java, где сами аннотации являются метаданными по отношению к конструкциям языка, а механизмы рефлексии позволяют получить к ним доступ. Но это всё ещё частный случай, где сходятся метаданные и метапрограммирование. В целом метаданные не ограничиваются аннотациями, а метапрограммирование — рефлексией. И если программа без данных по сути не имеет смысла, то метапрограмма прекрасно может существовать и без метаданных (равно как метаданные без метапрограммы).
То же самое с примером: декларативная модель, описанная в HTML, подаётся на вход JS скрипту в виде данных, то есть просто в виде набора каких-то сторонних объектов, не имеющих к JS никакого отношения. Сравните с CLOS: вы также описываете модель будущего объекта декларативно, однако делаете это на самом языке и подаёте на вход макроса список символов, то есть элементов самого этого языка.
Судя по всему, вы хотите показать что-то вроде аннотаций в Java, где сами аннотации являются метаданными по отношению к конструкциям языка, а механизмы рефлексии позволяют получить к ним доступ. Но это всё ещё частный случай, где сходятся метаданные и метапрограммирование. В целом метаданные не ограничиваются аннотациями, а метапрограммирование — рефлексией. И если программа без данных по сути не имеет смысла, то метапрограмма прекрасно может существовать и без метаданных (равно как метаданные без метапрограммы).
Регулярные выражения описывают тип данных для поля базы. Это метаданные о типе поля. Пока они находятся в комментариях к полю, то они хранятся как строка, а при попадании в программу они интерпретируются и начинают влиять, например: на валидацию в формах. Если бы я писал регулярные выражения как комментарий к строковой переменной так: s = "+=10"; // [-+]=?[0-9]*
и потом бы проверял при каждом присвоении значения в s, удовлетворяет ли значение регулярному выражению и если нет, то оставлял бы старое значение. В этом случае Вы бы согласились, что это можно это считать метапрограммированием и метаданными одновременно?
Структура данных в памяти есть частью программы, точно так же, структура данных в БД есть частью информационной системы. Поэтому нет принципиальной разницы где хранить метаданные, в комментариях кода или в комментариях к полям в БД, главное, что они динамически интерпретируются и влияют на ход выполнения программы.
Вот-вот, мета-анотация в Java, пожалуй самый близкий случай. Согласен, это частный случай метапрограммирования, поэтому я и отношу его к гибриду, где пересекаются метаданные и метапрограммирование.
и потом бы проверял при каждом присвоении значения в s, удовлетворяет ли значение регулярному выражению и если нет, то оставлял бы старое значение. В этом случае Вы бы согласились, что это можно это считать метапрограммированием и метаданными одновременно?
Структура данных в памяти есть частью программы, точно так же, структура данных в БД есть частью информационной системы. Поэтому нет принципиальной разницы где хранить метаданные, в комментариях кода или в комментариях к полям в БД, главное, что они динамически интерпретируются и влияют на ход выполнения программы.
Вот-вот, мета-анотация в Java, пожалуй самый близкий случай. Согласен, это частный случай метапрограммирования, поэтому я и отношу его к гибриду, где пересекаются метаданные и метапрограммирование.
> В этом случае Вы бы согласились, что это можно это считать метапрограммированием и метаданными одновременно?
Месье знает толк в извращениях ;)
> Поэтому нет принципиальной разницы где хранить метаданные, в комментариях кода или в комментариях к полям в БД, главное, что они динамически интерпретируются и влияют на ход выполнения программы.
Во-первых, вы снова смешиваете разные уровни абстракции. Понятия метапрограммирования и метаданных имеют смысл только в каком-то конкретном контексте. Регулярные выражения, описывающие поле, являются метаданными только в контексте самого этого поля. В контексте базы данных (файла на диске, памяти программы, комментария самого по себе — не важно) то же самое регулярное выражение является просто данными. Это именно вопрос разных абстракций над одними и теми же (или пересекающимися) объектами реального мира.
Во-вторых, я и не говорил, что метаданные не могут быть использованы в метапрограммировании. Но точно так же в метапрограммировании могут использоваться строки, переменные, open source и покрышка от колеса. То есть непосредственной связи между метапрограммированием и метаданными нет, и единственная общее у них — это приставка «мета».
Месье знает толк в извращениях ;)
> Поэтому нет принципиальной разницы где хранить метаданные, в комментариях кода или в комментариях к полям в БД, главное, что они динамически интерпретируются и влияют на ход выполнения программы.
Во-первых, вы снова смешиваете разные уровни абстракции. Понятия метапрограммирования и метаданных имеют смысл только в каком-то конкретном контексте. Регулярные выражения, описывающие поле, являются метаданными только в контексте самого этого поля. В контексте базы данных (файла на диске, памяти программы, комментария самого по себе — не важно) то же самое регулярное выражение является просто данными. Это именно вопрос разных абстракций над одними и теми же (или пересекающимися) объектами реального мира.
Во-вторых, я и не говорил, что метаданные не могут быть использованы в метапрограммировании. Но точно так же в метапрограммировании могут использоваться строки, переменные, open source и покрышка от колеса. То есть непосредственной связи между метапрограммированием и метаданными нет, и единственная общее у них — это приставка «мета».
Интерпретация того что вы называете «метаданными», как в вашем примере — это называется Data Driven Programming.
Метаданные — это данные о данных. Напирмер, если данные — это картинка, до метаданными будут размер картинки, глубина цвета, формат хранения и т.д. Но никак не направление или частота движения.
Метапрограммирование — это программирование программ :) Когда программы создают сами себя. В вашем примере этого нет, к сожалению.
Метаданные — это данные о данных. Напирмер, если данные — это картинка, до метаданными будут размер картинки, глубина цвета, формат хранения и т.д. Но никак не направление или частота движения.
Метапрограммирование — это программирование программ :) Когда программы создают сами себя. В вашем примере этого нет, к сожалению.
Понятие Data-driven programming еще не настолько устоялось, чтобы все понимали его одинаково.
Чтобы его проиллюстрировать, обычно приводят пример, что на всход программы идет поток инструкций из заранее определенного набора, например: UP, DOWN, UP, LEFT, DOWN, RIGHT… И мы заранее не знаем, какой эта последовательность будет. Это по сути управление поведением программы с помощью потока данных. Но это же разновидность метапрограммирования.
Что до моего маленького примера — в нем неявно используется eval, функция setInterval вызывает eval для переданной строки с вызовом. И даже в том коде, который предложил наш коллега выше, происходит нечто очень похожее. Разве это не напоминает Вам шаблоны или макросы? А если они относятся к метапрограммированию, то почему бы не относить к нему и этот подход и тот же Data-driven programming.
Чтобы его проиллюстрировать, обычно приводят пример, что на всход программы идет поток инструкций из заранее определенного набора, например: UP, DOWN, UP, LEFT, DOWN, RIGHT… И мы заранее не знаем, какой эта последовательность будет. Это по сути управление поведением программы с помощью потока данных. Но это же разновидность метапрограммирования.
Что до моего маленького примера — в нем неявно используется eval, функция setInterval вызывает eval для переданной строки с вызовом. И даже в том коде, который предложил наш коллега выше, происходит нечто очень похожее. Разве это не напоминает Вам шаблоны или макросы? А если они относятся к метапрограммированию, то почему бы не относить к нему и этот подход и тот же Data-driven programming.
Размер и глубина цвета для картинки, как метаданные о картинке, ни чем принципиально не отличаются от частоты и направления движения слоя, как метаданные о слое.
принципиальное отличие:
картинка обладает глубиной цвета независимо от того, указан он или нет — это мета данные об уже существующих данных.
а у слоя направление движения не существует, пока не указано — это обычные данные, привязанные к слою. это просто параметры создаваемой скриптом анимации.
метаданными они бы стали, еслибы вы саму анимацию (например, замыкание) передали в другую часть программы вместе с этими параметрами.
картинка обладает глубиной цвета независимо от того, указан он или нет — это мета данные об уже существующих данных.
а у слоя направление движения не существует, пока не указано — это обычные данные, привязанные к слою. это просто параметры создаваемой скриптом анимации.
метаданными они бы стали, еслибы вы саму анимацию (например, замыкание) передали в другую часть программы вместе с этими параметрами.
Оффтопик —
что подразумевается под «доставкой приложения пользователю»?
что подразумевается под «доставкой приложения пользователю»?
Видимо, чтобы приложение доставляло пользователю.
Спасибо автору. Видно, что много работы проделано. По теме Фабрики разработки прогам, Порождающее программирование
Sign up to leave a comment.
Метапрограммирование