S>Переменная в императивных средах — это storage location.

осталось вот только обосновать, почему storage location не является объектом

S>Её семантика такова, что что мы туда положили, то мы и вытащили.

а объект как-то по другому сюда ведет? т.е. это ты так говоришь, как будто это должно противоречить поведению объекта.

S>Имя переменной — это сущность ЯП.

и че? опять же как это мешает переменной быть тоже объектом.

S>Вот, например, в следующем коде — ровно одна переменная:
S>

S>int a1 = 1;
S>int&a2 = a1;
S>

S>А имён у неё две.

тут три объекта: 1, a1 и a2.
один из них — immutable: 1, один из них обладает ссылочной семантикой: a2.

не понятно чем этот код отличается от следующего кода. и почему во втором коде объекты, а в первом нет.
и эквивалентность между вышеуказанным кодом и кодом ниже — обеспечивает компилятор (или интерпретатор), скрывая всю эту кухню.

class Variable
{
  public readonly string name;
  public Variable(string name, int value){this.name = name; this.storage = value;}
   int storage;
  public int getValue(){return storage;}
  public int setValue(int value){this.storage = value;}
}
class RefVariable
{
  public RefVariable(string name, Variable var){this.name = name; this.var = var;}
  public readonly string name;  
  Variable var;
  public int getValue(){return var.getValue();}
  public int setValue(int value){var.setValue(value);}
}

new RefVariable("a2", new Variable("a1", 1))

S>При этом в переменной вовсе не обязан храниться сам объект.

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

S>Например, в следующем коде переменная представляет адрес объекта:
S>

S>typedef MyClass *pMyClass;

S>pMyClass p1 = new MyClass(1);
S>pMyClass &p2 = p1;
S>p2 = new MyClass(2);
S>

S>Здесь по-прежнему два имени, одна переменная, и два объекта. Один из которых "утёк", т.к. переменных, хранящих его адрес, не осталось.

здесь 6 объектов (с различной семантикой)
два immutable: 1, 2, два неименнованых (new MyClass(1) и new MyClass(2)), и два именованных p1 и p2

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

class Variable<T>
{
  public readonly string name;
  public Variable(string name, T value){this.name = name; this.storage = value;}
   T storage;
  public T getValue(){return storage;}
  public T setValue(T value){this.storage = value;}
}

class RefVariable<T>
{
  public RefVariable(string name, Variable<T> var){this.name = name; this.var = var;}
  public readonly string name;  
  Variable<T> var;
  public T getValue(){return var.getValue();}
  public T setValue(T value){var.setValue(value);}
}


new RefVariable<MyClass>("p2", new Variable<MyClass>("p1", new MyClass(1))).setValue(new MyClass(2))

S>ООП-шной идентичности (там идентичность требует различать вообще любые два объекта).

где вводится именная такая идентичность? и как это свойство используется?

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

S>>И особенно переменную от объекта следует отличать в аспекте возможности изменения.

DG>отличать необходимо то, что отличается.
DG>а переменная является частным случаем объекта, и обладает двумя методами(сообщениями) getValue/setValue, и соответственно константная переменная (или readonly-переменная) является immutable-объектом, обладающим одним методом getValue
неожиданный поворот. Ну что же, тогда я настаиваю что следует отличать "объект переменная" от "объекта значения", т.к. они в общем случае обладают различными ответственностями и наборами сообщений.

А если поковыряться, то окажется, что у переменной нет метода getValue, а вместо этого есть обязанность обеспечивать доставку сообщений объекту-значению. setValue тоже может не быть. Так, например, в C++ вместо setValue переменной работают конструкторы копирования/операторы присваивания значений. И работают они не с переменными, а со значениями.

В C# — да, можно считать что у переменной есть setValue. Но в C# нет возможности объявить неизменяемую переменную.

Здравствуйте, DarkGray, Вы писали:
DG>где вводится именная такая идентичность? и как это свойство используется?
В определении.
Используется (совместно с концепцией ссылок) в возможности послать сообщение конкретному объекту, независимо от его внутреннего состояния.

Здравствуйте, DarkGray, Вы писали:
DG>осталось вот только обосновать, почему storage location не является объектом
Для начала нужно как-то определить термин "объект".
DG>а объект как-то по другому сюда ведет?
Смотря какой объект.

