LINUX.ORG.RU

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

 


1

0

В списке рассылки gtk-devel-list обсуждаются планы выпуска GTK+ версии 3. Основные подготовительные действия, которые необходимо предпринять в текущей ветке:

  • Спрятать все открытые поля структур с помощью макроса GSEAL(). В случае необходимости предоставить новые методы доступа к этим полям. Также должны быть скрыты поля-указатели "priv" на структуры, содержащие закрытые данные. Эти действия уже практически полностью проведены в репозитории git://git.imendio.com/projects/gtk+.git
  • Реализовать закрытые члены класса, что включает изменения в коде GType.
  • Объявить как deprecated публичные данные класса с помощью макроса GSEAL().
  • Поскольку не останется простого способа для доступа к полям класса, а использование g_object_[sg]et() утомительно, необходимо ввести новые методы доступа, вроде g_object_get_int(), *double(), *string() и т.д.
  • Существует множество макросов, таких как GTK_WIDGET_GET_FLAGS(), которые всегда были причиной многочисленных проблем (см. bug #69872). Необходимо реализовать нормальные методы доступа (в виде функций) и избавиться от этих макросов.
  • GtkStyle, без сомнений, самый сложный тип, нуждающийся в скрытии публичных полей, и до релиза должно быть проведено множество исследований.
  • Избавиться от всего кода, объявленного deprecated в 2.x. Это подразумевает все соответствующие виджеты и функции.
  • Удалить все поля структур из публичного API. Есть два способа достичь этого:
    a) переместить все структуры в закрытые заголовки;
    b) переместить структуры в C-файл реализации, но тогда всей библиотеке придётся использовать соответствующие методы доступа.
    Эти варианты ещё обсуждаются.
  • Отключить deprecated-код по умолчанию во флагах компиляции.
Таким образом, версия 3.0 будет готова к релизу. Все приложения, которые собираются для ветки 2.x с макросом GSEAL() и не используют deprecated-кода, будут без проблем собираться для ветки 3.x. Наверное, таким образом разработчики пытаются избежать кошмара миграции, который можно видеть на примере библиотеки Qt.

>>> Подробности

★★★★

Проверено: JB ()

Ответ на: комментарий от naryl

>> Это спровоцирует индокод с обменом текстовыми коммандами между объектами.

>Раздобыл библиотечку для mutiple dispatch. Вот use-case:

>class Foo

Таким образом класс Foo будет раздуваться квадратично. И чтобы добавить поведение для нового типа придется его модифицировать. А полиморфизм был задуман для того чтобы старый код не надо было модифицировать.

Absurd ★★★
()
Ответ на: комментарий от tailgunner

>> класс Foo будет раздуваться квадратично.

>это как?

Как функция y=x^2, где х - количество диспечеризуемых типов.

Absurd ★★★
()
Ответ на: комментарий от tailgunner

> это как?

Ему, наверное, не нравится, что специализированные функции в этом примере являются методами третьего (левого) класса.

mv ★★★★★
()
Ответ на: комментарий от mv

> Ему, наверное, не нравится, что специализированные функции в этом примере являются методами третьего (левого) класса.

Не, на это он пожаловался в "полиморфизм был задуман для того чтобы старый код не надо было модифицировать" :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> Ему, наверное, не нравится, что специализированные функции в этом примере являются методами третьего (левого) класса.

>Не, на это он пожаловался в "полиморфизм был задуман для того чтобы старый код не надо было модифицировать" :)

1) Я не жалуюсь. Я отправляю фтопку. 2) Зачем по Вашему нужен полиморфизм? Чтобы аккуратные программисты могли писать красивый код?

Absurd ★★★
()
Ответ на: комментарий от mv

>Ему, наверное, не нравится, что специализированные функции в этом примере являются методами третьего (левого) класса.

А что, нет? Правила диспетчеризации должны храниться вместе с обработчиками, иначе в проекте появится класс-помойка c эклектичной revision history.

Absurd ★★★
()
Ответ на: комментарий от Absurd

>> Не, на это он пожаловался в "полиморфизм был задуман для того чтобы старый код не надо было модифицировать" :)

> 1) Я не жалуюсь. Я отправляю фтопку

Суров, как всегда. Впрочем, "да никакой разницы" (c)

>>Ему, наверное, не нравится, что специализированные функции в этом примере являются методами третьего (левого) класса.

>А что, нет? Правила диспетчеризации должны храниться вместе с обработчиками

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

tailgunner ★★★★★
()
Ответ на: комментарий от gaa

> Мда... Мы прям дети в сравнении с ними :)

AFAIK рекорд у экстрасенсов, более 3500 сообщений.

anonymous
()
Ответ на: комментарий от Absurd

> А что, нет? Правила диспетчеризации должны храниться вместе с обработчиками, иначе в проекте появится класс-помойка c эклектичной revision history.

