Почему многие оконные менеджеры не поддерживают ориентацию объектов?
Замечания: Я провел краткий поиск, который дал мало результатов, единственный действительно релевантный результат этот, так что я не думаю, что об этом уже спрашивали.
В последнее время я много занимался разработкой ОС и обнаружил, что большинство, если не все, не имеют полностью объектно-ориентированных интерфейсов оконных приложений, включая Windows. Это, конечно, с заметным исключением интерпретируемых языков байт-кода, таких как C # (или CLI в целом) и Java. (Чтобы уточнить, я имею в виду, что они имеют тенденцию создавать окно через функцию, а не через создание класса).
Я могу понять меньших менеджеров, сделанных для простоты, таких как tinywm, но даже большие оконные менеджеры, такие как Metacity, Fluxbox, а также Открытая коробка как правило, все еще не из объектов, а из функций — несмотря на то, что некоторые из них написаны на C ++, а не на чистом C (по крайней мере, насколько я понимаю).
Это может быть наивным вопросом, но почему это так?
Я понимаю, что важно реализовать не объектно-ориентированный ABI для языков, которые не поддерживают объектную ориентацию, но почему это невозможно также обеспечить высокоуровневые хуки для языков, которые ДЕЛАТЬ поддерживать ориентацию объекта?
Разве, возможно, программисту в конце концов не будет легче иметь такие хуки, потому что это облегчит разработку программного обеспечения? Учитывая достижения в области аппаратного обеспечения, не будет ли потеря производительности минимальной по сравнению с преимуществами от того, насколько проще было бы разрабатывать?
Это было что-то, что меня немного напрягало, и я надеюсь, что у кого-то будет ответ.
PSЕсли мое понимание где-то в корне неверно, не стесняйтесь поправлять меня.
Решение
Это не просто окна. Нет операционных систем, которые имеют объектно-ориентированные API в терминах методов, вызываемых через объекты, как в myObject->method() или же myObject.method(). Большинство из тех, что мы используем сейчас, имеют оконные API, разработанные в начале 1980-х годов (например, Windows, The X Window System и т. Д.). Есть вопросы языка и ABI, чтобы рассмотреть. Единственное исключение, которое я могу придумать, это независимая от языка OO-вещь OS / 2, называемая Системная объектная модель.
Формально говоря, нет никакой разницы между method(object, ...) а также object.method(...) или же object->method(...)Синтаксическая разница.
Другие решения
Я думаю, вы где-то в корне ошибаетесь, но это неловкий способ сказать это. 🙂
Менеджеры окон обычно ориентированы на объекты, но они не предназначены для классов и объектов, как вы можете найти в C ++. То, что вы, как правило, имеете что-то вроде:
struct Object {
...
};
void DoSomething(Object* obj, ...);
Все функции, предоставляемые оконным менеджером, управляют внутренними объектами Object, будь то кнопка, окно или какой-то другой виджет. В большинстве случаев программист должен обрабатывать эти объекты непрозрачно и позволить API управлять их содержимым. Как программист, вы все еще работаете с объектами и методами этих объектов. Просто большая часть связи нарушена, и не похоже, что люди ожидают, что объектно-ориентированное программирование будет выглядеть, потому что объекты являются параметрами функций, а не функциями, являющимися свойствами объектов.