DG>тут три объекта: 1, a1 и a2.
DG>один из них — immutable: 1, один из них обладает ссылочной семантикой: a2.
Гм. Опираясь на данные примеры, я могу заключить, что ваше определение термина "объект" эквивалентно определению термина "штуковина", или "сущность". То есть, вы называете объектом всё, что угодно.
Если нет — то жду определения в студии.
Утверждение про ссылочную семантику я вообще не понял. Отвлекаясь от определения объекта и вопроса о том, что же такое a1 и a2, хочу напомнить, что семантика у a1 и a2 совершенно одинаковая.
В C++ приведённый код вводит т.н. alias для a1, т.е. оба имени означают одно и то же.

DG>не понятно чем этот код отличается от следующего кода. и почему во втором коде объекты, а в первом нет.
Давайте вы приведёте определение термина "объект", и мы обсудим, что им является, а что — нет.

DG>и эквивалентность между вышеуказанным кодом и кодом ниже — обеспечивает компилятор (или интерпретатор), скрывая всю эту кухню.
Эквивалентность вышеуказанного кода и кода ниже никакой компилятор не обеспечит, т.к. код неэквивалентен.
В моём коде вы не сможете написать функцию Compare(x, y), которая бы вернула false для a1 и a2, при этом вернув true для a1 и a1.
В вашем коде банальный вызов Equals() расставит всё по своим местам.
А когда вы почините Equals() я вызову ReferenceEquals и снова получу то же, вид сбоку.
И только когда вы почините Equals и введёте непротиворечивую систему определений, мы сможем на примере вашей модели мира обсуждать разницу между переменной, её именем, и объектом, который хранится в этой переменной.

DG>

DG>class Variable
DG>{
DG>  public readonly string name;
DG>  public Variable(string name, int value){this.name = name; this.storage = value;}
DG>   int storage;
DG>  public int getValue(){return storage;}
DG>  public int setValue(int value){this.storage = value;}
DG>}
DG>class RefVariable
DG>{
DG>  public RefVariable(string name, Variable var){this.name = name; this.var = var;}
DG>  public readonly string name;  
DG>  Variable var;
DG>  public int getValue(){return var.getValue();}
DG>  public int setValue(int value){var.setValue(value);}
DG>}

DG>new RefVariable("a2", new Variable("a1", 1))

DG>

S>>При этом в переменной вовсе не обязан храниться сам объект.

DG>опять же ты так это говоришь, как будто это утверждение должно обосновывать почему переменную нельзя считать объектом.

S>>Например, в следующем коде переменная представляет адрес объекта:
S>>

S>>typedef MyClass *pMyClass;

S>>pMyClass p1 = new MyClass(1);
S>>pMyClass &p2 = p1;
S>>p2 = new MyClass(2);
S>>

S>>Здесь по-прежнему два имени, одна переменная, и два объекта. Один из которых "утёк", т.к. переменных, хранящих его адрес, не осталось.

DG>здесь 6 объектов (с различной семантикой)
DG>два immutable: 1, 2, два неименнованых (new MyClass(1) и new MyClass(2)), и два именованных p1 и p2

DG>опять же вышеприведенный код эквивалентен коду ниже, и соответственно стоит обосновать почему ниже объекты есть, а выше нету
DG>

DG>class Variable<T>
DG>{
DG>  public readonly string name;
DG>  public Variable(string name, T value){this.name = name; this.storage = value;}
DG>   T storage;
DG>  public T getValue(){return storage;}
DG>  public T setValue(T value){this.storage = value;}
DG>}

DG>class RefVariable<T>
DG>{
DG>  public RefVariable(string name, Variable<T> var){this.name = name; this.var = var;}
DG>  public readonly string name;  
DG>  Variable<T> var;
DG>  public T getValue(){return var.getValue();}
DG>  public T setValue(T value){var.setValue(value);}
DG>}


DG>new RefVariable<MyClass>("p2", new Variable<MyClass>("p1", new MyClass(1))).setValue(new MyClass(2))

DG>

S>неожиданный поворот. Ну что же, тогда я настаиваю что следует отличать "объект переменная" от "объекта значения",

согласен.