С утра трезв, не осилил понять, извини... Так ты за мультиметоды или за мультифункции (по-tailgunner'у)? Я за второе. А ещё за то, чтобы их можно было комбинировать: :before, :after, :around, call-next...

mv ★★★★★
()
Ответ на: комментарий от tailgunner

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

Нелогично. Логично как-то так: void function(virtual& a, virtual&b);

mv ★★★★★
()
Ответ на: комментарий от mv

>Так ты за мультиметоды или за мультифункции (по-tailgunner'у)? Я за второе. А ещё за то, чтобы их можно было комбинировать: :before, :after, :around, call-next...

В терминологии не силен. Я за то чтобы класс Foo не надо было менять при добавлении новых классов и обработчиков их взаимодействия. Возможно, помогли бы аннотации времени компилирования типа "это метод обработки взаимодействия с объектом класса A", так чтобы статический код в классе Foo все эти аннотации находил и склеивал. Слишком усложнять тоже не стоит.

Absurd ★★★
()
Ответ на: комментарий от mv

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

> Нелогично. Логично как-то так: void function(virtual& a, virtual&b);

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Метод по определению описывается в классе (извращения типа динамического добавления не рассматриваем, акторы тоже), поэтому твоя function методом не является :) Я бы назвал это мультифункцией, но тоже не силен в терминологии.

Сам автор C++ про мультиметоды: http://www.research.att.com/~bs/multimethods.pdf

mv ★★★★★
()
Ответ на: комментарий от Absurd

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

mv ★★★★★
()
Ответ на: комментарий от gaa

> Мсье идиот

если ты такой умный, объясни, как пайпы решают задачу совмещения языков? Вот IDL решает. IDL в GTK3 как раз намечается. Когда есть высокоуровневое описание, с него хоть трубы, хоть привязки строгать можно. А когда нету? Если бы с трубами было всё так просто, Trolltech разорились бы, потому что по трубе GPL не передаётся (тот же FUSE эту лазейку эксплуатирует, когда напрямую линковать нельзя)

> Пройдите на виндовс.

на кой мне это старьё

Nihilist
()
Ответ на: комментарий от gaa

> Ты просто не умеешь пользоваться фишками области видимости.

+1

Nihilist
()
Ответ на: комментарий от Absurd

> Ни Си++ надо разрешать кодить только тем кто Си++ терпеть не может.

+1

Nihilist
()
Ответ на: комментарий от tailgunner

> Червячог, рефлексия - вещь полезная. Она не зря включена в CORBA.

Так CORBA -- это не ЯП. В этом-то и фишка! CORBA -- отдельно, ЯП -- отдельно.

Nihilist
()
Ответ на: комментарий от MYMUR

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

избегать C++ /= использовать Java

Nihilist
()
Ответ на: комментарий от Nihilist

> Real-Time Java -- как в анекдоте про морскую свинку

Хорошо тебе иронизировать... а вдруг заставят юзать эту свинку? o_O

tailgunner ★★★★★
()
Ответ на: комментарий от redgremlin

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

... BDS

Это ведь среда располагает достигать целей таким путём

Nihilist
()
Ответ на: комментарий от tailgunner

> Хорошо тебе иронизировать... а вдруг заставят юзать эту свинку? o_O

И что теперь, не иронизировать?

Nihilist
()
Ответ на: комментарий от lester

> я считаю, что ява и с++ очень похожи

Их похожесть заканчивается на синтаксисе. По семантике там Oberon-2 и немного Smalltalk

Nihilist
()
Ответ на: комментарий от Nihilist

>> И что, даже RT Java им не помогла? o_O

>Real-Time Java -- как в анекдоте про морскую свинку

Ну в жаве это API хотя бы есть. Т.е там можно написать шедюлер, который вызывает какие-то методы по расписанию, есть там какой-то контроль за приоритетами тредов чтобы низкоприоритетные треды не блокировали мутекс мешающий работе высокоприоритетного треда, есть какие-то спорадические эвенты которые ломают план использования процессорного ресурса и JVM это как-то пытается их разрулить. В С++ этого API однако нет.

Absurd ★★★
()
Ответ на: комментарий от tailgunner

>а вдруг заставят юзать эту свинку? o_O

В mission critical задачах С++ тоже не особо доверяют.

Absurd ★★★
()
Ответ на: комментарий от lester

>предлагаю минуту помолчать, чтоб помянуть Томми, который на себе проверил Real-Time Java...

RT Java предназначена для того чтобы управлять приоритетами тредов и делать шедюлинг. Не для mission-critical. Sun это признает: "Замечание относительно поддержки языка Java... Технология Java не является устойчивой к сбоям и не предназначена... для использования в рамках управляющих систем реального времени..., в которых сбой языка Java может повлечь за собой смерть, увечье, или тяжелый урон инфраструктуре или окружающей среде. Компания Sun Microsystems, Inc. обязала компанию Microsoft разместить данное предупреждение".

Absurd ★★★
()
Ответ на: комментарий от Absurd

> RT Java предназначена для того чтобы управлять приоритетами тредов и делать шедюлинг.

Для прогнозируемых временных характеристик работы, вообще-то..

mv ★★★★★
()
Ответ на: комментарий от Absurd

> Ну в жаве это API хотя бы есть. Т.е там можно написать шедюлер, который вызывает какие-то методы по расписанию, есть там какой-то контроль за приоритетами тредов чтобы низкоприоритетные треды не блокировали мутекс мешающий работе высокоприоритетного треда, есть какие-то спорадические эвенты которые ломают план использования процессорного ресурса и JVM это как-то пытается их разрулить. В С++ этого API однако нет.

Однако, на уровне ОС такие вещи делать положено. И они делаются.

> RT Java предназначена для того чтобы управлять приоритетами тредов и делать шедюлинг. Не для mission-critical

Причем здесь mission-critical? Она должна была управлять планированием и событиями в Томми. Был Томми mission-critical или не был - неважно. Результат известен :D

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Был Томми mission-critical или не был - неважно. Результат известен :D

Официально поддерживаемая скорость была ниже :-D

mv ★★★★★
()
Ответ на: комментарий от tailgunner

>Однако, на уровне ОС такие вещи делать положено. И они делаются.

Ну если писать на Си, то можно положиться на то как оно описано в документации на ядро. Как например себя будет вести система если высокоприоритетный тред пытается захватить мутекс который захвачен низкоприоритетным тредом. Си++ тут не поможет - в boost::thread я ничего такого не нашел.

>Причем здесь mission-critical? Она должна была управлять планированием и событиями в Томми. Был Томми mission-critical или не был - неважно. Результат известен :D

"99 процентов моих экспериментов были неудачными. Я волком вгрызался в один процентов удачных и брал из них все" (Ц) создатель корпорации Хонда.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Ну если писать на Си, то можно положиться на то как оно описано в документации на ядро. Как например себя будет вести система если высокоприоритетный тред пытается захватить мутекс который захвачен низкоприоритетным тредом. Си++ тут не поможет - в boost::thread я ничего такого не нашел.

А как себя будет вести сишная программа, залочившаяся навсегда в ядре из-за кривой работы приоритетов в ядерной реализации futex'ов? Никому верить нельзя...

mv ★★★★★
()
Ответ на: комментарий от Absurd

>>Однако, на уровне ОС такие вещи делать положено. И они делаются.

>Ну если писать на Си, то можно положиться на то как оно описано в документации на ядро.

Если писать на Си++, на ядро можно положиться ровно в той же степени.

> Как например себя будет вести система если высокоприоритетный тред пытается захватить мутекс который захвачен низкоприоритетным тредом.

Точно так же, как и в Си.

> Си++ тут не поможет - в boost::thread я ничего такого не нашел.

Boost.Thread не является частью Си++

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Точно так же, как и в Си.

А ещё такие весёлые штуки есть, зовутся ошибками в процессоре (и другом железе) :) Программирование - оно такое, как хождение по минному полю.

