GIMP Script-Fu ООП. Встраиваем векторы в систему классов Фигур и все Фигуры в язык Функциональной геометрии

Библиотека функций к Script-fu В предыдущей статье мы рассмотрели имеющиеся в GIMP возможности векторной графики. Здесь мы рассмотрим как эти возможности использовать при построении графических примитивов - Фигур. Для построения абстракций фигур мы уже написали несколько классов: Фигуры рисуемых по контуру Кистью и Карандашом, Фигур заполняемых определённым цветом, Комбинированных Фигур, Фигур использующих Изображения и Фигур использующих Текст. Здесь я продемонстрирую, как легко и непринуждённо мы можем встроить новые абстракции в существующую иерарахию классов. А заодно рассмотрим как вся эта иерархия классов может испольоваться в языке функциональной геометрии, рассмотренном в предыдущем цикле статей.

https://habr.com/ru/articles/937886/

#lisp #scheme #gimp #scriptfu #ооп #векторная_графика

GIMP Script-Fu ООП. Векторы

Библиотека функций к Script-fu Когда то, очень давно, считалось что графические редакторы делятся на растровые и векторные. К векторным относились Coreldraw Adobe Illustrator Inkscape и работали они не с отдельными пикселами изображений, а с элементами называемыми векторами, которые можно превращать, с помощью манипуляций в дуги различной формы, называемыми кривыми Безье. К растровым же относились Photoshop Paint и тот же GIMP. В этих редакторах отсутствовала какая либо геометрия и изображения представляли собой наборы отдельных точек - пикселов. Но время не стоит на месте и элементы растрового редактирования проникали в редакторы, которые считались векторными и наоборот, элементы векторных редакторов переносились в растровые графические редакторы. Примером тому является GIMP. Представление о том, что GIMP то растровый графический редактор давно уже устарело. Текстовый слой, да и вся работа со шрифтами в GIMPе это работа с векторными объектами представляющими собой кривые Безье. Таким образом целые текстовые слои в GIMP представляют собой векторные объекты. По мимо отдельных текстовых слоёв, в каждом изображении GIMP можно создавать отдельные строки и вектора. Вот с ними мы сегодня и разберёмся.

https://habr.com/ru/articles/937152/

#lisp #scheme #scriptfu #gimp #векторная_графика

GIMP Script-Fu ООП. ООП на миксинах или сказ о том: «Да что оно может ваше множественное наследование?»

