Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Не совпадают. Иначе бы в стандарте так и написали, что это одно и то же.
I>С чего бы это? Стандарт не святое писание, там есть ошибки, более того, их там полно. Вон про то, что reference это variable сколько лет не писали.
И сейчас этого не написано. Ты считаешь это ошибкой?
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>И сейчас этого не написано. Ты считаешь это ошибкой?
I>Нет. Кстати, различаешь ли ты точно также понятия тип и имя типа?
различаю
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>различаю
I>Так. А вот в стандарте есть такой пассаж:
I>
I>All function types, function names with external linkage, and variable names with external linkage have a
I>language linkage.
I>Сравни: function types, но function names и variable names. Почему не function type names?
Или ты предлагаешь линковать по именам типов, а не по типам? Так это бред.
не пойму, что тебя смущает в данном пассаже. То что variable names? Так там не просто variable names а variable names with external linkage.
S>Продемонстрируй, как будет выглядеть проверка с помощью консоли компилятора идентичности объектов, на которые ссылаются a и b.
//например, так (а можно еще по AST-у ходить — там будет точнее)
string GetObjectKeyFromCompileError(CompileError error)
{
if (error.SourceLine.Words().Contains("a"))
return"a";
if (error.SourceLine.Words().Contains("b"))
return"b";
return null;
}
DG>>можно. и если она к тому же будет эквивалентной исходной на каком-то подмножестве операций, то это нам позволит утверждать, что C++-программу, которая использует только эти операции, можно напрямую(без введения ВМ) выполнить в БД или с помощью вагонов РЖД. S>Но такая модель не делает поле объекта вагоном.
я плохо понимаю, что в данном случае означает термин "не делает или делает" и почему это важно в данном контексте...
DG>>и каковы границы этого утверждения? S>Оно справедливо в границах ООП в том случае если конструктор прямо или косвенно не записал this куда-нибудь. ООП не рассматривает объекты, которым нельзя отправить сообщение либо проверить идентичность.
но получается, что например, если брать объекты, которые имеют идентичность лишь иногда, то это утверждение не нарушается, отправить сообщения таких объектам можно — надо лишь подождать.
если разбирать твои утверждения и утверждения Синклера, то они опираются на двоичную логику, когда у объекта есть лишь два варианта — идентичность либо есть всегда, либо нет никогда.
и эти утверждения не работают для модели, когда объект рассматривается хотя бы с точки зрения трех состояний: у объекта идентичность есть всегда, у объекта идентичности нет никогда, у объекта идентичность — то есть, то нет.
как пример: когда ты делаешь утверждение "у объекта нет идентичности, и поэтому нельзя отправить ему сообщение", ты подразумеваешь именно вариант, что у объекта нет идентичности никогда, и только для этого варианта утверждение верно.
S>>>Ее можно автоматически переписать и без того что бы считать переменную рантайм объектом ООП.
DG>>покажи чем мы ее при этом считаем, и на основании каких утверждений мы переписываем программу. S>Мы ее ничем не считам. Допустим, что мы можем наблюдать узел AST, который может превратиться в переменную. Но нет никаких оснований считать что узел АСТ имеет какое-то отношение к некой переменной, особенно ввиду того, что сей узел будет заменен на кусок АСТ, представляющий обращение к некому кэшу.
вопрос был: в рамках какой модели делается такое переписывание?
или, например, другими словами: вот есть кусок кода, который это делает — как мы понимаем, что это кусок кода преобразует код верно? монетку подбрасываем? или верим программисту на слово?
DG>>>>потому что в реальных программах — такое поведение встречается с вероятностью 0.001% (условно) DG>>>>соответственно, с вероятностью 99.999% — это ошибка. S>>>посчитать средне-арифметическое значений функции в заданных точках это ошибка с вероятностью 99.999%?
DG>>и где там вызов функции от изменяемой переменной (кроме вызовов от изменяемой переменной цикла, которая пробегает по заданным точкам)? S>Например, вызов функции суммирования агрегата с очередным значением.
использован стандартный паттерн аккумулятор — ничего криминального. при этом на основе промежуточных (изменяемых значений) аккумулятора никаких других расчетов не делается. кроме обновления его самого.
DG>>скажет, что программа требует рефакторинга, и что откомпилированный результат лучше выбросить, если есть возможность. S>Выбросить работающий код потому что он не соответствует паттернам, заложенным в компилятор? Боюсь, что немногие будут пользоваться таким компилятором.
вот возьмем ситуацию, когда компилятор сейчас говорит, что возможен выход за границы массива, и поэтому такую программу лучше выбросить? ты такой программой будешь пользоваться? или ты ее выбросишь (например, перепишешь?)
в чем отличие этой ситуации от приведенной мной ситуации?
с другой стороны, если паттерны можно добавлять, то чем это отличается от тех же классов и статик-типизированных языков?
зы
также паттернов на самом деле счетное число, и они все крутятся вокруг небольшого кол-ва центральных понятий:
состояние, множество, объединение/разница, последовательность, вариант, время, идентификация, отображение, изменение и т.д.
Здравствуйте, samius, Вы писали:
S>Хорошо, пусть будет объект, инициализированный значением этого литерала. Но i — это не объект. Это идентификатор.
Для случая оперирования по значению, это одно и то же.
I>>А употребленное тобой "имя переменной" это в терминах чего было? S>Хорошо, пусть будет "идентификатор".
Имя переменной тоже неплохо, в чем проблема? По определению, переменная в ЯП — это именованный адрес.
Здравствуйте, Lloyd, Вы писали:
L>Да, тип Int32 — неизменяемый. Отсутствие/наличие const тут погоды не делает, т.к. этот модификатор относится не к типу, а к переменной.
DG>>программист это решение принял на основании какой-то информации (а не просто потому что так захотела его левая пятка) DG>>соответственно, я еще раз спрашиваю — какая информация есть у программиста, которой нет у компилятора? S>Собственно так бывает, что сначала левая пятка программиста захотела сделать объект мутабельным, а потом она же захотела сделать его иммутабельным. Может программист покурил чего до того или после и у программиста появились какие-то соображения. Может его на форуме кто надоумил. Компилятору нужна такая информация?
вопрос всё тот же — на основании какой информации человек понял что это правильное решение?
вот если в этой ситуации будет два человека: один говорит надо делать mutable, а другой говорит — нет, надо сделать immutable.
они же этот спор решают приведением доводом на основе какой-то информации, а не монетку бросают.
так какая информация будет использоваться?
S>>Продемонстрируй, как будет выглядеть проверка с помощью консоли компилятора идентичности объектов, на которые ссылаются a и b.
DG>//например, так (а можно еще по AST-у ходить — там будет точнее) DG>
DG> if (error.SourceLine.Words().Contains("a"))
DG> return"a";
DG> ...
DG>
Строчка "b = a'" сломает всю кухню.
И AST тут не поможет, если перед этой строчкой будет "if(rnd.next() < 0.1)".
А раз метод не позволяет отличить объекты, то он не может использоваться в качестве идентичности по определению идентичности.
DG>>>можно. и если она к тому же будет эквивалентной исходной на каком-то подмножестве операций, то это нам позволит утверждать, что C++-программу, которая использует только эти операции, можно напрямую(без введения ВМ) выполнить в БД или с помощью вагонов РЖД. S>>Но такая модель не делает поле объекта вагоном.
DG>я плохо понимаю, что в данном случае означает термин "не делает или делает" и почему это важно в данном контексте...
Это так же важно как и то, является ли поле объектом. "делает или не делает" здесь то же, что и "является или нет".
S>>Оно справедливо в границах ООП в том случае если конструктор прямо или косвенно не записал this куда-нибудь. ООП не рассматривает объекты, которым нельзя отправить сообщение либо проверить идентичность.
DG>но получается, что например, если брать объекты, которые имеют идентичность лишь иногда, то это утверждение не нарушается, отправить сообщения таких объектам можно — надо лишь подождать.
Известная мне ОО парадигма требует идентичности всегда.
DG>если разбирать твои утверждения и утверждения Синклера, то они опираются на двоичную логику, когда у объекта есть лишь два варианта — идентичность либо есть всегда, либо нет никогда. DG>и эти утверждения не работают для модели, когда объект рассматривается хотя бы с точки зрения трех состояний: у объекта идентичность есть всегда, у объекта идентичности нет никогда, у объекта идентичность — то есть, то нет.
Такая модель не является ООП моделью. DG>как пример: когда ты делаешь утверждение "у объекта нет идентичности, и поэтому нельзя отправить ему сообщение", ты подразумеваешь именно вариант, что у объекта нет идентичности никогда, и только для этого варианта утверждение верно.
Хорошо, можно считать что в тот момент, когда невозможно определить идентичнолсть объекта, он не является объектом.
DG>>>покажи чем мы ее при этом считаем, и на основании каких утверждений мы переписываем программу. S>>Мы ее ничем не считам. Допустим, что мы можем наблюдать узел AST, который может превратиться в переменную. Но нет никаких оснований считать что узел АСТ имеет какое-то отношение к некой переменной, особенно ввиду того, что сей узел будет заменен на кусок АСТ, представляющий обращение к некому кэшу.
DG>вопрос был: в рамках какой модели делается такое переписывание? DG>или, например, другими словами: вот есть кусок кода, который это делает — как мы понимаем, что это кусок кода преобразует код верно? монетку подбрасываем? или верим программисту на слово?
Не понимаю, причем здесь кусок кода, преобразующего код? Зачем нам понимать, что он делает?
DG>>>и где там вызов функции от изменяемой переменной (кроме вызовов от изменяемой переменной цикла, которая пробегает по заданным точкам)? S>>Например, вызов функции суммирования агрегата с очередным значением.
DG>использован стандартный паттерн аккумулятор — ничего криминального. при этом на основе промежуточных (изменяемых значений) аккумулятора никаких других расчетов не делается. кроме обновления его самого.
Речь была о том что изменять можно лишь счетчики... Ну да ладно, а почему нельзя делать вычисления на промежуточных значениях?
S>>Выбросить работающий код потому что он не соответствует паттернам, заложенным в компилятор? Боюсь, что немногие будут пользоваться таким компилятором.
DG>вот возьмем ситуацию, когда компилятор сейчас говорит, что возможен выход за границы массива, и поэтому такую программу лучше выбросить? ты такой программой будешь пользоваться? или ты ее выбросишь (например, перепишешь?) DG>в чем отличие этой ситуации от приведенной мной ситуации?
Компилятор и сейчас много чего говорит, чего в принципе не может быть, но он допускает это на основе каких-то заложенных в него паттернов. В частности, он может сказать что переменная может быть не проинициализирована. Из этого не следует что существует вероятность того что она не будет проинициализирована. Да, приходится предпринимать действия, которые нацелены на то, что бы удовлетворить компилятор. Но такие предупреждения вовсе не означают то, что программой невозможно пользоваться. Да, эти предупреждения позволяют обнаруживать ошибки. Но еще раз, они не означают 100% что в программе ошибка.
DG>с другой стороны, если паттерны можно добавлять, то чем это отличается от тех же классов и статик-типизированных языков?
Кто их будет добавлять? Разработчик компилятора? Пользователь компилятора?
DG>зы DG>также паттернов на самом деле счетное число, и они все крутятся вокруг небольшого кол-ва центральных понятий: DG>состояние, множество, объединение/разница, последовательность, вариант, время, идентификация, отображение, изменение и т.д.
Счетное число паттернов — это слишком много для конкретного компилятора, т.к. вопрос принадлежности кода паттерну становится неразрешим за конечное время.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Хорошо, пусть будет объект, инициализированный значением этого литерала. Но i — это не объект. Это идентификатор.
V>Для случая оперирования по значению, это одно и то же.
Возражаю. Идентификатор один, значения разные. Уже это дает повот делать различия.
I>>>А употребленное тобой "имя переменной" это в терминах чего было? S>>Хорошо, пусть будет "идентификатор".
V>Имя переменной тоже неплохо, в чем проблема? По определению, переменная в ЯП — это именованный адрес.
ЯП — это другой уровень. Я говорил в терминах ООП.
DG>>но получается, что например, если брать объекты, которые имеют идентичность лишь иногда, то это утверждение не нарушается, отправить сообщения таких объектам можно — надо лишь подождать. S>Известная мне ОО парадигма требует идентичности всегда.
вы подходите к ООП, как к религии, которая задана как догма.
а это наука, и есть известный алгоритм, как произвольную модель (или теорию) совместить с заданным набором утверждений (в том числе с утверждениями ослабляющий базис исходной модели).
зы
если брать, например, в науке переход к геометрии лобачевского от евклидовой, или к релятивисткой физике из ньютоновской — то они двигались ровно тем же путе: бралось одно из базовых утверждений предыдущей модели(теории) и ослаблялось.
геометрия лобаческового, вообще, была создана как забавные размышления, что будет если считатать, что базисная аксиома параллельные переменные не пересекаются не нужна. и только потом нашли где можно это в реальности использовать.
если послушать тебя с синклером, то выяснится, что и nullable-чисел не должно существовать. из-за того, что математика требует, чтобы числа существовали всегда.
DG>>>но получается, что например, если брать объекты, которые имеют идентичность лишь иногда, то это утверждение не нарушается, отправить сообщения таких объектам можно — надо лишь подождать. S>>Известная мне ОО парадигма требует идентичности всегда.
DG>вы подходите к ООП, как к религии, которая задана как догма.
Я подхожу формально. DG>а это наука, и есть известный алгоритм, как произвольную модель (или теорию) совместить с заданным набором утверждений (в том числе с утверждениями ослабляющий базис исходной модели).
Это за рамками базиса исходной модели, в рамках которой я до сих пор пытался вести беседу.
DG>зы DG>если брать, например, в науке переход к геометрии лобачевского от евклидовой, или к релятивисткой физике из ньютоновской — то они двигались ровно тем же путе: бралось одно из базовых утверждений предыдущей модели(теории) и ослаблялось. DG>геометрия лобаческового, вообще, была создана как забавные размышления, что будет если считатать, что базисная аксиома параллельные переменные не пересекаются не нужна. и только потом нашли где можно это в реальности использовать.
Вот и я об этом. Сначала вы утверждали что я слишком узко понимаю ООП, теперь оказалось что вы его понимаете шире чем оно есть. Если бы вы начали со слов "давайте представим расширенное ООП2, где идентичность не нужна", то возражать было бы нечего.
Здравствуйте, DarkGray, Вы писали:
DG>если послушать тебя с синклером, то выяснится, что и nullable-чисел не должно существовать. из-за того, что математика требует, чтобы числа существовали всегда.
Не имею понятия, что такое nullable-число
S>Вот и я об этом. Сначала вы утверждали что я слишком узко понимаю ООП, теперь оказалось что вы его понимаете шире чем оно есть. Если бы вы начали со слов "давайте представим расширенное ООП2, где идентичность не нужна", то возражать было бы нечего.
я хочу от тебя, чтобы ты не просто ссылался на ООП в формате я верю: что с точки зрения ООП — это неверно, а доказал что это неверно.
например, в ООП не вводится понятия времени.
поэтому если ввести формальную функцию идентичности как: идентичность объектов определяется как идентичность состояния объектов в моменты времени t, когда g(t) > 0.
и докажи (или покажи) какому базисному утверждению ООП — это противоречит.
при этом функция идентичности есть — вот она, выше.
