Планы по выпуску GTK+ версии 3

> теперь там все строки -- std::string.

Вот видите - байндинг починили. К gobject как таковому это никак не относится.

> Можно на методы повесить аннотации типа @ConfigurableProperty(propertyName="listen_port", mandatory=true) тип параметра здесь можно взять из непосредственно из метода, чтобы сконвертировать String->int, а потом, после того как инстанциировал класс по имени, запросить все методы с аннотациями и вызвать их с параметрами из конфига.

Чем оно лучше двух методов:

const list<string> &getProperties();

void setProperties(const map<string,string> &)?

Которые определены в интерфейсе?

> пример того как это может пригодится на практике - ну узнаю я, что обьекта 5 методов и их имена,

http://www.linux.org.ru/jump-message.jsp?msgid=2804957&cid=2808098

> ну и накуя мне это надо? :)

http://www.linux.org.ru/jump-message.jsp?msgid=2804957&cid=2806482

>Чем оно лучше двух методов:

const list<string> &getProperties();

void setProperties(const map<string,string> &)?

Которые определены в интерфейсе?

Оно не type-safely -> Строуструп покарает.

Потому что ОО удобнее для тулкитовых библиотек. Общепринят. Если честно - я не вспомню ни одного не-ОО тулкита. В том смысле, что везде есть понятия окна, события - и методы работы с ними. Просто в gtk сделали логическое завершение - вместо неявной системы объектов "structs + functions" использовали законченную ОО модель gobject, используемую всем стеком. Наличие этой модели дает много разных бонусов, build-time & run-time. Вполне логично. Не нравится - не используйте. Кстати, напоминаю, в те дни когда слово GNOME было аббревиатурой, третья буква означала Object.

> Там макросов MS_OBJECT нет :)

Я же говорю - "кривоватый". Не пофиг ли Вам на макросы? в байндинге-то Вы их не увидите.

> Если я сравниваю потребление проца - я результаты сравнения использую сами по себе, не накладывая на результаты сравнения потребления памяти.

Эффективность программы считается по совокупности. Кстати, не верю, что для Вас торможение связанное с работой менеджера памяти является ненаблюдаемым явлением.

Вы, например, можете дать пользователю за них подергать...

> Оно не type-safely -> Строуструп покарает.

Какая разница, с какой стороны линии "ядро-плагин" парсить текст из конфига?

Наблюдаемым. Но явлением второго порядка по важности. Хотя допускаю, что в есть задачи (которых все меньше), когда это важно.

> Потому что ОО удобнее для тулкитовых библиотек. Общепринят. Если честно - я не вспомню ни одного не-ОО тулкита

Tk. Кстати, легко биндится хоть к питону(tkinter), хоть к перлу(perl-tk). И никаких проблем из-за не-объектно-ориентированности.

> Я же говорю - "кривоватый". Не пофиг ли Вам на макросы? в байндинге-то Вы их не увидите.

Я не про макросы, я про наличие навязываемой тулкитом объектной модели. winapi объектную модель не навязывает(а вот дотнет -- навязывает, чем и плох).

> Вазвращаясь к тому что каждый програмист обязан в своей жизни написать парсер конфигов, посмотрим на такой пример:

жуть :) и это называется ООП??? это тот самый пример костылей, который я приводил, по хорошему обьект должен получить конфиг тоже как обьект, и сам вычитать из него данные, например так:

void Object::LoadPrefs( I_Config* inConfig )
{
mPort = inConfig->ReadLong( "/ServerPlugin/Connection/Port" );
...
}

>> Оно не type-safely -> Строуструп покарает.

>Какая разница, с какой стороны линии "ядро-плагин" парсить текст из конфига?

В ядре это можно сделать один раз в одном месте. И надежно, то есть если в конфиге стоит listen_port=abc, то метод setPort(int port) вообще не будет вызван - ошибка будет отловлена выше.

> Наблюдаемым. Но явлением второго порядка по важности.

А я вот всё никак не забуду пляски с ключами жава-машины для того, чтоб подстроиться под поведение менеджера памяти.

> Хотя допускаю, что в есть задачи (которых все меньше), когда это важно.

