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 ()
Ответ на: комментарий от gaa

>> Афигеть, впервые вижу приписывание конструкторов копирования зависти к Фортрану o_O

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

ИМХО, именно правила вызова конструкторов и привели к офигенной сложности Си++. Может быть, Страуструпу следовало оставить value-семантику для struct, и сделать классы reference. Интересно, он как-то обосновал свои решения?

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

> Может быть, Страуструпу следовало оставить value-семантику для struct, и сделать классы reference.

Возможно, тогда бы этого треда не было. Это сильно бы ослабило мои позиции.

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

>ИМХО, именно правила вызова конструкторов и привели к офигенной сложности Си++. Может быть, Страуструпу следовало оставить value-семантику для struct, и сделать классы reference.

Да, так было бы логичнее конечно же. Тогда бы все разговоры любителей плюсов о cons и trade-off имели бы какой-то смысл.

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

А если бы в довершение объекты бы жили только в хипе, да операторы нельзя было перегружать (вот точно вам говорю: перегрузка операторов - это Страуструповы комплексы перед фортраном)...

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

> да операторы нельзя было перегружать (вот точно вам говорю: перегрузка операторов - это Страуструповы комплексы перед фортраном)...

А перегрузка операторов в Питоне, Хаскеле (и Клу тоже :)) - это чьи комплексы перед чем? :D

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

во всех остальных языках это не недостаток, а преимущество, мы же только с++ здесь ругаем, правда? :)

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

> Это вредное влияние плюсов, разумеется!;)

Что, Страуструп тоже слямзил машину времени ЛОР? o_O

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

>А если бы в довершение объекты бы жили только в хипе

Это само собой. Только сказав "А" надо сказать и "Б" - если ограничиваемся только подсчетом ссылок, то выносим это на уровень языка и вносим класс weak - референсов. Если не ограничиваемся, то надо делать разметку бинарного представления объекта под gc. В С++ сказано "А", так как разметки объектов под gc нет, но не сказано "Б".

>да операторы нельзя было перегружать

Это не кардинальная проблема. Можно перегружающие библиотеки и не использовать. Лично меня работа с BigInteger в жабке однако коробит.

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

> Историю прогуливал? :D

У нас на специальности из истории освещали разве что исторические аспекты био- и прочих реакторов ;)

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

> Может быть, Страуструпу следовало оставить value-семантику для struct, и сделать классы reference.

В D struct - просто размеченная область памяти. Их можно без проблем передавать в C. А class - ссылочный тип дпнных с поддержкой OO. Это действительно решает кучу проблем, но немного усложняет написание шаблонов, т.к. где структуру достаточно присвоить, класс нужно копировать. Приходится городить static if (is(T : struct)) { ...

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

>Приходится городить static if (is(T : struct)) { ...

Это я так думаю не хуже частичных специализаций template member function шаблонным параметром Loki::Int2Type<isPolymorfic>.

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

> Может быть, Страуструпу следовало оставить value-семантику для struct, и сделать классы reference. Интересно, он как-то обосновал свои решения?

Уж не знаю как бы это обовновал Страуструп, но многих бы это лишило возможности использовать один и тот же алгоритм для работы с double и классом MyCoolDoubleWithInacuracyCouting.

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

>Уж не знаю как бы это обовновал Страуструп, но многих бы это лишило возможности использовать один и тот же алгоритм для работы с double и классом MyCoolDoubleWithInacuracyCouting.

Я как-то сталкивался с необходимостью отказаться от double в пользу custom типа и идея сделать это классическим С++ способом провалилась из-за перформанса. Пришлось на массивах делать.

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