История изменений

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

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

Класс определяется как совокупность методов, сигналов и свойств. Cигналы и свойства связываются «в рантайме», т.е. их имена являются обычными строками, по которым осуществляется связывание. Для сигнала можно узнать его сигнатуру, для свойства — тип.

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

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

Поэтому я еще раз повторю тезис, который выше озвучивал: glib — это шаг в сторону Objective C, Javascript, Ruby, но никак не в сторону С++. Объектная и темплейтная модели крестов в данном случае «не про то», т.е. совершенно про другое.

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

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

Класс определяется как совокупность методов, сигналов и свойств. Cигналы и свойства связываются «в рантайме», т.е. их имена являются обычными строками, по которым осуществляется связывание. Для сигнала можно узнать его сигнатуру, для свойства — тип.

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

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

Поэтому я еще раз повторю тезис, который выше озвучивал: glib — это шаг в сторону Objective C, Javascript, Ruby, но никак не в сторону С++. Объектная и темплейтная модели крестов в данном случае «не про то», т.е. соврешенно про другое.

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

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

Класс определяется как совокупность методов, сигналов и свойств. Cигналы и свойства связываются «в рантайме», т.е. их имена являются обычными строками, по которым осуществляется связывание. Для сигнала можно узнать его сигнатуру, для свойства — тип.

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

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

Поэтому я еще раз повторю тезис, который выше озвучивал: glib — это шаг в сторону Objective C, Javascript, Ruby, но никак не в сторону С++. Объектная и темплейтная модели крестов в данном случае «не про то», т.е. соврешенно про другое.

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

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

Класс определяется как совокупность методов, сигналов и свойств. Cигналы и свойства связываются «в рантайме», т.е. их имена являются обычными строками, по которым осуществляется связывание. Для сигнала можно узнать его сигнатуру, для свойства — тип.

По сути glib определяет компонентную модель для динамически типизированного языка. Текущие ограничения на её применение это фактически ограничения Си: например, в Си бессмыслено связывание методов по имени, поэтому его нет.

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

Поэтому я еще раз повторю тезис, который выше озвучивал: glib — это шаг в сторону Objective C, Javascript, Ruby, но никак не в сторону С++. Объектная и темплейтная модели крестов в данном случае «не про то», т.е. соврешенно про другое.

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

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

Класс определяется как совокупность методов, сигналов и свойств. Cигналы и свойства связываются «в рантайме», т.е. их имена являются обычными строками, по которым осуществляется связывание.

По сути glib определяет компонентную модель для динамически типизированного языка. Текущие ограничения на её применение это фактически ограничения Си: например, в Си бессмыслено связывание методов по имени, поэтому его нет.

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

Поэтому я еще раз повторю тезис, который выше озвучивал: glib — это шаг в сторону Objective C, Javascript, Ruby, но никак не в сторону С++. Объектная и темплейтная модели крестов в данном случае «не про то», т.е. соврешенно про другое.

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

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

Класс определяется как совокупность методов, сигналов и свойств. Cигналы и свойства связываются «в рантайме», т.е. их имена являются обычными строками, по которым осуществляется связывание.

По сути glib определяет компонентную модель для динамически типизированного языка. Текущие ограничения на её применение это фактически ограничения Си: например, в Си бессмыслено связывание методов по имени, поэтому его нет.

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

Поэтому я еще раз повторю тезис, который выше озвучивал: glib — это шаг в сторону Objective C, Javascript, Ruby, но никак не в сторону С++. Объектная и темплейтная модели крестов в данном случае «не про то», т.е. соврешенно про другое.