Здравствуйте, batu, Вы писали:

B>На перспективу.
Ну, тогда подождём.

B>Дело ж не только в объекте, а еще в том, кто и как будет с ним работать.
И? Вся работа с событиями у вас описана ровно так же, как с любым другим объектом. То, что там "за сценой" кто-то делает что-то ещё — ну так это нормально для библиотеки.

S>> К примеру, целые числа не ведут себя как объекты. Поэтому реализация их через объекты (как, скажем, в том же Smalltalk) является надуманной.
B>Прочитай еще раз у меня про объекты. Есть объекты-классы, объекты-типы (или объекты-значения) и объекты-инструкции. Это разные вещи.
В чём различие? В чём общность? Меня настораживает эквивалентность объектов-типов и объектов-значнений. Она говорит либо о том, что вы не различаете понятия "тип" и "значение", либо о том, что вы непоследовательно пользуетесь собственной терминологией.

S>>И зачем любому объекту свойство Result? Какого оно типа?
B>Логического. Нужно для проверки выполнения объекта.
Логический — это, надо полагать, объект-значение. А у него тоже есть свойство Result? Или утверждение "свойство Result есть у всех объектов" оказалось опрометчивым?

S>>Я не понимаю, что изменяется в инструкции I = I + 1 при её выполнении. В классике меняется состояние машины: значение, хранящееся в переменной с именем "I". Инструкция остаётся точно такой же. Ей не нужен никакой Result — доступа к нему всё равно никто не получит.
B>В вашем примере две инструкции. Сложения и присвоения.
Или три. Доступа к значению, сложения, и присваивания. Или пять — доступа к значению, приведения типа, сложения, приведения типа, присваивания.
Ни у одной из них нет никакого изменяемого состояния.

S>>А, то есть объект "for" не имеет шанса превратиться в обычный исполняемый код на x86?
B>Очень даже превращается. А то как же. Зачем вы спрашиваете очевидные вещи? Стеб?
Нет. Ничего очевидного тут нету. Ну вот к примеру — как же он превратится в исполняемый код, если без виртуальной машины он всё равно не может выполниться?

B>Да. Эффективность будет ниже. Я уже писал об этом. Но причина не в реализации объектов, Здесь разницы нет, а в проверке на события.
А что, нельзя как-то оптимизировать вот эту "проверку на события"? По идее, это должно быть очень легко — из миллионов происходящих событий интерес вызывают лишь немногие.
Реализация "объектов", конечно же, будет оказывать разительное влияние. Например, если цикл for не имеет никакого "состояния", которое он обязан менять в процессе исполнения, компилятор может его развернуть, или вовсе устранить. К примеру, тут выше пробегал код, где в цикле происходит одно и то же присваивание. Современный компилятор с промышленного языка программирования перенесёт присваивание за цикл, а сам цикл устранит как избыточный.
Ваш компилятор ничего подобного сделать не сможет — потому, что у for есть какой-то Result, который нужно менять при исполнении, даже если внутри цикла ничего не происходит.

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