Запомнил с детства фразу из "Робокопа": "Работоспособность выше 90% - норма" ;)

mv ★★★★★
()
Ответ на: комментарий от mv

>> Точно так же, как и в Си.

> А ещё такие весёлые штуки есть, зовутся ошибками в процессоре (и другом железе) :)

Обычно их маскируют ядро и драйверы.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Обычно их маскируют ядро и драйверы.

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

mv ★★★★★
()
Ответ на: комментарий от tailgunner

>>>Однако, на уровне ОС такие вещи делать положено. И они делаются.

>>Ну если писать на Си, то можно положиться на то как оно описано в документации на ядро.

>Если писать на Си++, на ядро можно положиться ровно в той же степени.

Минус гранулярность контроля если используем RAII цацки типа Loki::ObjectLevelLockable<MyClass>::Lock либо имеем регрессию к Си с Си++ путающимся под ногами.

>> Как например себя будет вести система если высокоприоритетный тред пытается захватить мутекс который захвачен низкоприоритетным тредом.

>Точно так же, как и в Си.

Си не склоняет к написанию дополнительных слоев абстракции которые тоже надо будет мэйнтейнить.

>> Си++ тут не поможет - в boost::thread я ничего такого не нашел.

>Boost.Thread не является частью Си++

Я уже писал что в соответствии с т.н Стандартом частью Си++ являются std::cin, std::cout, std::cerr и cstd::log, так как на компьютере может не быть клавиатуры, сети и монитора. Есть также идиотские триграфы которые позволяют при набивании кода пользоваться символами которых нет на некоторых доисторических терминалах. При этом однако предполагается что компьютер у нас 32-битный с виртуальной памятью.

