Здравствуйте, samius, Вы писали:
S>Если для тебя это одно и то же, то не надо подписывать сюда программистов в общем случае. Я тоже программист (и в том числе на C++), но различаю эти понятия.
DG>>ты можешь это проверить? доказать? S>Во время компиляции не работает доставка сообщений, object identity в том смысле, в котором они работают во время выполнения.
опять же это вопросы веры и не более.
вот если бы ты сказал: я тут проверил, и увидел, что конструкторы при компиляции не вызываются (потому что я в конструкторе винт форматирую, а при компиляции он не сформатировался), вот это уже было движение в правильном направлении — ты бы перешел от недоказуемых вещей к тому что есть на самом деле и то, что можно потрогать.
я могу, например, согласиться — что при компиляции нету еще классов и объектов, есть лишь их бледные проекции, потому что это можно проверить и этим можно управлять. и я утверждаю, что эти бледные проекции умеют посылать сообщения и это можно проверить, меняя листинг и получая сообщения на консоле компилятора.
S>Я понимаю, что такое самораскрутка компилятора. Но не очень представляю себе как семантика поля может быть продемонстрирована с помощью рекурсивного типа данных с отстуствием выхода из рекурсии и рекурсивного метода без выхода из рекурсии в рамках eager языка.
кроме самораскрутки компилятора, есть еще самораскрутка моделей.
нет там никакой рекурсии, потому что формально там язык A' описывается с помощью языка A.
и цепочка получается следующая:
допустим мы наивно знаем, что такое объект, поле, переменная и т.д., и что такое язык A, который оперирует этими понятиями.
для формализации понимания языка A построим язык A' и опишем его поведение и ожидаемые свойства, используя аппарат языка A.
описываем..
получившийся язык A' проверяем на эквивалентность языку A, если эквивалентности не наблюдается — корректируем понимание языка A.
S>>>Это не так. Замыкание трансформирует локальную переменную в поле класса, но никакой объектизации переменной там нет. Как была переменная storage location, так им и осталась. Изменяется лишь ее принадлежность.
DG>>по видимому я не понимаю, что такое storage location. S>Интересно, ты понимаешь слишком широко модель ООП, но не понимаешь терминологии из спецификации языков.
я не понимаю, как ты трактуешь те или иные понятия, и какой евангелие(ну там страуструпа, книгу дракона, буча или что-то еще) для этого используешь (раз уж зашел вопрос про веру)
DG>>что такое storage location? и чем оно отличается для переменной и объекта? S>Это место для хранения. Переменная представляет собой место для хранения, а объект/значение хранится в этом месте.
если мы делаем new MyObject(), то где здесь переменная и место для хранения?
DG>>если не можем, то почему? S>Потому как не знаем все единицы компиляции/модули.
тогда мы должны были как минимум специфицировать (явно или неявно) интерфейс доступа к нашей программе(нашей части), и зафиксировать через какие сообщения в какое время кто и каким образом имеем доступ.
также должны были зафиксировать жизненный цикл, инварианты состояний и т.д.
мы всё это сделали?
DG>>если можем, то значит можем и понять — переменная изменяемая или нет, и в какие промежутки. S>даже если можем, то только в рамках одного потока выполнения.
мы же вроде были в парадигме ООП, а там нет никаких потоков, а есть интерфейс и сообщения, а также спецификация в какое время какое сообщение должно приниматься.
DG>>>>так name — это зависимая(относительная) ссылка. DG>>>>кстати, так переменные из компилируемой среды тоже можно интерпретировать, если есть необходимость. S>>>Не понял.
DG>>для переменных в следующем куске кода DG>>можно считать, что это есть пары ключ-значения из словаря F (который создается при старте функции F) с ключами "a" и "b" (или с ключами 0 и 1). DG>>или если мы знаем, что тред один (а из под функции F ни в коем случае F еще раз вызываться не может), то тогда значения a и b можно размещать в глобальном dictionary с ключами "F.a" и "F.b" DG>>и т.д. S>И какой в этом смысл кроме издевательства над инкапсуляцией?
например, получить возможность сохранять и восстанавливать состояние программы(или ее части) в произвольный момент времени.
например есть код:
T F()
{
var a = Foo();
var b = Server_Bar();
return a + b;
}
и нам хочется его запускать в браузере, при этом Server_Bar — это серверная функция, и мы знаем, что она может работать долго, поэтому нам нужно уметь ее вызывать асинхронно, чтобы не подвешивать браузер.
это приводит к тому, что необходимо уметь прерывать работу программы на время вызова Server_Bar, а также уметь хранить текущее состояние.
соответственно, можно автоматически переписать эту программу к виду:
DG>>ты что-то имеешь против ФЯ-шного ООП (или ООП-шного ФЯ)? S>Нет, я просто говорю что в рамках ФЯ (чистого) тема переменных бессмысленна.
это в смысле использовать модель ФЯ, который чисто списковый. и что в этой модели хорошего? кроме того, что математики могут об этой модели что-то подоказывать?
DG>>сигнализирует или о том, что или в нем есть ошибка (Foo не пересчитывается на основе изменения состояния a) S>Почему же это ошибка?
потому что в реальных программах — такое поведение встречается с вероятностью 0.001% (условно)
соответственно, с вероятностью 99.999% — это ошибка.
DG>>, или он требует рефакторинга (нарушается правило, что переменная должна использоваться лишь для хранения одной сущности) S>Одной сущности? Так будет одна сущность? S>
S>int a = GetValue1(init_value);
S>var r= Foo(a);
S>a = GetValue1(a);
S>var r2 = Bar(a);
S>return r + r2;
S>
S>Если не одна, тогда где разница между одной сущностью и не одной, например в цикле со счетчиком?
сущность не одна и в этом куске кода.
разница в том, что паттерны, которые используют переменные повторно все на перечет, один из таких паттернов — это использование счетчика цикла. остальные использования — это ошибка, или какой-то новый паттерн, который тогда надо ввести.
DG>>цикл for определенно закладывается на то, что переменная цикла будет меняться. S>Понимаешь, когда переменная не меняется, компилятор может сказать, что она не меняется. Как только она стала меняться, компилятор скажет что код заточен под то, что она меняется.
чем это отличается от того, что программист сначала поставил const/readonly на переменную, а потом убрал?
или другими словами — какая такая информация есть у программиста, которая ему позволяет так делать, и какой информации не хватает компилятору?
S>А если переменные статические?
S>По определению. Для того, чтобы что-то можно было трактовать как объект ООП, оно должно обладать идентичностью. Причём всегда, а не так, что с утра идентичность была, а в обед её уже нету. Потому, что это означает, что построенные на идентичности решения с утра работают, а после обеда — нет.
так вроде тогда правильный ответ, что надо строить решения на чем-то другом (например, на частичной идентичности), и жизнь сразу наладится. разве нет?
S>С чего вдруг? Мы не говорили о достаточности. Мы говорили только о необходимости.
речь идет именно о достаточности. потому что, например, модель вида "здесь используем идентичность, здесь — не используем, а здесь используем частичную идентичность;
здесь используем булеву логику, а здесь используем другую логику" включает в себя модель "мы только работаем с объектами с постоянной идентичностью и только с булевой логикой".
DG>>возьмем, как пример анонимный чат — там всё еще как-то понятно с точки зрения идентичности сообщений, но с идентичностью субъектов, которые эти сообщения постят — всё очень и очень непросто. но ведь необходимо и эту задачу уметь решать. S>Не вижу формулировки проблемы. Опять же, нужно понимать, что мы говорим не о реальном мире, а о программировании. Нас вопросы идентичности реальных субъектов вообще никак не интересуют.
вот этот постулат не понятен.
программирование мы используем для того, чтобы решать какие-то задачи в реальном мире, а не само по себе в вакууме.
и соответственно, если мы даже в реальном мире не можем разобраться на многих задачах с идентичностью, а программист утверждает, что он готов решать только задачи, где есть строгая идентичность, то получается — а нафиг нам такое программирование и такой программист, который нам ничем помочь не может?
DG>>или, например, возьмем машину — например, до какой степени машина идентична сама с собой по времени? по какому свойству определяется идентичность? по цвету, по номеру, по царапине на крыле? S>И какое отношение это имеет к программированию?
потому что программирование это перевод реальности в модель. соответственно, если в реальности нет строгой идентичности между объектами, то откуда она появится в модели?
DG>>или есть даже брать чисто программисткие заморочки — объект хранящийся в базе, он же на сервере, а потом на клиенте — это один и тот же объект? или это три разных? S>Это зависит от выбранной модели. Разве это не очевидно?
можем ли мы одновременно использовать две модели: одна которая утверждает что это идентичные объекты, а другая — что это разные?
или другими словами: можем ли мы использовать модель — которая в одной части утверждений считает, что это идентичные объекты, а в другой части утверждений считает, что это неидентичные объекты?
S>А, не ну если мы будем баловаться с небезопасными фичами C++, то можно сразу же забить на любые рассуждения о свойствах С++ программ.
так я тебе сразу говорил, что про эквивалентность можно лишь говорить на каком-то наборе операций, и что стоит это сразу оговаривать. В данном случае, ты рассматриваешь эквивалентность лишь на наборе безопасных операций.
но ты не стал это слушать, а начал бегать с шашкой и кричать: что в моем любимом языке можно утверждать, что переменная и ссылка — эквивалентны всегда безотносительно набора операций.
когда же я тебе показал, что это не так, твоя реакция свелась к "я так не играю".
соответственно, я также утверждаю, что переменные и объекты эквиваленты между собой на "безопасном"-наборе: получить/записать значение
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>одна
I>Согласно стандарту все же две.
Ссылку/цитату в студию. Ты его как-то не так интерпретируешь.
Z> Я уверен, что ты прекрасно понимаешь собеседника, но регулярно уводишь в лес обсуждения терминов где оттачиваешь демагогию.
если человек делает утверждение (особенно сильные утверждения с кванторами все(всегда) и не существует(никогда)), он обязан понимать границы применимости своего утверждения.
соответственно, отвод в сторону — это лишь попытка проверить, а человек понимает, что его утверждение имеет границы, и что вот они только что были пересечены.
DG>>>ты можешь это проверить? доказать? S>>Во время компиляции не работает доставка сообщений, object identity в том смысле, в котором они работают во время выполнения.
DG>опять же это вопросы веры и не более. DG>вот если бы ты сказал: я тут проверил, и увидел, что конструкторы при компиляции не вызываются (потому что я в конструкторе винт форматирую, а при компиляции он не сформатировался), вот это уже было движение в правильном направлении — ты бы перешел от недоказуемых вещей к тому что есть на самом деле и то, что можно потрогать.
В самом деле? Ты считаешь что факт вызова конструктора имеет определяющее значение в модели ООП, но object identity это вопрос веры? У тебя какая-то своя модель.
DG>я могу, например, согласиться — что при компиляции нету еще классов и объектов, есть лишь их бледные проекции, потому что это можно проверить и этим можно управлять. и я утверждаю, что эти бледные проекции умеют посылать сообщения и это можно проверить, меняя листинг и получая сообщения на консоле компилятора.
ты можешь определить идентичность объектов, получая сообщения на консоли компилятора?
DG>кроме самораскрутки компилятора, есть еще самораскрутка моделей.
DG>нет там никакой рекурсии, потому что формально там язык A' описывается с помощью языка A. DG>и цепочка получается следующая: DG>допустим мы наивно знаем, что такое объект, поле, переменная и т.д., и что такое язык A, который оперирует этими понятиями.
Если мы знаем, что такое поле, то зачем язык А? DG>для формализации понимания языка A построим язык A' и опишем его поведение и ожидаемые свойства, используя аппарат языка A. DG>описываем.. DG>получившийся язык A' проверяем на эквивалентность языку A, если эквивалентности не наблюдается — корректируем понимание языка A.
Точно так же можно раскрутить модель, в которой поле в C++ будет записью в БД или вагоном РЖД. Так что твоя модель ничего не доказывает.
DG>>>по видимому я не понимаю, что такое storage location. S>>Интересно, ты понимаешь слишком широко модель ООП, но не понимаешь терминологии из спецификации языков.
DG>я не понимаю, как ты трактуешь те или иные понятия, и какой евангелие(ну там страуструпа, книгу дракона, буча или что-то еще) для этого используешь (раз уж зашел вопрос про веру)
википедию, спецификации
DG>>>что такое storage location? и чем оно отличается для переменной и объекта? S>>Это место для хранения. Переменная представляет собой место для хранения, а объект/значение хранится в этом месте.
DG>если мы делаем new MyObject(), то где здесь переменная и место для хранения?
а здесь нет переменной. Но формально здесь нет и объекта. Ты всего лишь попортил память.
S>>Потому как не знаем все единицы компиляции/модули.
DG>тогда мы должны были как минимум специфицировать (явно или неявно) интерфейс доступа к нашей программе(нашей части), и зафиксировать через какие сообщения в какое время кто и каким образом имеем доступ. DG>также должны были зафиксировать жизненный цикл, инварианты состояний и т.д. DG>мы всё это сделали?
ок, мы можем это сделать.
DG>>>если можем, то значит можем и понять — переменная изменяемая или нет, и в какие промежутки. S>>даже если можем, то только в рамках одного потока выполнения.
DG>мы же вроде были в парадигме ООП, а там нет никаких потоков, а есть интерфейс и сообщения, а также спецификация в какое время какое сообщение должно приниматься.
добро.
S>>И какой в этом смысл кроме издевательства над инкапсуляцией?
DG>например, получить возможность сохранять и восстанавливать состояние программы(или ее части) в произвольный момент времени.
А ее не было до этого? DG>например есть код: DG>
DG>T F()
DG>{
DG> var a = Foo();
DG> var b = Server_Bar();
DG> return a + b;
DG>}
DG>
DG>соответственно, можно автоматически переписать эту программу к виду: DG>
Ее можно автоматически переписать и без того что бы считать переменную рантайм объектом ООП.
DG>>>ты что-то имеешь против ФЯ-шного ООП (или ООП-шного ФЯ)? S>>Нет, я просто говорю что в рамках ФЯ (чистого) тема переменных бессмысленна.
DG>это в смысле использовать модель ФЯ, который чисто списковый. и что в этой модели хорошего? кроме того, что математики могут об этой модели что-то подоказывать?
Не понимаю, что значит чисто списковый. Я говорю о том, что флудить о переменных и их объектных моделях в контексте чистого ФЯ я не собираюсь.
DG>>>сигнализирует или о том, что или в нем есть ошибка (Foo не пересчитывается на основе изменения состояния a) S>>Почему же это ошибка?
DG>потому что в реальных программах — такое поведение встречается с вероятностью 0.001% (условно) DG>соответственно, с вероятностью 99.999% — это ошибка.
посчитать средне-арифметическое значений функции в заданных точках это ошибка с вероятностью 99.999%?
DG>сущность не одна и в этом куске кода. DG>разница в том, что паттерны, которые используют переменные повторно все на перечет, один из таких паттернов — это использование счетчика цикла. остальные использования — это ошибка, или какой-то новый паттерн, который тогда надо ввести.
Т.е. ты предлагаешь поделить весь код на паттерны известные и неизвестные компилятору? И о неизвестных кричать что это ошибка?
DG>>>цикл for определенно закладывается на то, что переменная цикла будет меняться. S>>Понимаешь, когда переменная не меняется, компилятор может сказать, что она не меняется. Как только она стала меняться, компилятор скажет что код заточен под то, что она меняется.
DG>чем это отличается от того, что программист сначала поставил const/readonly на переменную, а потом убрал? DG>или другими словами — какая такая информация есть у программиста, которая ему позволяет так делать, и какой информации не хватает компилятору?
У программиста есть намерение использовать этот объект определенным образом и предотвратить использование его другими способами. А компилятор может только догадываться о том, что хочет программист, причем постфактум. Если у программиста есть намерение сделать объект иммутабельным, но нет способа сказать об этом компилятору, компилятор будет считать объект мутабельным по его использованию.
S>>А если переменные статические?
DG>код требует рефакторинга.
Допустим. Так что скажет компилятор?
DG>>я могу, например, согласиться — что при компиляции нету еще классов и объектов, есть лишь их бледные проекции, потому что это можно проверить и этим можно управлять. и я утверждаю, что эти бледные проекции умеют посылать сообщения и это можно проверить, меняя листинг и получая сообщения на консоле компилятора. S>ты можешь определить идентичность объектов, получая сообщения на консоли компилятора?
с какой-то точностью — да.
S>Точно так же можно раскрутить модель, в которой поле в C++ будет записью в БД или вагоном РЖД. Так что твоя модель ничего не доказывает.
можно. и если она к тому же будет эквивалентной исходной на каком-то подмножестве операций, то это нам позволит утверждать, что C++-программу, которая использует только эти операции, можно напрямую(без введения ВМ) выполнить в БД или с помощью вагонов РЖД.
DG>>если мы делаем new MyObject(), то где здесь переменная и место для хранения? S>а здесь нет переменной. Но формально здесь нет и объекта. Ты всего лишь попортил память.
и каковы границы этого утверждения?
S>Ее можно автоматически переписать и без того что бы считать переменную рантайм объектом ООП.
покажи чем мы ее при этом считаем, и на основании каких утверждений мы переписываем программу.
DG>>потому что в реальных программах — такое поведение встречается с вероятностью 0.001% (условно) DG>>соответственно, с вероятностью 99.999% — это ошибка. S>посчитать средне-арифметическое значений функции в заданных точках это ошибка с вероятностью 99.999%?
и где там вызов функции от изменяемой переменной (кроме вызовов от изменяемой переменной цикла, которая пробегает по заданным точкам)?
DG>>сущность не одна и в этом куске кода. DG>>разница в том, что паттерны, которые используют переменные повторно все на перечет, один из таких паттернов — это использование счетчика цикла. остальные использования — это ошибка, или какой-то новый паттерн, который тогда надо ввести. S>Т.е. ты предлагаешь поделить весь код на паттерны известные и неизвестные компилятору? И о неизвестных кричать что это ошибка?
в первом приближении, да.
DG>>код требует рефакторинга. S>Допустим. Так что скажет компилятор?
скажет, что программа требует рефакторинга, и что откомпилированный результат лучше выбросить, если есть возможность.
S>У программиста есть намерение использовать этот объект определенным образом и предотвратить использование его другими способами. А компилятор может только догадываться о том, что хочет программист, причем постфактум. Если у программиста есть намерение сделать объект иммутабельным, но нет способа сказать об этом компилятору, компилятор будет считать объект мутабельным по его использованию.
программист это решение принял на основании какой-то информации (а не просто потому что так захотела его левая пятка)
соответственно, я еще раз спрашиваю — какая информация есть у программиста, которой нет у компилятора?
Здравствуйте, DarkGray, Вы писали:
DG>так вроде тогда правильный ответ, что надо строить решения на чем-то другом (например, на частичной идентичности), и жизнь сразу наладится. разве нет?
С нетерпением жду новой парадигмы программирования, построенной на частичной идентичности. Она, надо полагать, придёт на смену ООП, которое так требовательно к идентичности.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>С нетерпением жду новой парадигмы программирования, построенной на частичной идентичности. Она, надо полагать, придёт на смену ООП, которое так требовательно к идентичности.
ты лучше ответь на следующее:
DG> можем ли мы одновременно использовать две модели: одна которая утверждает что это идентичные объекты, а другая — что это разные? DG> или другими словами: можем ли мы использовать модель — которая в одной части утверждений считает, что это идентичные объекты, а в другой части утверждений считает, что это неидентичные объекты?
Здравствуйте, DarkGray, Вы писали:
DG>речь идет именно о достаточности. потому что, например, модель вида "здесь используем идентичность, здесь — не используем, а здесь используем частичную идентичность; DG>здесь используем булеву логику, а здесь используем другую логику" включает в себя модель "мы только работаем с объектами с постоянной идентичностью и только с булевой логикой".
А ещё модель машины тьюринга с неизвестным количеством ошибок (то есть при чтении с ленты получаем не тот символ, котроый там записан) включает в себя модель машины тьюринга с нулём ошибок.
Давайте поставим ребром вопрос о достаточности МТ с нулевым количеством ошибок для описания произвольных алгоритмов.
DG>вот этот постулат не понятен. DG>программирование мы используем для того, чтобы решать какие-то задачи в реальном мире, а не само по себе в вакууме.
DG>и соответственно, если мы даже в реальном мире не можем разобраться на многих задачах с идентичностью, а программист утверждает, что он готов решать только задачи, где есть строгая идентичность, то получается — а нафиг нам такое программирование и такой программист, который нам ничем помочь не может?
Налицо передёргивание. Совершенно непонятно, каким это образом вы перешли от строгости модели программирования к её непригодности для решения реальных задач. Если следовать вашей логике, то преобразование Фурье нафиг не нужно, т.к. в нём используется интеграл с бесконечными пределами, а в природе бывают исключительно сигналы конечной длительности.
Да вообще всю математику нужно выкинуть на помойку, т.к. она оперирует исключительно идеальными объектами, в то время, как в жизни у нас ничего идеального заведомо нет.
Если же перестать заниматься демагогией, то станет понятно, что для программного решения задачи совершенно нет нужды моделировать недостатки реального мира.
DG>потому что программирование это перевод реальности в модель. соответственно, если в реальности нет строгой идентичности между объектами, то откуда она появится в модели?
Зададим, и появится. Зачем вы пишете этот бред? У нас нет нужды создать копию машины на молекулярном уровне внутри компьютера.
У нас есть задача автоматизировать некоторые действия. С точки зрения сервиса по прокату автомобилей, все автомобили в пределах одного класса эквивалентны. Тем не менее, конкретный автомобиль, выданный вам в начале срока проката, будет вполне себе идентичен только самому себе при возврате в конце срока проката. Независимо от наличия либо отсутствия царапин.
Попробуйте для эксперимента вернуть не тот автомобиль, привлекая ваши философские экзерсисы типа "автомобиль сегодня не может быть идентичен автомобилю вчера, ибо нельзя войти дважды в одну и ту же реку".
DG>можем ли мы одновременно использовать две модели: одна которая утверждает что это идентичные объекты, а другая — что это разные?
Что значит "одновременно использовать две модели"? Объект входит ровно в одну модель. Если вам хочется построить другую модель — на здоровье, в ней будут другие объекты, в общем случае никак не связанные с объектами в первой модели. DG>или другими словами: можем ли мы использовать модель — которая в одной части утверждений считает, что это идентичные объекты, а в другой части утверждений считает, что это неидентичные объекты?
Нет, не можем. По определению идентичности. Как вы себе представляете "одну часть" и "другую часть" утверждений, если сама по себе идентичность — это ровно одно отношение?
DG>так я тебе сразу говорил, что про эквивалентность можно лишь говорить на каком-то наборе операций, и что стоит это сразу оговаривать. В данном случае, ты рассматриваешь эквивалентность лишь на наборе безопасных операций.
Давайте введём в студию формальное определение "эквивалентности на наборе операций". Лично мне это словосочетание непонятно.
Для эквивалентности необходимо и достаточно ровно одной операции: процедуры сравнения объектов.
DG>но ты не стал это слушать, а начал бегать с шашкой и кричать: что в моем любимом языке можно утверждать, что переменная и ссылка — эквивалентны всегда безотносительно набора операций.
Я не делал такого утверждения. Я говорил, что имя переменной и переменная — не одно и то же.
DG>соответственно, я также утверждаю, что переменные и объекты эквиваленты между собой на "безопасном"-наборе: получить/записать значение
К сожалению, это утверждение всё ещё легко опровергнуть. Я уже давно показал пример, в котором есть одна переменная, и два объекта. Очевидно, что, т.к. объекты не эквивалентны между собой, то и переменной они эквивалентны быть не могут.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
S>>ты можешь определить идентичность объектов, получая сообщения на консоли компилятора?
DG>с какой-то точностью — да.
Продемонстрируй, как будет выглядеть проверка с помощью консоли компилятора идентичности объектов, на которые ссылаются a и b.
DG>можно. и если она к тому же будет эквивалентной исходной на каком-то подмножестве операций, то это нам позволит утверждать, что C++-программу, которая использует только эти операции, можно напрямую(без введения ВМ) выполнить в БД или с помощью вагонов РЖД.
Но такая модель не делает поле объекта вагоном.
DG>>>если мы делаем new MyObject(), то где здесь переменная и место для хранения? S>>а здесь нет переменной. Но формально здесь нет и объекта. Ты всего лишь попортил память.
DG>и каковы границы этого утверждения?
Оно справедливо в границах ООП в том случае если конструктор прямо или косвенно не записал this куда-нибудь. ООП не рассматривает объекты, которым нельзя отправить сообщение либо проверить идентичность.
S>>Ее можно автоматически переписать и без того что бы считать переменную рантайм объектом ООП.
DG>покажи чем мы ее при этом считаем, и на основании каких утверждений мы переписываем программу.
Мы ее ничем не считам. Допустим, что мы можем наблюдать узел AST, который может превратиться в переменную. Но нет никаких оснований считать что узел АСТ имеет какое-то отношение к некой переменной, особенно ввиду того, что сей узел будет заменен на кусок АСТ, представляющий обращение к некому кэшу.
DG>>>потому что в реальных программах — такое поведение встречается с вероятностью 0.001% (условно) DG>>>соответственно, с вероятностью 99.999% — это ошибка. S>>посчитать средне-арифметическое значений функции в заданных точках это ошибка с вероятностью 99.999%?
DG>и где там вызов функции от изменяемой переменной (кроме вызовов от изменяемой переменной цикла, которая пробегает по заданным точкам)?
Например, вызов функции суммирования агрегата с очередным значением.
S>>Т.е. ты предлагаешь поделить весь код на паттерны известные и неизвестные компилятору? И о неизвестных кричать что это ошибка? DG>в первом приближении, да.
О втором приближении боюсь спрашивать.
DG>>>код требует рефакторинга. S>>Допустим. Так что скажет компилятор?
DG>скажет, что программа требует рефакторинга, и что откомпилированный результат лучше выбросить, если есть возможность.
Выбросить работающий код потому что он не соответствует паттернам, заложенным в компилятор? Боюсь, что немногие будут пользоваться таким компилятором.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
I>
I>A variable is introduced by the declaration of a reference other than a non-static data member or of an
I>object.
S>>Эта цитата не говорит о том что в примере выше две переменных.
I>Эта цитата говорит о том, что объявление ссылки "вводит" (новую) переменную.
Уточни, пожалуйста, оно говорит о каких-то конкретных случаях объявления ссылки, или о всех, включая объявление ссылки на локальную переменную?
S>>У программиста есть намерение использовать этот объект определенным образом и предотвратить использование его другими способами. А компилятор может только догадываться о том, что хочет программист, причем постфактум. Если у программиста есть намерение сделать объект иммутабельным, но нет способа сказать об этом компилятору, компилятор будет считать объект мутабельным по его использованию.
DG>программист это решение принял на основании какой-то информации (а не просто потому что так захотела его левая пятка) DG>соответственно, я еще раз спрашиваю — какая информация есть у программиста, которой нет у компилятора?
Собственно так бывает, что сначала левая пятка программиста захотела сделать объект мутабельным, а потом она же захотела сделать его иммутабельным. Может программист покурил чего до того или после и у программиста появились какие-то соображения. Может его на форуме кто надоумил. Компилятору нужна такая информация?