...которых всё меньше пишут на яве... :)

> Эффективность программы считается по совокупности. Кстати, не верю, что для Вас торможение связанное с работой менеджера памяти является ненаблюдаемым явлением.

Единственным существенным отрицательным моментом автоматического управления памятью является непредсказуемость времени, которое займёт у GC очередная сборка. IIRC, в жабу вставляют рилтаймовый GC с декларированным временем сборки мусора. Смартпойнтеры в плюсах - это тоже элемент автоматического управления памятью, с которой программисты так и не научились работать.

> В ядре это можно сделать один раз в одном месте.

class ConfigParser никто не отменял.

> И надежно, то есть если в конфиге стоит listen_port=abc, то метод setPort(int port) вообще не будет вызван - ошибка будет отловлена выше.

throw ConfigParseException(); тоже никто не отменял. Да и каким умом надо наделить ядро, чтобы оно ещё и проверяло, что 0 < listen_port < 65536 ?

> Tk

И когда это он стал не объектным?

> winapi объектную модель не навязывает

Еще бы - она там такая простая, что ее не надо навязывать.

Поймите, тулкит неизбежно объектен - просто потому что каждый виджет и окно является объектом, и мимо этого не пройти. До тех пор, пока мы живем в парадигме WIMP.

> Вы, например, можете дать пользователю за них подергать...

код программы подергать??? если вы имеете ввиду только gui, то это должно быть прописать как раз в виде GetPluginMenu(), как в моем примере и написано, в остальных случаях при внедрении в основной гуй программы плагин обязан делать это сам( например AddToGui( I_DockFrame inFrame ) и уж никак получение списка методов в основной программе этому не поможет, или что вы имеете в виду?

И проверяло, что текущий пользователь рут, иначе listen_port >= 1024 ;)

> Смартпойнтеры в плюсах - это тоже элемент автоматического управления памятью, с которой программисты так и не научились работать.

Учитывая, что единственное, с чем работает программа -- это память, я приравниваю такое неумение к неумению программировать.

> GetPluginMenu(),

Да, что-то в этом духе. Я уже сказал - все это можно делать руками. Но можно сделать один раз и навсегда - в виде рефлексии.

Кстати, один из удачных, хотя и скромных, примеров рефлексии ИМХО - junit. Там не надо явно указывать функции тестирования. Сам junit посмотрит и запустит.

>> Tk

> И когда это он стал не объектным?

Он родился не объектно-ориентированным. Кстати, Вы ловко подменили "объектно-ориентированный" на "объектный".

>> winapi объектную модель не навязывает

> Еще бы - она там такая простая, что ее не надо навязывать.

Это ей только в плюс.

> Поймите, тулкит неизбежно объектен - просто потому что каждый виджет и окно является объектом, и мимо этого не пройти. До тех пор, пока мы живем в парадигме WIMP.

До тех пор, пока мы _мыслим_ в объектной парадигме. Надо расширить сознание :)

> Но можно сделать один раз и навсегда - в виде рефлексии.

ну и как определить для чего этот метод, для гуи или нет? чтоб сделать такую выборку прийдется руками написать костыль для разбора списка методов - еще один источник неоднозначности и запутывания кода, в моем же примере все разложено по полочкам

>Да и каким умом надо наделить ядро, чтобы оно ещё и проверяло, что 0 < listen_port < 65536 ?

А вот это можно уже и в setPort проверить.

void setPort(int port) { if (port > 0 && port < 65535) { this.port = port; } else { throw new IllegalArgumentException("Illegal port: " + port); } }

Грубая валидация - в ядре, окончательная - в плугине.

>> Ассемблеры предполагают эквивалентное преобразование код=>маш.инструкция (если не заморачиваться с макросами). Им практически неведомо понятие оптимизации.

> В Си это отображение довольно очевидно. Не однозначно, конечно, но на то он и "кроссплатформенный".

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

> Впрочем это чисто моё мнение - хотя я и не одинок в нём 8)

Вас таких мало.