S> т.к. они в общем случае обладают различными ответственностями и наборами сообщений.

их можно считать полиморфными друг другу, тогда они будут обладать одним набором сообщений, но вот поведение — да, будет отличаться.

S>А если поковыряться, то окажется, что у переменной нет метода getValue, а вместо этого есть обязанность обеспечивать доставку сообщений объекту-значению.

можно рассматривать и такую модель, но такая модель требует больше информации для описания (более сложная)

S> setValue тоже может не быть. Так, например, в C++ вместо setValue переменной работают конструкторы копирования/операторы присваивания значений. И работают они не с переменными, а со значениями.

в C++ есть и setValue, и конструктор копирования, одно другому не мешает.
и присвоение выглядит как:

var.setValue(obj.Copy()); //для void setValue(T&value){this.storage = value;}

или так

var.setValueWithCopy(obj); //для void setValueWithCopy(const T&value){this.storage = value.Copy()};

S>В C# — да, можно считать что у переменной есть setValue. Но в C# нет возможности объявить неизменяемую переменную.

есть такое. но при этом никто не мешает считать переменную, которая не меняется, как неизменяемую переменную.

DG>>где вводится именная такая идентичность? и как это свойство используется?
S>В определении.
S>Используется (совместно с концепцией ссылок) в возможности послать сообщение конкретному объекту, независимо от его внутреннего состояния.

стот подчеркнуть где там написано, что требуется различать любые два объекта, как это было указано в цитате ниже

S> идентичность требует различать вообще любые два объекта

зы
отмечу, что из фразы на неформальном ЕЯ(на естественном языке) "объекты необходимо различать" автоматически не следует "любые два объекта должны быть различимы". это обусловленно тем, что ЕЯ оперирует в терминах нечетких логик, и в переводе на четкую логику слово "необходимо" будет означать "желательно; это обеспечит отличие от вырожденного случая".
например, когда прямоугольник определяется как штука с разными сторонами, из этого не следует прямого запрета на то, что квадрат и точка не являются прямоугольниками.

S>Гм. Опираясь на данные примеры, я могу заключить, что ваше определение термина "объект" эквивалентно определению термина "штуковина", или "сущность". То есть, вы называете объектом всё, что угодно.
S>Если нет — то жду определения в студии.

вообще принято, что объект — это само по себе аксиоматическое понятие. все попытки его определить заканчиваются тем, что используются другие слова для описания того же самого.
конструктивный подход для таких неопределяемых понятий требует лишь, чтобы описывались свойства, которыми данное понятие обладает.
соответственно тогда:
объект — неопределяемое понятие, обладающее двумя свойствами:
1. объект имеет поведение (в том числе и вырожденное)
2. с объектом можно общаться посредством сообщений (запрос-ответ), в том числе возможны вырожденные варианты общения: запрос — есть, ответа — нет; запроса — нет, ответ — есть.

S>Утверждение про ссылочную семантику я вообще не понял. Отвлекаясь от определения объекта и вопроса о том, что же такое a1 и a2, хочу напомнить, что семантика у a1 и a2 совершенно одинаковая.
S>В C++ приведённый код вводит т.н. alias для a1, т.е. оба имени означают одно и то же.

они выглядят для нас (как пользователей языка) одним и тем же, но ниоткуда не следует, что они являются одним и тем же. и в лучшем случае, только расковыряв каждый конкретный компилятор мы можем убедиться, что в данном конкретном компиляторе они являются одним и тем же.

зы
отмечу важное отличие — "выглядят для нас одинаковым" от "является одинаковым".
из второго следует, что он для всех является одинаковым (в том числе и для тех, кого мы не знаем и не представляем себе, и это очень сильное утверждение, если мы берем на себя смелость что-то утверждать про тех, кого не знаем и не представляем, и соответственно — должно очень строго доказываться), а из первого — это не следует.

ззы
и кстати, в следующем коде, насколько i является алиасом для x.y.z? и для чего именно он является алиасом? и в каких терминах эту семантику лучше записать?

int &a = x.y.z;

DG>>не понятно чем этот код отличается от следующего кода. и почему во втором коде объекты, а в первом нет.
S>Давайте вы приведёте определение термина "объект", и мы обсудим, что им является, а что — нет.

