среда, 8 декабря 2010 г.

Long live Common Lisp

У ANSI CL, типа, 18-го декабря - юбилей, поэтому лисперы по всей планете отмечают праздник, клепая мегакод. Я следующую фигню решал.

Дано описание железки в терминах DSL: какие в коробке есть платы,  что за гейтвари крутятся на FPGA, какие там ядра зашиты, где они находятся, что из себя представляют, etc. Надо: сделать веб-интерфейс для просмотра, редактирования конфигурации и мониторинга железки. DSL проектировался без учёта того, что какой-то там веб ещё должен быть.

Сколько усилий потребовалось, чтобы в браузере начать мышкой тыкать? Всего лишь добавить в макрос-генератор классов опцию :metaclass и указать метакласс от фреймворка, на котором крутится cl-user.net. Причём, приукрашательства ситуации, практически, нет (ну глюк нашёл, initarg у слотов по пути съедался, делов-то). Фреймворк сам траверсит объекты и их иерархию, используя метаобъектный протокол, и рисует умолчательные формы. Мне ничего дополнительного писать не пришлось, фреймворк даже юзает стандартные мои акцессоры для чтения регистров ядер с железки по сети.

То есть, что получается: к обыкновенному объектному коду можно привешивать метаклассы и получить автоматически интеграцию с веб-фреймворком, который о сути подсовываемых ему объектов ничего, собственно, и не знает. С другой стороны, в метакласс можно прикрутить такие мощные вещи, как персистентность объектов или чёрта с рогами, и мой DSL'ный код никаких изменений не потребует.

Собственно, персистентность там уже есть, а также присутствует проксирование, когда начинка объектов валяется где-нибудь на другой машине, а локально от объекта есть только шкурка.

И, да, ни строчки HTML.

8 комментариев:

  1. Кстати про подход добавления функциональности через метаклассы. Я правильно понимаю что если мы например уже реализовали персистентность через метакласс (например использовали для этого cl-perec или elephant или rucksack) то использовать данный фреймворк не получится?

    ОтветитьУдалить
  2. В Django это называется "стандартные представления" ))

    ОтветитьУдалить
  3. ln: в конкретном случае может и не получиться (зависит от реализации соответствующих метаклассов (то бишь методов, специализированных на них)), но в принципе никаких преград нет - просто нужно создать свой метакласс, наследующий от всех нужных метаклассов.

    ОтветитьУдалить
  4. > Я правильно понимаю что если мы например уже реализовали персистентность через метакласс, то использовать данный фреймворк не получится?

    Зависит от метаклассов. С помощью MOP можно стандартный CLOS изменить до полной неузнаваемости, поэтому если каждый метакласс чрезмерно гнёт палку, то может случиться и коллизия.

    ОтветитьУдалить
  5. А что за юбилей-то? Изнасиловал Гугл уже, и нихрена. :)

    ОтветитьУдалить

Архив блога