Но мы есть! :) Вообще же, здесь уже говорили, что надо прежде договориться о терминах. Если же в понятие ООП включать всё, до чего кто-либо уже додумался, или, например, наследование толковать всё более расширительно, то всегда найдётся тот, кто и нынешних критиков С++ покритикует за неверное понимание истины. Это и есть максимализм и даже монотеизм :) Может быть, лучше говорить о движении в сторону ООП. Таким образом, возможны языки ООП разных степеней :) Да, и каждый для своей цели. Если же принять, крайнюю точку зрения на единственно верный язык, соответствующий некой крайней концепции и высшей цели, то он всегда окажется неподходящим для цели менее значительной. А говорить, что язык кого-то обманывает? Он же всё-таки не человеческий :)

С уважением, Евгений.

а таки ты согласен, что мой пример лучше и понятнее? :)

> Он родился не объектно-ориентированным.

В Tk кнопки, менюшки и пр. - не объекты? Вы же тем и занимаетесь, что шлете команды объектам - в духе старого доброго смоллтолка.

> Кстати, Вы ловко подменили "объектно-ориентированный" на "объектный".

В данном контексте не вижу принципиальной разницы. Если укажете, буду аккуратнее.

> Это ей только в плюс.

Сомнительно. Некоторые вещи можно было б обобщить, будь там хотя б зачаточная, но прилично оформленная, объектная модель.

> Надо расширить сознание :)

Опять про вещества?;) Предложите что-то лучшее, чем WIMP - и я пойду за Вами;)

>> Да и каким умом надо наделить ядро, чтобы оно ещё и проверяло, что 0 < listen_port < 65536 ?

> А вот это можно уже и в setPort проверить.

Советую уже начать придумывать новый пример, т.к. это не прокатил.

>> А вот это можно уже и в setPort проверить.

>Советую уже начать придумывать новый пример, т.к. это не прокатил.

Слив засчитан.

>> Он родился не объектно-ориентированным.

> В Tk кнопки, менюшки и пр. - не объекты?

Объекты. Но у них нет виртуальных функций, общего предка и т.д.

>> Надо расширить сознание :)

> Опять про вещества?;) Предложите что-то лучшее, чем WIMP - и я пойду за Вами;)

Достаточно воспринимать WIMP не как дерево объектов, унаследованных от SomethingWidget. Например как сюрьективное отображение внутреннего состояния программы на последовательность команд X-протокола.

P.S. Нет, я не употребляю вещества.

> Слив засчитан.

Пример-то твой => и слив твой :)

>> Слив засчитан.

>Пример-то твой => и слив твой :)

То что у тебя в одном cpp файле импортируется и <list> и <map> вообще довольно показательно -> полное отсутствие инженерной культуры.

> как сюрьективное отображение внутреннего состояния программы на последовательность команд X-протокола.

Нет, не так: отображение автоморфизма состояний программы на последовательность команд X-протокола. Ну а автоморфизм задаётся действиями пользователя.

> Объекты. Но у них нет виртуальных функций, общего предка и т.д.

Объектная модель у них "плоская". Тем хуже для них. И для разработчиков.

> Достаточно воспринимать WIMP не как дерево объектов, унаследованных от SomethingWidget.

Очень неудобно. Если они таковы по поведению - почему это не использовать явно? У них много общего!

ЗЫ Про вещества была шутка, ничего личного.

> То что у тебя в одном cpp файле импортируется и <list> и <map> вообще довольно показательно -> полное отсутствие инженерной культуры.

А да, я ж расстрелян за употребление std::* :)

>а таки ты согласен, что мой пример лучше и понятнее? :)

В модуле парсингу в общем делать нечего. Он просто декларирует через аннотации что у него надо сконфигурировать, и все.

При чем тут X протокол? Он же безумно низкоуровневый! Разработчик вообще о нем думать не должен. Лучше уж выучить десяток разных объектных моделей на голом С, чем думать в терминах этого ... протокола. Вы еще предложите пользователям почтовых агентов думать в imap...

> Объектная модель у них "плоская". Тем хуже для них. И для разработчиков.

Разработчики получают как раз простор для своих дел. При желании ООП на без проблем навешивается.

>> Достаточно воспринимать WIMP не как дерево объектов, унаследованных от SomethingWidget.