Absurd ★★★
()
Ответ на: комментарий от Absurd

>>Если писать на Си++, на ядро можно положиться ровно в той же степени.

>Минус гранулярность контроля если используем RAII цацки типа Loki::ObjectLevelLockable<MyClass>::Lock

Не используй их.

> либо имеем регрессию к Си с Си++ путающимся под ногами.

Неправда.

> Я уже писал что в соответствии с т.н Стандартом частью Си++ являются std::cin, std::cout, std::cerr и cstd::log, так как на компьютере может не быть клавиатуры, сети и монитора.

И как это отличается от стандарта Си?

> Есть также идиотские триграфы

Которые достались по наследству от Си.

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

Бред.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>>>Если писать на Си++, на ядро можно положиться ровно в той же степени.

>>Минус гранулярность контроля если используем RAII цацки типа Loki::ObjectLevelLockable<MyClass>::Lock

>Не используй их.

Лучше вообще С++ не использовать.

>> Я уже писал что в соответствии с т.н Стандартом частью Си++ являются std::cin, std::cout, std::cerr и cstd::log, так как на компьютере может не быть клавиатуры, сети и монитора.

>И как это отличается от стандарта Си?

Дело в том что на всех операционных системах есть обширный набор полезных библиотек на Си. А BeOS таки RIP.

>> либо имеем регрессию к Си с Си++ путающимся под ногами.

>Неправда.

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

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

>Бред.

По Стандарту я не имею передать указатель на объект системному C API чтобы он мог переместить объект на новое место в памяти или вытеснил его на диск. Следовательно, на Win16 где память раздается по хендлам которые надо лочить чтобы получить указатель и разлочивать после использования это работать не будет.

Absurd ★★★
()
Ответ на: комментарий от Absurd

>>> либо имеем регрессию к Си с Си++ путающимся под ногами.

>>Неправда.

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

Сам сливаешь, сам засчитываешь.

> По Стандарту я не имею передать указатель на объект системному C API чтобы он мог переместить объект на новое место в памяти или вытеснил его на диск.

Название и пункт стандарта - в студию,

> на Win16 где память раздается по хендлам которые надо лочить чтобы получить указатель и разлочивать после использования это работать не будет.

На Win16 я не работал, но в 16-бит ДОС - вполне. Странно, да? А куча народа работала и на Win16, и работает на 64-бит Unix. Короче, перестань бредить.

tailgunner ★★★★★
()
Ответ на: комментарий от Absurd

Кстати, о стандартах... так как насет триграфов? Признаешь, что они не являются виной Си++, или отмажешься, как всегда? Как насчет сети, клавиатуры и прочего, которых нет в Си точно так же, как и в Си++?

tailgunner ★★★★★
()
Ответ на: комментарий от Absurd

>Лучше вообще С++ не использовать.

Не используй. Сделай одолжение себе и людям.

>>>либо имеем регрессию к Си с Си++ путающимся под ногами.

>>Неправда.

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

Я с тебя фигею: ляпнул какую-то бездоказательную и бессодержательную субъективную хрень, а в ответ на ТОЧНО ТАКОЕ ЖЕ бездоказательное и бессодержательное возражение "засчитал слив" =)))))

MYMUR ★★★★
()
Ответ на: комментарий от tailgunner

>> По Стандарту я не имею передать указатель на объект системному C API чтобы он мог переместить объект на новое место в памяти или вытеснил его на диск.

>Название и пункт стандарта - в студию,

Это абсолютно точно. Стандарт запрещает перемещать не-POD объекты другим способом кроме как через placement new с конструктором копирования под новый адрес с последующим удалением старого объекта через деструктор.

>> на Win16 где память раздается по хендлам которые надо лочить чтобы получить указатель и разлочивать после использования это работать не будет.

>На Win16 я не работал, но в 16-бит ДОС - вполне.

Речь о Win16. В ДОС-е не было функций типа GlobalAlloc() / GlobalLock() / GlobalUnlock()

Absurd ★★★
()
Ответ на: комментарий от MYMUR

>>Лучше вообще С++ не использовать.

>Не используй. Сделай одолжение себе и людям.

Нет буду. Для того чтобы в примерах и с аргументами объяснять людям какой это быдляческий язык.

Absurd ★★★
()
Ответ на: комментарий от tailgunner

>Признаешь, что они не являются виной Си++, или отмажешься, как всегда?

Дело в том что в С++ совершенно необязательно надо было поддерживать триграфы, но совершенно обязательно было сделать поддержку сети и нормальных терминалов которые поддерживают curses.

Absurd ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.