см. выше.

DG>>и эквивалентность между вышеуказанным кодом и кодом ниже — обеспечивает компилятор (или интерпретатор), скрывая всю эту кухню.
S>Эквивалентность вышеуказанного кода и кода ниже никакой компилятор не обеспечит, т.к. код неэквивалентен.
S>В моём коде вы не сможете написать функцию Compare(x, y), которая бы вернула false для a1 и a2, при этом вернув true для a1 и a1.
S>В вашем коде банальный вызов Equals() расставит всё по своим местам.
S>А когда вы почините Equals() я вызову ReferenceEquals и снова получу то же, вид сбоку.
S>И только когда вы почините Equals и введёте непротиворечивую систему определений, мы сможем на примере вашей модели мира обсуждать разницу между переменной, её именем, и объектом, который хранится в этой переменной.

это дурной тон — высечь то, чего не было в чужом сообщении.
семантика сравнений там не описывалась, потому что она не обсуждалась до этого.
если она требуется для данной дискуссии, я могу ее добавить.

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

S>>неожиданный поворот. Ну что же, тогда я настаиваю что следует отличать "объект переменная" от "объекта значения",

DG>согласен.


S>> т.к. они в общем случае обладают различными ответственностями и наборами сообщений.

DG>их можно считать полиморфными друг другу, тогда они будут обладать одним набором сообщений, но вот поведение — да, будет отличаться.
"Полиморфными друг другу" — это непонятно в отношении объекта и переменной.
Один набор сообщений — это спорно. объект-значение не имеет метода setValue: 1.setValue(2) — что-то нелепое.

S>>А если поковыряться, то окажется, что у переменной нет метода getValue, а вместо этого есть обязанность обеспечивать доставку сообщений объекту-значению.

DG>можно рассматривать и такую модель, но такая модель требует больше информации для описания (более сложная)
Может тогда вообще не стоит делать объект из переменной? Ради чего, собественно?

S>> setValue тоже может не быть. Так, например, в C++ вместо setValue переменной работают конструкторы копирования/операторы присваивания значений. И работают они не с переменными, а со значениями.

DG>в C++ есть и setValue, и конструктор копирования, одно другому не мешает.
DG>и присвоение выглядит как:
DG>

DG>var.setValue(obj.Copy()); //для void setValue(T&value){this.storage = value;}
DG>

DG>или так
DG>

DG>var.setValueWithCopy(obj); //для void setValueWithCopy(const T&value){this.storage = value.Copy()};
DG>

Если поле объекта-переменной тоже считать объектом с методом setValue, то код выше представляет собой бесконечную рекурсию. Оно нам надо?

S>>В C# — да, можно считать что у переменной есть setValue. Но в C# нет возможности объявить неизменяемую переменную.

DG>есть такое. но при этом никто не мешает считать переменную, которая не меняется, как неизменяемую переменную.
Можно, но тогда придется считать неизменяемыми объекты, которые никто не менял по факту, а не по отсутствию возможности его изменения.

Здравствуйте, DarkGray, Вы писали:
DG>вообще принято, что объект — это само по себе аксиоматическое понятие.
Да щас прямо.

DG>конструктивный подход для таких неопределяемых понятий требует лишь, чтобы описывались свойства, которыми данное понятие обладает.
Совершенно верно.

DG>соответственно тогда:
DG>объект — неопределяемое понятие, обладающее двумя свойствами:
DG>1. объект имеет поведение (в том числе и вырожденное)
DG>2. с объектом можно общаться посредством сообщений (запрос-ответ), в том числе возможны вырожденные варианты общения: запрос — есть, ответа — нет; запроса — нет, ответ — есть.
Если честно, я в среднем участвую в подобном ликбезе на тему математических основ ООП на RSDN в среднем ежегодно. Норму на этот год я уже выполнил. Поэтому никакого желания в очередной раз проходить вместе с вами по пути изобретения формальных определений поведения (которое определяется через "общение с объектом"), состояния, и идентичности я не испытываю.