> Очень неудобно. Если они таковы по поведению - почему это не использовать явно? У них много общего!

"В Microsoft есть большие мыслители. Когда эти мыслители размышляют над проблемами, они находят в них что-то общее. Они смотрят на то, как пользователи посылают друг другу файлы в формате текстовых процессоров, на то, как другие пользователи посылают друг другу электронные таблицы, и замечают общее: посылка файлов. Это первый уровень абстракции. Дальше они поднимаются уровнем выше: пользователи посылают файлы, но и броузер " посылает" запросы на веб страницы. Это всё операции посылки, так что наши мыслители придумывают еще одну, большего радиуса поражения абстракцию, под названием посылка сообщения, но теперь это становится совсем туманным, и теперь никто не понимает, о чем вообще идет речь."(c)J.Spolsky

> ЗЫ Про вещества была шутка, ничего личного.

Я там смайлик недопоставил :)

>> То что у тебя в одном cpp файле импортируется и <list> и <map> вообще довольно показательно -> полное отсутствие инженерной культуры.

>А да, я ж расстрелян за употребление std::* :)

Можно вообще-то вектором ограничиться. Все равно list и map обгоняют vector наачиная с ~1000 элементов [Sutter хз какого года]. Вектор к тому же память меньше фрагментирует.

> При чем тут X протокол? Он же безумно низкоуровневый!

Рассмотрим наше отображение как компизицию "тулкитизирующего" отображения в команды конкретного тулкита и "тулкитного", реализуемого тулкитом. Так лучше?

> Вы еще предложите пользователям почтовых агентов думать в imap...

Разработчики kmail мыслили в абстракциях kio(а именно kio_imap и kio_poh3), в результате я не могу понять, почему у меня kmail не хочет проверять почту на mail.ru, т.к. логов попросту нет. А вот разработчики sylpheed думали в терминах imap, в результате чего их программа работает.

>> В Си это отображение довольно очевидно. Не однозначно, конечно, но на то он и "кроссплатформенный".

> Наверное, всё-таки, если есть неоднозначность - то это не ассемблер,

Я знаю минимум 1 ассемблер, который сам вставляет команды, которых не пишет программист :)

> какими эпитетами его не украшай.

"Кроссплатформенный ассемблер" - это метафора, она не обязана быть математически точной.

> Разработчики получают как раз простор для своих дел.

Не вижу простора в том, что некоторые методы у многих виджетов просто продублированы - вместо того, чтобы сделать их один раз у базового класса. В том, что нельзя передать указатель на базовый класс в функцию. Это все "простор вставлять спицы в колеса".

> При желании ООП на без проблем навешивается.

Зачем навешивать ООП на то, что гораздо проще и ЕСТЕСТВЕННЕЙ построить как ООП?

> придумывают еще одну, большего радиуса поражения абстракцию

Дада, про "архитекторов-космонавтов" все читали. Из того, что обобщая можно дойти до бессмыслицы - выводим мысль о вреде обобщения как такового?

> В модуле парсингу в общем делать нечего. Он просто декларирует через аннотации что у него надо сконфигурировать, и все.

а в модуле парсинга и нет - он есть в обьекте основной программы, причем в своей программе я ввел кеширование данных, чтоб не было лишних чтений/записей на жесткий( без отдельного обьекта конфига это был бы отдельный геморрой ), причем чтоб поменять сохранение из локального файла на сохранение в архив или по ftp достаточно поменять одну строку - потому что конструктор конфига получает поток, а не путь, и если я захочу реализвать сохранение в xml, к примеру, мне достаточно будет написать новый класс наследованный от I_Config и просто подставить его вместо старого в одном только месте - остальной код вообще не изменится, в этом и есть плюс ООП

> компизицию "тулкитизирующего" отображения в команды конкретного тулкита и "тулкитного", реализуемого тулкитом. Так лучше?

"Извините, доктор, Вы меня теряете." (с) Пациент. Как-то не сильно лучше. Вы допускаете, что одни и те же команды применимым к нескольким виджетам тулкита, без разбору? Если да - вот Вам материал для базового виджета (вероятно, абстрактного).