Библиотека функций к Script-fu Вы любите рефакторинг? Ну вот и я приблизительно так же. Основное правило хорошего программиста, такое: "Работает, НЕ ТРОГАЙ!". Но иногда, в редкие минуты помутнения/вдохновения, возникает желание, или я бы даже сказал зуд, в одном месте, и мы садимся за рабочее место, берём в руки клавиатуру и начинаем "творить шедевры" с чистого листа. Системы подпрограмм для языка функциональной геометрии я писал три раза: сначала в функциональном стиле(и в этом то месте и возник пресловутый "свитчинг по типам", потом в стиле примитивных объектов, который не имел наследования, но я придумав хак с шаблонным использованием кода, значительно сократил его дублирование и теперь, когда я разработал развитую ООП систему, во многом повторяющую функциональность CLOS. И это событие прекрасная причина, чтобы переработать старый ООП код, в новой ОО системе. Чем мы с вами здесь и займёмся.

https://habr.com/ru/articles/936636/

#lisp #scheme #gimp #scriptfu #ооп

GIMP Script-Fu ООП. Обобщённые функции и примитивные типы данных

Библиотека функций к Script-fu Как я ранее уже говорил, обобщённые функции нашей системы производят диспетчеризацию вызовов методов основываясь на типах входящих аргументов. Пока меня устраивала ситуация, что диспетчеризация производится только для классов. Все остальные типы данных не учитывались при диспетчеризации методов. В реально же CLOS возможна диспетчеризация по примитивным типам данных. И вообще для работы обобщённых функций классы не требуются. Можно ли как то реализовать подобное поведение в нашей системе? Решению данного вопроса и посвящена эта статья.

https://habr.com/ru/articles/936210/

#lisp #scheme #gimp #scriptfu #типизация #ооп

GIMP Script-Fu ООП. Небольшой рефакторинг объектной системы. Изюминка всего проекта

Библиотека функций к Script-fu В принципе реализация представленная в файле obj4.scm и описанная ранее, меня вполне устраивала. Я реализовал там всё что хотел от объектной системы: определения классов и обобщённых функций, множественное наследование, статические поля класса. Но вот какое-то маленькое зёрнышко сомнения, мешало мене оставить этот проект. А всё ли я сделал для ускорения работы системы? И дело даже не в том, что какие то нехорошие люди из проекта GIMPа обрезали возможность для Script-fu загружать расширения, что не даёт возможности быстро рассчитать хеш-код символов(а то и вовсе заменить хеш-таблицы сишной реализацией). Нет. Для себя я спокойно перекомпилирую Script-fu и буду пользоваться всеми преимуществами предоставляемыми настоящей tinyscheme. Но что же можно сделать ещё, чтобы улучшить скорость работы ОО системы? А может и не только скорость.

https://habr.com/ru/articles/935292/

#gimp #lisp #scheme #scriptfu #ооп

GIMP Script-Fu ООП. Dot синтаксис и другой синтаксический сахар

Библиотека функций к Script-fu После написания объектной системы для Script-fu я задумался над примерами, на которых хорошо бы было проверить эту систему. Я прошерстил уйму литературы, но хороших примеров использующих все возможности ООП в литературе встречается крайне мало. Ну что толку реализовывать класс List в Лиспе? А класс Stack? Примерами подобных классов пестрят книжки по Си++. Всё было не интересно, но вот я встретил книжку "Теория вычислений для программистов" Тома Стюарта, и вот примеры из неё, написанные на Ruby, показались мне интересными. Да в Ruby нет множественного наследования, но есть возможность создавать миксины, что несколько сглаживает этот недостаток. И вот делая примеры из этой, безусловно замечательной(с точки зрения теории вычислений), книжки я заметил, что мой код получается более длинный чем код Ruby. И это происходит не только из за наличия операторов в Руби. Сами определения классов и методов в Руби получаются компактнее, и требуют меньше кода. Сможем ли мы что нибудь сделать, чтобы "догнать" Руби в "краткости" кода?!

https://habr.com/ru/articles/934894/

#lisp #scheme #gimp #scriptfu #ооп

GIMP Script-Fu ООП. Статические поля класса

Библиотека функций к Script-fu Итак, мы разработали практически полнофункциональную ООП систему для языка tinyscheme, так же работающую в script-fu GIMP. Но гложет меня одна мысль, реализовать поля общие для всех объектов класса. В разных языках они называются по разному, но смысл один, некие значения которые общие для всех объектов одного класса. В принципе как я уже указывал, такие поля реализуются как глобальные переменные, но реализация их в виде подсистемы ООП облегчит управление этими полями и использование их в обобщённых функциях. Тут есть тонкий момент: обобщённая функция может работать не только с объявленными типами параметров, но и с их наследниками. Если мы используем общие поля для класса в виде какой то глобальной переменной, то с этими полями могут работать не только объекты объявленных в параметрах классов, но и их потомки. И по идее методы обобщённой функции должны работать с типами соответствующим типам входных аргументов, а не просто типам объявленных параметров. А работа с глобальной переменной не будет различать одних потомков объявленных параметров метода от других. Во всяком случае такая персонализация работы будет затруднена и должна будет выполняться в ручную.

https://habr.com/ru/articles/934560/

#lisp #scheme #gimp #scriptfu #ооп

GIMP Script-Fu ООП. Тестирование на «РОМБЕ СМЕРТИ»

Библиотека функций к Script-fu Написание кода на Лисп это тестирование, я не знаю(это не значит что их нет, просто я их действительно не знаю) ни одного языка программирования в котором цикл: написание код - проверка(тестирование) был бы таким коротким. Кстати в Script-fu я работаю через буфер обмена, это не удобно! Там есть возможность работать из Емакс, через сервер Scrip-fu, но я эту возможность не использую(приятно видеть консоль), а с обычной схемой или лиспом, работа в передаче кода заключается в нажатии пары клавиш. Лисперы не пишут многостраничные листинги кода, а затем его тестируют, они пишут функцию, выполняют его в интерпретаторе и сразу тестируют. Всё это благодаря наличию в системе REPL. И всё таки не смотря на это настаёт момент, когда требуются отдельные тесты, которые удобно запустить и проверить консистентное состояние программной системы, а то в процессе такого интенсивного создания-тестирования программы всё равно можно что либо опустить, и какая нибудь функциональность да отвалится. В нашем случае(в связи со сложностью функционирования комбинаций методов) потребуются тесты проверяющие корректность функционирования обобщённых функций в объектной системе и, по мимо них, правильность обращения к полям объекта, т. е. правильность создания самих объектов и т.д. Так что эти тесты будут скорее интеграционными, чем юнит-тестами.

https://habr.com/ru/articles/934092/

#lisp #gimp #scriptfu #ооп #тестирование

GIMP Script-Fu ООП. Основной дизайн (аля CLOS)

Библиотека функций к Script-fu Итак, теперь наша система позволяет описывать классы с иерархиями множественного наследования и описывать обобщённые функции(generic function) и они придают динамику, придают жизнь создаваемым в системе объектам. Но так ли хороши описанные нами обобщённые функции? Да с точки зрения широко распространённых("классических") ООП систем, они полностью повторяют функциональность методов объектов. При вызове обобщённой функции, происходит диспетчеризация вызова и выбирается наиболее подходящий по типам аргументов метод обобщённой функции. НО в CLOS это НЕ ТАК!!! Да в простейшем случае это так, НО..! CLOS предоставляет более гибкий способ организации кода, когда выполняемый при вызове обобщённой функции код представляет собой не один метод, а целую группу методов. Причём создаётся эта группа динамически в момент вызова, в зависимости от текущих аргументов обобщённой функции(вернее их типов/классов). А в основе такой организации кода лежит спецификация методов обобщённой функции различными квалификаторами .

https://habr.com/ru/articles/933644/

#gimp #scriptfu #lisp #ооп

GIMP Script-Fu ООП. Обобщённые функции

Библиотека функций к Script-fu Готовя эту статью я интересовался, что там в других языках, что там за "дженерики"? Все языки разбирать не буду, но скажу одно: Generic function использующиеся в ЛИСПе и современые дженерики различаются как НЕБО и ЗЕМЛЯ. За дженерики в современных языках в основном ратуют строго типизированные языки, всем понятно, что писать кучу однотипного кода просто глупо. Не скажу точно, кто стоит у истоков современных "дженериков", но пожалуй одним из ранних их проявлений это ШАБЛОНЫ в С++. Почему все остальные языки типа явы и ей подобных, решили назвать свои шаблоны дженериками мне не понятно. (у меня есть язвительное замечание, что хотели как в лиспе, но получилось как всегда). Но дело в том что в ПОДОБНЫХ дженериках языки с динамической типизацией просто не нуждаются. Функция list работает с любыми типами данных, ШАБЛОНЫ не нужны! А в С++ именно контейнеры стали основной побудительной силой использования дженериков, это просто хранилища которые хранят значения, если Си мы можем обойтись (void *) и потом привести тип к нужному, то С++ решил пойти по типобезопасному пути, ну немного "потолстев" в коде. Ну а что же там у современных его последователей? Рассмотрим Go. Пытаясь избавиться от типа, вводят обобщённую переменную T, но понимая, что сделать то с ней ничего нельзя(кроме как хранить и выдать обратно), пытаются как то её ТИПИЗИРОВАТЬ!!! Вводят КОНТРАКТ! А что делать когда в функции надо будет делать сложение? Надо будет к этому контракту добавить ещё контракт аддитиве? а умножение? или ещё что то? в любом случае код функции БЕДЕН! именно в силу того что мы не знаем что может прилететь нам в типе Т. Я вам расскжу что такое НАСТОЯЩИЕ ДЖЕНЕРИКИ.

https://habr.com/ru/articles/933466/

#ооп #generics #generic #lisp #scheme #gimp #scriptfu