DG>они выглядят для нас (как пользователей языка) одним и тем же, но ниоткуда не следует, что они являются одним и тем же. и в лучшем случае, только расковыряв каждый конкретный компилятор мы можем убедиться, что в данном конкретном компиляторе они являются одним и тем же.
Нет никакой нужды расковыривать компилятор. Если внутри языка они являются одним и тем же — значит, они являются одним и тем же. Это же математика — никакого "самого дела" нет, поэтому вопрос "а на самом деле они идентичны или нет" лишён смысла.
Они идентичны, если для них нельзя ввести отношение эквивалентности, разделяющее их в разне классы эквивалентности.

DG>зы
DG>отмечу важное отличие — "выглядят для нас одинаковым" от "является одинаковым".
Если формализовать эти утверждения, то вы пытаетесь объяснить мне разницу между отношением идентичности и любым другим отношением эквивалентности. Спасибо, я в курсе.

DG>из второго следует, что он для всех является одинаковым (в том числе и для тех, кого мы не знаем и не представляем себе, и это очень сильное утверждение, если мы берем на себя смелость что-то утверждать про тех, кого не знаем и не представляем, и соответственно — должно очень строго доказываться),
Да, мы берём на себя смелость. Я уже предложил вам написать функцию на языке С++, которая введёт такое отношение эквивалентности, чтобы a1 и a2 оказались различными. Чтобы избежать недопонимания: препроцессор не считается.

DG>ззы
DG>и кстати, в следующем коде, насколько i является алиасом для x.y.z? и для чего именно он является алиасом? и в каких терминах эту семантику лучше записать?
DG>

DG>int &a = x.y.z;
DG>

Какую именно семантику вы хотите записать? a, в данном контексте, естественно, будет алиасом для x.y.z.
И вы точно так же не сможете различить их ни в какой функции Compare(x, y).

DG>это дурной тон — высечь то, чего не было в чужом сообщении.
DG>семантика сравнений там не описывалась, потому что она не обсуждалась до этого.
Ну а как можно обсуждать вопросы идентичности, не обсуждая семантику сравнения?

DG>если она требуется для данной дискуссии, я могу ее добавить.
Я честно предупредил, что будет после того, как вы её добавите. Фактически, предлагаемые вами Variable и RefVariable могут "выглядеть одинаково", при условии, что мы не смотрим на них слишком внимательно (например, пользуемся только GetValue и SetValue). При этом они, очевидно, не "являются одинаковыми" в вашей терминологии. В отличие от имён a1 и a2 в моём примере, которые принадлежат одной и той же переменной.

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


DG>отмечу, что из фразы на неформальном ЕЯ(на естественном языке) "объекты необходимо различать" автоматически не следует "любые два объекта должны быть различимы". это обусловленно тем, что ЕЯ оперирует в терминах нечетких логик, и в переводе на четкую логику слово "необходимо" будет означать "желательно; это обеспечит отличие от вырожденного случая".
Это будет означать, что если у объектов нет свойства, позволяющего уверенно их различать, то у них нет идентичности. А поскольку идентичность является свойством самого объекта, а не пары объектов, то она не может то быть, то не быть. Значит, идентичность для объекта o1 — это его свойство, позволяющее нам отличать его от любого другого объекта. Например, мы отличили его от объекта o2. Значит, у o2 идентичность тоже есть. А раз она есть, значит она позволяет отличить и его от любого другого объекта.
Итого, если мы нашли что-то, с чем мы не можем проверить идентичность объекта o1, то это не объект. Или это — не идентичность.
Именно поэтому идентичность в ОО-моделях принято считать универсальной. То есть отношение identity(o1, o2) как минимум определено на всех объектах.

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

DG>например, когда прямоугольник определяется как штука с разными сторонами, из этого не следует прямого запрета на то, что квадрат и точка не являются прямоугольниками.
Если прямоугольник определяется как штука с разными сторонами, то квадрат под него таки не подойдёт. Зато подойдёт треугольник. Именно поэтому никто не определяет прямоугольник таким образом.

S>Один набор сообщений — это спорно. объект-значение не имеет метода setValue: 1.setValue(2) — что-то нелепое.

такое сообщение есть, и оно даже отрабатывается, выдавая ошибку.
можешь сам попробовать написать 1 = 2 в любом языке, в котором '=' означает присвоение

S>Если поле объекта-переменной тоже считать объектом с методом setValue, то код выше представляет собой бесконечную рекурсию. Оно нам надо?