> в результате я не могу понять,

Переносить проблемы конкретного реализации на проблемы подхода - довольно дешевый прием в дискуссии. Пользователь вообще не должен думать про imap/kio/... И программист - про X protocol, если ему специально не нужно.

> То что у тебя в одном cpp файле импортируется и <list> и <map> вообще довольно показательно -> полное отсутствие инженерной культуры.

Фигассе понятия об инженерной культуре.

> Не вижу простора

А он есть!

>> При желании ООП на без проблем навешивается.

> Зачем навешивать ООП на то, что гораздо проще и ЕСТЕСТВЕННЕЙ построить как ООП?

Затем, чтобы не навешивать ненужного. Просто из принципа минимальности :)

Кстати, какую именно объектную модель навесить по умолчанию? В tcl их как минимум три, на любой вкус.

> Из того, что обобщая можно дойти до бессмыслицы - выводим мысль о вреде обобщения как такового?

Просто надо остановить его в нужном месте. По мне, так достаточно остановиться ещё до того, как постричь все виджеты под общую решётку.

> Затем, чтобы не навешивать ненужного.

Что значит "ненужного"? Общность объектов - это факт из жизни тулкита. Не использовать этот факт для построения базового объекта только потому что у кого-то нелюбовь к ОО - было бы глупо. Не любите ОО - не пользуйте gtk. Будете вне мейнстрима. Соббсно, Вы так и делаете в tklor.

> По мне, так достаточно остановиться ещё до того, как постричь все виджеты под общую решётку.

А по мне - нет. И по разработчикам большинства современных тулкитов - тоже (думаю, спасибо надо сказать мотифцам). А вы остаетесь на обочине исторического процесса. Ну, до тех пор пока очередной виток не сделает так, что Ваша идея "окажется" самой правильной и трушной.

> Вы допускаете, что одни и те же команды применимым к нескольким виджетам тулкита, без разбору? Если да - вот Вам материал для базового виджета (вероятно, абстрактного).

Ну тут преобразование может вполне быть и нетривиальным и необратимым. Т.е. никто не говорит о биекции между виджетами и элементами внутреннего состояния программы.

> Переносить проблемы конкретного реализации на проблемы подхода - довольно дешевый прием в дискуссии.

Это контрпример к "ну не думать же программистам в терминах imap".

> Пользователь вообще не должен думать про imap/kio/... И программист - про X protocol, если ему специально не нужно.

Не надо смешивать пользователя и программиста. Пользователь -- да, не должен знать про imap, а вто программист -- обязан.

Аналогия для x11 -- при вызове fopen() почти никто не думает о том, как представлены данные в файловой системе, хотя там чёрт-ногу-сломит-что происходит.

То есть, в терминах наших отображений, работу по "тулкитному" отображению проводит уже тулкит прозрачно от программиста. И тут опять же биекции между Ximage и TrueToolkitPicture может не быть.

> Общность объектов - это факт из жизни тулкита. Не использовать этот факт для построения базового объекта только потому что у кого-то нелюбовь к ОО - было бы глупо.

man fudgets

>> По мне, так достаточно остановиться ещё до того, как постричь все виджеты под общую решётку.

> А по мне - нет. И по разработчикам большинства современных тулкитов - тоже (думаю, спасибо надо сказать мотифцам).

Снова мы уткнулись в субъективность. На этой прекрасной ноте можно и закруглиться :)

> Ну, до тех пор пока очередной виток не сделает так, что Ваша идея "окажется" самой правильной и трушной.

У меня нет достаточной усидчивости для разработки этой идеи. Так что отпускаю её в свободное плавание.

>> То что у тебя в одном cpp файле импортируется и <list> и <map> вообще довольно показательно -> полное отсутствие инженерной культуры.

>Фигассе понятия об инженерной культуре.

Что проще - добавить 4-8 байтов std::string'а в хвост std::vector или аллоцировать каждый раз мелкий объект для узла list? std::map тоже нужна только если в нее что-то постоянно класть/удалять в режиме 24/7. Проще надо быть, проще.

> Т.е. никто не говорит о биекции между виджетами и элементами внутреннего состояния программы.

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