Библиотека функций к Script-fu

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

Представление о том, что GIMP то растровый графический редактор давно уже устарело. Текстовый слой, да и вся работа со шрифтами в GIMPе это работа с векторными объектами представляющими собой кривые Безье. Таким образом целые текстовые слои в GIMP представляют собой векторные объекты. По мимо отдельных текстовых слоёв, в каждом изображении GIMP можно создавать отдельные строки и вектора. Вот с ними мы сегодня и разберёмся.

Библиотека функций к Script-fu

Вы любите рефакторинг? Ну вот и я приблизительно так же. Основное правило хорошего программиста, такое: «Работает, НЕ ТРОГАЙ!». Но иногда, в редкие минуты помутнения/вдохновения, возникает желание, или я бы даже сказал зуд, в одном месте, и мы садимся за рабочее место, берём в руки клавиатуру и начинаем «творить шедевры» с чистого листа.

Системы подпрограмм для языка функциональной геометрии я писал три раза: сначала в функциональном стиле(и в этом то месте и возник пресловутый «свитчинг по типам», потом в стиле примитивных объектов, который не имел наследования, но я придумав хак с шаблонным использованием кода, значительно сократил его дублирование и теперь, когда я разработал развитую ООП систему, во многом повторяющую функциональность CLOS. И это событие прекрасная причина, чтобы переработать старый ООП код, в новой ОО системе. Чем мы с вами здесь и займёмся.

Библиотека функций к Script-fu

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

Библиотека функций к Script-fu

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

Библиотека функций к Script-fu

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

Библиотека функций к Script-fu

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

Библиотека функций к Script-fu

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

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

Библиотека функций к Script-fu

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

Библиотека функций к Script-fu

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

Рассмотрим Go. Пытаясь избавиться от типа, вводят обобщённую переменную T, но понимая, что сделать то с ней ничего нельзя(кроме как хранить и выдать обратно), пытаются как то её ТИПИЗИРОВАТЬ!!! Вводят КОНТРАКТ! А что делать когда в функции надо будет делать сложение? Надо будет к этому контракту добавить ещё контракт аддитиве? а умножение? или ещё что то? в любом случае код функции БЕДЕН! именно в силу того что мы не знаем что может прилететь нам в типе Т. Я вам расскажу, что такое НАСТОЯЩИЕ ДЖЕНЕРИКИ.

Библиотека функций к Script-fu

Введение.

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

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

С необходимостью введения в язык Script‑fu Объектно‑ориентированного стиля программирования я столкнулся на поздних этапах реализации языка функциональной геометрии. Когда в коде появились «свичи/переключатели» и возможность исполнения кода в зависимости от типа входящих данных. Сам то этот «переключатель» написать не сложно, но в развивающемся проекте, постоянно возникают новые типы, изменяются, от каких то приходится отказываться, а ещё есть вариант создания модульных систем, когда в одном варианте существует один набор типов, а вдругом другой, ну а в третьем третий и т. д. И код этого «переключателя» постоянно приходится переписывать, или прибегать к различным «хакам», модифицирующим код в зависимости от того или иного варианта загрузки.

Когда вы в своём проекте сталкиваетесь с подобными конструкциями это явный признак того что вам необходимы языковые конструкции поддерживающие гибкое поведение кода. В объектно‑ориентированном программировании подобное поведение функций называется полиморфным, а сам принцип позволяющий создавать такие функции полиморфизмом.

Библиотека функций к Script-fu
Язык функциональной геометрии

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

Библиотека функций к Script-fu
Язык функциональной геометрии

Базовым элементом языка функциональной геометрии являются рисунки (picture), это функции которые отображают своё содержимое в предоставляемые им в виде аргументов изображение и рамку. Конечно в базовой документации об изображениях нет речи, но здесь я адаптировал этот язык в реалиям GIMP и включил изображение на котором будет отображаться картинка как часть интерфейса вызова функции. Хотя можно было и выкинуть их из него, создав какой нибудь глобальный контекст, хранящий текущее изображение с которым работает язык, к которому бы обращались все функции, это дело вкуса.

Рисунки мы можем создавать из фигур и изображений, задавая при этом ограничения, границы картинки отображаемые в задаваемую рамку.

Библиотека функций к Script-fu

Создав функции отображения фигур(fig, figs) и изображений(img) в заданные рамки(rect), мы практически подошли к созданию языка функциональной геометрии. Но базовые возможности языка созданного на лекциях SICP, немного отличаются от языка Питера Хендерсона. Дело в том что на лекциях SICP в целях облегчения усвоения материала, лектор упростил возможности отображения изображений в рамку. На лекциях осуществлялось точное отображение, из полных габаритов рисунка в полные габариты рамки. Но язык Питера Хендерсона предусматривает расширенное отображение исходного изображения в предоставленную рамку, т.е. в саму ограничивающую рамку может отображаться только специально выделяемая часть изображения, остальная же часть изображения может размещаться ВНЕ пределов рамки.

Библиотека функций к Script-fu

Реализовав простейшую объектную систему в Scheme полезно было бы продемонстрировать преимущество от её использования. Чем в этой статье мы и займёмся. Демонстрацию проведём на примере абстракции Фигуры, ведь именно при реализации этой абстракции у меня и возникло сожаление об отсутствии ОО средств в Scheme.

На протяжении всей работы по реализации языка функциональной геометрии Эшера Хендерсона мы немного развивали tinyscheme, различными языковыми конструкциями и ни разу у меня не возникало необходимости использовать Объектно-Ориентированный подход, но вот реализовав абстракцию Фигуры, я понял, что языку tinyscheme очень не хватает объектов и полиморфных функций, потому что данная конструкция не позволяет развивать абстракцию фигуры, расширять различные их варианты. Нет расширять и изменять конечно можно, но придётся постоянно её дописывать и изменять.

С этим нужно было что-то делать. И в этой статье речь пойдёт о первой попытке решить проблему отсутствия нормального ООП в tinyscheme.

Библиотека функций к Script-fu

Мы уже использовали контуры, для вычерчивания кривых линий, для формирования выделений, для закрашивания областей изображения. Но абстракция контура охватывает только позиции(точки), которые можно использовать по своему усмотрению. Пора бы создать абстракцию которая бы объединила возможность рисования контура, кисть, цвет, и тип получаемого изображения, будь это фигура или голый контур. Руководствуясь этими соображениями я объединил в структуре фигуры и окружил её набором функций, создающих абстракцию фигуры.

Библиотека функций к Script-fu

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

Да да, опять точки. Я ранее уже рассказывал как построить абстракцию точки. А теперь мы займёмся рисованием точек, выбранными кистями, рассмотрим различие в управлении кистями версий 2.10 и 2.6, ознакомимся с понятием "динамика кисти" и как с ней работать, а так же займёмся рисованием звёзд без градиента и с помощью "псевдо градиента". Поехали.

Библиотека функций к Script-fu

Библиотека функций к Script-fu

Script-fu(Тинисхема) передает параметры в функцию в виде списка и позволяет передавать значения в обязательные именованные параметры, функции с одним параметром принимающим неограниченное количество значений , или функции смешанного типа, с обязательными именованными параметрами и параметром остатком в виде списка.

Но иногда... мы хотим чего-то БОЛЬШЕГО!!!