не надо так считать. те же самые обозначения лишь используются для того, чтобы не вводить новых сущностей.
также ряд понятий (как, например, присваивание) являются неопределяемыми, и можно лишь показать свойства, которыми они обладают.
что в данном случае и показывается. показывается, что работа с переменными не отличима от работы с объектами.
"а если что-то выглядит как кошка, то оно и является кошкой" (c).

S>Можно, но тогда придется считать неизменяемыми объекты, которые никто не менял по факту, а не по отсутствию возможности его изменения.

фраза построена так, что мне в ней видится намек на то, что это приведет к чему-то плохому.
это так и есть? но тогда, в чем опасность? или это мне лишь чудится.

тот же оптимизирующий компилятор, или там resharper — так и считает, когда, например, проводит оптимизации или refactoring, и этом им обеспечивает больше возможностей.

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

S>Вот, например, в следующем коде — ровно одна переменная:

S>int a1 = 1;
S>int&a2 = a1;

S>А имён у неё две.

Разве? Согласно терминологии Danny Kalev здесь:

An object in C++ is just a piece of memory, and a variable is the name by which the program refers to an object in the program. Plain and simple!

в твоем примере не одна переменная, а один объект, и не два имени переменной, а две переменные являющиеся именами этого объекта.

То есть остается верным следующее

(имя переменной == переменная) && (переменная != объект)

либо:

(имя переменной != переменная) && (переменная == объект)

В твоем примере имеем первый случай.

Еще раз другими словами: Сущности у нас две, из трех терминов: объект, переменная и имя переменной два будут означать одно и то же. Какие два — зависит от выбранной терминологии.

PS. Я говорю о различиях интересных с точки зрения программирования, а не лингвистики.

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

S>>Один набор сообщений — это спорно. объект-значение не имеет метода setValue: 1.setValue(2) — что-то нелепое.

DG>такое сообщение есть, и оно даже отрабатывается, выдавая ошибку.
DG>можешь сам попробовать написать 1 = 2 в любом языке, в котором '=' означает присвоение
В любом компилируемом языке до сообщения не доходит, т.к. ошибка времени компиляции, а не выполнения.

S>>Если поле объекта-переменной тоже считать объектом с методом setValue, то код выше представляет собой бесконечную рекурсию. Оно нам надо?

DG>не надо так считать. те же самые обозначения лишь используются для того, чтобы не вводить новых сущностей.
Т.е. поле (которое на самом деле instance variable) объектом не считается, в отличии от local variable?

DG>также ряд понятий (как, например, присваивание) являются неопределяемыми, и можно лишь показать свойства, которыми они обладают.
Полагаю что в конкретных языках присваивание определяемо.
DG>что в данном случае и показывается. показывается, что работа с переменными не отличима от работы с объектами.
DG>"а если что-то выглядит как кошка, то оно и является кошкой" (c).
Но отличия есть. См. 1 = 2, &(a + 1), ...

S>>Можно, но тогда придется считать неизменяемыми объекты, которые никто не менял по факту, а не по отсутствию возможности его изменения.

DG>фраза построена так, что мне в ней видится намек на то, что это приведет к чему-то плохому.
DG>это так и есть? но тогда, в чем опасность? или это мне лишь чудится.
Опасность в том, что мы отойдем от определения неизменяемого объекта и начнем фантазировать. Придется вводить понятие контекста неизменяемости, т.к. объект не сможет быть неизменяемым в классическом понимании, но раз мы захотим называть его изменяемым, то нужно будет оговариваться, с какого момента он неизменяем, в каком контексте, на протяжении каких вычислений. Неизменяемость будет не атрибутом типа объекта, а атрибутом конкретного экземпляра в конкретных условиях.
Мы даже на этапе анализа кода не сможем сказать, изменяем ли объект или нет:

if (someCondition)
     b.UpdateState();

DG> тот же оптимизирующий компилятор, или там resharper — так и считает, когда, например, проводит оптимизации или refactoring, и этом им обеспечивает больше возможностей.
Но для разработчика на стадии написания программы фактическая неизменяемость изменяемых объектов — слишком эфимерное понятие. Особенно, если оно никак не декларируется и не проверяется компилятором.

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

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

