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

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

B>>Стандарты такая вещь..меняется..
S>На перспективу работаете? Или очень хочется ограничить рынок языка исключительно владельцами цветных принтеров, да ещё и с абсолютным цветоощущением?
На перспективу.

S>>>Я не буду называть ваши события сообщениями. В терминах smalltalk сообщение — это, к примеру, Fire. А ваше "событие" — это полноценный объект, точно такой же, как и любой другой. Он никакого отношения к языку как таковому не имеет — его можно изобразить хоть на C#, хоть на Smalltalk.
B>>Можно. А выполнение? Хотя тоже можно. Поднапрягшись.
S>Не вижу никакого особенного поднапряжения. Библиотека пишется один раз, также как и компилятор. Только она, в отличие от компилятора, может быть расширяемой.
Дело ж не только в объекте, а еще в том, кто и как будет с ним работать.

S>>>Правильно. Поэтому a и b — это не объекты. И точно также и инструкции: у них нету состояния, нет обмена сообщениями. Это совершенно обычные структуры.
B>>Если а и b не объекты..У меня слов нет..
S> К примеру, целые числа не ведут себя как объекты. Поэтому реализация их через объекты (как, скажем, в том же Smalltalk) является надуманной.
Прочитай еще раз у меня про объекты. Есть объекты-классы, объекты-типы (или объекты-значения) и объекты-инструкции. Это разные вещи.

B>>Свои методы.. Вполне возможно. А вот вызывать чужие.. Надо подумать.
S>Конечно надо. Подумаю.

B>>>>Могу еще привести объект If. Любой объект у меня выполняясь может изменить свойство Result. Т.е. выполниться успешно или не успешно.
S>>>А свойство Result — оно кому принадлежит? Объекту If? Или всей программе?
B>>Свойство Result имеет любой объект.
S>И зачем любому объекту свойство Result? Какого оно типа?
Логического. Нужно для проверки выполнения объекта.

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

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


B>>Пользователь получит только то, что предусмотрено алгоритмом. А вот при отладке и сопровождении кое-что может понадобиться.
S>Я уже приводил примеры того, как работает реальная отладка и сопровождение. Совершенно необязательно для них держать в памяти копию исходного кода со всеми комментариями.
Есть и такой вариант. Не хотелось бы. Посмотрим.

B>>Из твоих статей я понял что ты занимался базами данных. Тогда должен понимать, что дублирование данных непременно приводит к потере доверия к ней.
S>Я много чем занимался. Откуда возьмется дублирование в JavaDoc?
А что ж ты предлагаешь дублировать мне?

B>>Из-за того что данные рано или поздно начнут отличаться. Правильней их держать в одном месте. Кстати, это одна из причин трудностей с созданием электронного документооборота. Данные для анализа должны находится внутри объекта, а не в прикрепленных структурах как делается сейчас. Так со временем накапливаются различия между документом и прикрепленной к нему структурой данных.
S>Я не знаю, что вы называете "электронным документооборотом". В том, что понимаю под этим я, никаких особенных трудностей нет. Кроме того, эта область никакого отношения к программированию не имеет.
Не имеет так не имеет. Вопрос снят.