S>>Вот, например, в следующем коде — ровно одна переменная:

I>

S>>int a1 = 1;
S>>int&a2 = a1;
I>

S>>А имён у неё две.

I>Разве? Согласно терминологии Danny Kalev здесь:

I>

I>An object in C++ is just a piece of memory, and a variable is the name by which the program refers to an object in the program. Plain and simple!

та еще терминология...

I>в твоем примере не одна переменная, а один объект, и не два имени переменной, а две переменные являющиеся именами этого объекта.

Но даже согласно этой терминлогии из фразы "and a variable is the name" не следует что "name (a2) is a variable".

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

I>

I>An object in C++ is just a piece of memory, and a variable is the name by which the program refers to an object in the program. Plain and simple!

Давайте не будем путать беллетристику и computer science.
У Дэнни есть боле формальные определения, не сопровождающиеся ужимками типа "plain and simple"? Если мы посмотрим хотя бы сюда http://en.wikipedia.org/wiki/Variable_(programming), то окажется, что есть переменные (variable), а есть отдельные от них имена (variable identifier).

В данном случае как раз два идентификатора обозначают одну и ту же переменную.


I>Еще раз другими словами: Сущности у нас две, из трех терминов: объект, переменная и имя переменной два будут означать одно и то же. Какие два — зависит от выбранной терминологии.
Я показал два примера, из которых вам должно стать понятно, чем объект отличается от переменной, а переменная — от её имени. Все приведённые различия интересны с точки зрения программирования.

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

S>Мы даже на этапе анализа кода не сможем сказать, изменяем ли объект или нет:
S>

S>if (someCondition)
S>     b.UpdateState();
S>

Вот-вот. Такая "казуальная иммутабельность" не имеет практического смысла, т.к. из неё нельзя сделать никаких выводов.

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

S>Но даже согласно этой терминлогии из фразы "and a variable is the name" не следует что "name (a2) is a variable".

Тебя сбивают с толку лингвистические различия. "Подумай над этим".

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

S>Я показал два примера, из которых вам должно стать понятно, чем объект отличается от переменной, а переменная — от её имени. Все приведённые различия интересны с точки зрения программирования.

Прошу прощения, заметив ошибку в первом примере, я не стал читать второго, а зря, потому-что там есть куда более очевидная ошибка:

S>При этом в переменной вовсе не обязан храниться сам объект.
S>Например, в следующем коде переменная представляет адрес объекта:

S>typedef MyClass *pMyClass;

S>pMyClass p1 = new MyClass(1);
S>pMyClass &p2 = p1;
S>p2 = new MyClass(2);

S>Здесь по-прежнему два имени, одна переменная, и два объекта. Один из которых "утёк", т.к. переменных, хранящих его адрес, не осталось.

На самом деле здесь три объекта, поскольку указатель тоже объект. Переменных здесь две (одна из них ссылочная). Цитата из стандарта:

A variable is introduced by the declaration of a reference other than a non-static data member or of an
object.

S>Если честно, я в среднем участвую в подобном ликбезе на тему математических основ ООП на RSDN в среднем ежегодно. Норму на этот год я уже выполнил. Поэтому никакого желания в очередной раз проходить вместе с вами по пути изобретения формальных определений поведения (которое определяется через "общение с объектом"), состояния, и идентичности я не испытываю.

либо — это были плодотворные дискуссии, и значит ты сейчас можешь быстро в трех словах сформулировать свое конструктивное мнение по этому вопросу, либо — это была демагогия ни о чем, тогда у тебя есть возможность сейчас подисскутировать с умным человеком на эту тему.


DG>>они выглядят для нас (как пользователей языка) одним и тем же, но ниоткуда не следует, что они являются одним и тем же. и в лучшем случае, только расковыряв каждый конкретный компилятор мы можем убедиться, что в данном конкретном компиляторе они являются одним и тем же.
S>Нет никакой нужды расковыривать компилятор. Если внутри языка они являются одним и тем же — значит, они являются одним и тем же. Это же математика — никакого "самого дела" нет, поэтому вопрос "а на самом деле они идентичны или нет" лишён смысла.
S>Они идентичны, если для них нельзя ввести отношение эквивалентности, разделяющее их в разне классы эквивалентности.

разделяющие их на разные классы эквивалентности с точки зрения кого? и с точки зрения каких операций? это был ключевой вопрос в абзаце на который ты отвечал.
они эквиваленты лишь с точки зрения небольшого кол-ва операций над ними.
например, с точки зрения компилятора, resharper-а и т.д. — они не эквиваленты, и можно привести примеры когда эта эквивалентность нарушается с их точки зрения.

DG>>

DG>>int &a = x.y.z;
DG>>

S>Какую именно семантику вы хотите записать? a, в данном контексте, естественно, будет алиасом для x.y.z.

семантику того, что в коде ниже a ведет себя не как алиас для x.y.z, а вот как именно — семантика как раз и может показать.

S>И вы точно так же не сможете различить их ни в какой функции Compare(x, y).

если допустить, что ты говоришь правду, что это алиас для x.y.z, то следующий код должен выдать true(или 0), а это не так

int&a = x.y.z;
x.y = x.y1;
Compare(a, x.y.z);

значит это alias для чего-то другого, или a, вообще, не обладает семантикой алиаса



DG>>зы
DG>>отмечу важное отличие — "выглядят для нас одинаковым" от "является одинаковым".
S>Если формализовать эти утверждения, то вы пытаетесь объяснить мне разницу между отношением идентичности и любым другим отношением эквивалентности. Спасибо, я в курсе.

DG>>из второго следует, что он для всех является одинаковым (в том числе и для тех, кого мы не знаем и не представляем себе, и это очень сильное утверждение, если мы берем на себя смелость что-то утверждать про тех, кого не знаем и не представляем, и соответственно — должно очень строго доказываться),
S>Да, мы берём на себя смелость. Я уже предложил вам написать функцию на языке С++, которая введёт такое отношение эквивалентности, чтобы a1 и a2 оказались различными. Чтобы избежать недопонимания: препроцессор не считается.

пожалуйста.
для:

int& GetValue(){int x = 5;return x;}

следующие два варианта кода обладают разным поведением. один периодически падает, другой нет.

int a = GetValue();

int &a = GetValue();

ты же не говорил, что конструкционную семантику ты выбрасываешь, которая отличается для переменной и ссылки.
и что ты считаешь их эквивалентными только с момента их создания.

int a1= 1;
int &a2 = a1;

или первую строку можно закоментировать, при этом вторая строка со ссылкой не скомпилится, а если закоментировать вторую, то всё будет нормально.
опять же когда ты говорил про эквивалентность, ты не говорил, что ты выкидываешь операции рефакторинга над этими сущностями.

т.е. ты рассматриваешь эквивалентность переменной и ссылки лишь на небольшом "части мира" — и это стоит осознавать, проговаривать и уж тем более признавать.

DG>>это дурной тон — высечь то, чего не было в чужом сообщении.
DG>>семантика сравнений там не описывалась, потому что она не обсуждалась до этого.
S>Ну а как можно обсуждать вопросы идентичности, не обсуждая семантику сравнения?

вообще-то обсуждали эквивалентность. вопрос идентичности появился чуть позже

если обсуждается вопрос: эквиваленты ли операции присвоения значения и получения значения из переменных a1, a2 операциям присвоения и получения значения из объектов Variable/RefVariable? то здесь нет нужды еще вводить идентичность Variable/RefVariable
вот если перейдем к вопросу обсуждения эквивалентности идентичности для одной пары и для другой, тогда стоит будет ввести.

DG>>если она требуется для данной дискуссии, я могу ее добавить.
S>Я честно предупредил, что будет после того, как вы её добавите. Фактически, предлагаемые вами Variable и RefVariable могут "выглядеть одинаково", при условии, что мы не смотрим на них слишком внимательно (например, пользуемся только GetValue и SetValue). При этом они, очевидно, не "являются одинаковыми" в вашей терминологии. В отличие от имён a1 и a2 в моём примере, которые принадлежат одной и той же переменной.

все эти утверждения зависят от внимательности рассмотрения: и одинаковость a1 и a2, и одинаковость Variable/RefVariable, и эквивалентность переменных и объектов.

и стоит обосновать почему твой взгляд стоит считать самым внимательным.