Здравствуйте, DarkGray, Вы писали:
S>>Какую именно семантику вы хотите записать? a, в данном контексте, естественно, будет алиасом для x.y.z.
DG>семантику того, что в коде ниже a ведет себя не как алиас для x.y.z, а вот как именно — семантика как раз и может показать.
S>>И вы точно так же не сможете различить их ни в какой функции Compare(x, y).
DG>если допустить, что ты говоришь правду, что это алиас для x.y.z, то следующий код должен выдать true(или 0), а это не так
В C++ это так, если не говорить о C++/CLI с его property расширением, либо о трюках вроде #define y=foo()
S>Это будет означать, что если у объектов нет свойства, позволяющего уверенно их различать, то у них нет идентичности. А поскольку идентичность является свойством самого объекта, а не пары объектов, то она не может то быть, то не быть. Значит, идентичность для объекта o1 — это его свойство, позволяющее нам отличать его от любого другого объекта. Например, мы отличили его от объекта o2. Значит, у o2 идентичность тоже есть. А раз она есть, значит она позволяет отличить и его от любого другого объекта.
в этом рассуждении есть куча логических дыр, как минимум:
во-первых, у пары объектов идентичность легко может появляться или пропадать. хотя бы просто из-за того, что два объекта могут сливаться, а потом опять разделяться. как пример: два бегущих солнечных зайчика навстречу друг другу — будет момент когда они сольются и мы не сможем отличить один от другого, а потом они опять разделятся. и да, если ты опять рассматриваешь с точки зрения небольшой "части мира", например, с точки зрения своего любимого языка в котором объекты не умеют разделяться и объединяться, то сразу это ограничение указывай.
во-вторых, идентичность не является свойством самого по себе объекта. необходимо задать другие объекты, и необходимо задать набор операций на котором проверяется идентичность.
S>Я понимаю, чего вам хочется — объявить идентичностью произвольно выбранное отношение эквивалентности. Так тоже можно делать, но у такого выбора есть малоприятные последствия. В частности, для изменчивых объектов любое отношение эквивалентности либо будет эквивалентно идентичности, либо позволит объекту перебегать из одного класса эквивалентности в другой. Таким образом, объект может утратить определённую таким образом "идентичность".
ты так это говоришь, как будто это что-то плохое, и мы при этом что-то теряем. так что мы при этом теряем? и почему это плохо?
Здравствуйте, DarkGray, Вы писали:
DG>разделяющие их на разные классы эквивалентности с точки зрения кого? и с точки зрения каких операций? это был ключевой вопрос в абзаце на который ты отвечал.
Нет никакой точки зрения. Есть язык с платформой. Они определяют некоторую математическую модель.
Рассуждения о том, что происходит за пределами этой модели, лишены смысла.
Мы говорим о программировании — нас интересует только программа.
Поэтому когда мы говорим об отношении эквивалентности — мы говорим об отношении, выраженном в терминах той же математической модели. То есть, к примеру, булевой функции двух аргументов.
DG>они эквиваленты лишь с точки зрения небольшого кол-ва операций над ними. DG>например, с точки зрения компилятора, resharper-а и т.д. — они не эквиваленты, и можно привести примеры когда эта эквивалентность нарушается с их точки зрения.
Нас не интересует точка зрения решарпера, компилятора, и прочих средств, не имеющих отношения к абстрактной машине, на которой работает программа.
S>>И вы точно так же не сможете различить их ни в какой функции Compare(x, y).
DG>если допустить, что ты говоришь правду, что это алиас для x.y.z, то следующий код должен выдать true(или 0), а это не так DG>
DG>значит это alias для чего-то другого, или a, вообще, не обладает семантикой алиаса
Да ладно! Неужто не выдаёт 0?
А по мне так должен выдавать. Компилятора плюсов под рукой нету. Открой же тайну — как ты определил x.y, и Compare, чтобы нарушить эквивалентность?
DG>пожалуйста. DG>для: DG>
DG>int& GetValue(){int x = 5;return x;}
DG>
DG>следующие два варианта кода обладают разным поведением. один периодически падает, другой нет. DG>
DG>int a = GetValue();
DG>
DG>
DG>int &a = GetValue();
DG>
DG>ты же не говорил, что конструкционную семантику ты выбрасываешь, которая отличается для переменной и ссылки. DG>и что ты считаешь их эквивалентными только с момента их создания.
Конечно же только с момента создания. Я привёл пример кода, определяющего a1 и a2 некоторым конкретным образом. Я не обещал того, что int& вообще всегда будет вести себя всегда как int. Утверждение об эквивалентности типов — совсем другое.
DG>
DG>int a1= 1;
DG>int &a2 = a1;
DG>
DG>или первую строку можно закоментировать, при этом вторая строка со ссылкой не скомпилится, а если закоментировать вторую, то всё будет нормально.
Я не обещал эквивалентности строчек в программе. Я обещал эквивалентность имён a1 и a2, при условии, что имя a2 определено как ... & a2 = a1.
DG>опять же когда ты говорил про эквивалентность, ты не говорил, что ты выкидываешь операции рефакторинга над этими сущностями.
"Операций рефакторинга" над этими сущностями не существует. Операции рефакторинга производятся над программой, а не над тем, с чем она работает.
Если хочется позаниматься ерундой, то можно сразу же сказать, что a2 ни разу не эквивалентно a1, потому что любая утилита текстового сравнения отличит "a1" от "a2". Решарпер и компилятор по отношению к a1 и a2 выступают в роли утилит текстового сравнения.
DG>вообще-то обсуждали эквивалентность. вопрос идентичности появился чуть позже
Когда мы говорим "а это то же самое, что и б", мы, как правило, имеем в виду идентичность.
Тем не менее, даже если хотелось пообсуждать эквивалентность, то вопрос сравнения стоит на первом месте и в ней.
DG>если обсуждается вопрос: эквиваленты ли операции присвоения значения и получения значения из переменных a1, a2 операциям присвоения и получения значения из объектов Variable/RefVariable? то здесь нет нужды еще вводить идентичность Variable/RefVariable
Этот вопрос не обсуждается. Обсуждается вопрос эквивалентности имени переменной и самой переменной. Он плавно перетёк в вопрос эквивалентности ссылки на переменную в С++ и "самой" переменной.
В качестве иллюстрации был приведён якобы эквивалентный код, который не является эквивалентным. И для опровержения этой эквивалентности мне не нужно заниматься трюками вроде привлечения решарпера, раскапывания исходников компилятора, комментирования разных фрагментов кода.
Мне достаточно написать простую функцию, которая работает для одного из этих фрагментов кода, и попросить написать такую же функцию для другого.
DG>вот если перейдем к вопросу обсуждения эквивалентности идентичности для одной пары и для другой, тогда стоит будет ввести.
S>>Я честно предупредил, что будет после того, как вы её добавите. Фактически, предлагаемые вами Variable и RefVariable могут "выглядеть одинаково", при условии, что мы не смотрим на них слишком внимательно (например, пользуемся только GetValue и SetValue). При этом они, очевидно, не "являются одинаковыми" в вашей терминологии. В отличие от имён a1 и a2 в моём примере, которые принадлежат одной и той же переменной.
DG>все эти утверждения зависят от внимательности рассмотрения: и одинаковость a1 и a2, и одинаковость Variable/RefVariable, и эквивалентность переменных и объектов.
DG>и стоит обосновать почему твой взгляд стоит считать самым внимательным.
Я уже обосновал. Отложу продолжение разговора вплоть до написания функции compare, которая отличает a1 от a2. Или хотя бы a от x.y.z.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Но даже согласно этой терминлогии из фразы "and a variable is the name" не следует что "name (a2) is a variable".
I>Тебя сбивают с толку лингвистические различия. "Подумай над этим".
В лингвистике отношение (Is-a) так же известно как "hyponym-hypernym relationship" (отношение частного и общего) или Subsumption(категоризация). Переменная здесь частное, имя — общее. И никак не наоборот.
S>В любом компилируемом языке до сообщения не доходит, т.к. ошибка времени компиляции, а не выполнения.
а ошибка компилятора — это что? знание данное нам свыше что ли? а не сообщение?
и потом ты как-то съехал на компиляторы, хотя на них мир не заканчивается.
DG>>не надо так считать. те же самые обозначения лишь используются для того, чтобы не вводить новых сущностей. S>Т.е. поле (которое на самом деле instance variable) объектом не считается, в отличии от local variable?
поле считается объектом, если мы умеем получать на него прямую ссылку. часто поле имеет ограничение, что оно доступно лишь косвенно через управляющий объект. в этом случается поле тоже можно рассматривать как объект, но придется вводить более сложное понятие — что такое ссылка, и какими свойствами она обладает.
DG>>также ряд понятий (как, например, присваивание) являются неопределяемыми, и можно лишь показать свойства, которыми они обладают. S>Полагаю что в конкретных языках присваивание определяемо. DG>>что в данном случае и показывается. показывается, что работа с переменными не отличима от работы с объектами. DG>>"а если что-то выглядит как кошка, то оно и является кошкой" (c). S>Но отличия есть. См. 1 = 2, &(a + 1), ...
для первого: переменной только на чтение тоже ничего присвоить нельзя.
второе зависит от языка: где-то можно получить ссылку на промежуточнее значения, где-то нельзя, где-то вообще нет понятия ссылки.
S>Опасность в том, что мы отойдем от определения неизменяемого объекта и начнем фантазировать. Придется вводить понятие контекста неизменяемости, т.к. объект не сможет быть неизменяемым в классическом понимании, но раз мы захотим называть его изменяемым, то нужно будет оговариваться, с какого момента он неизменяем, в каком контексте, на протяжении каких вычислений. Неизменяемость будет не атрибутом типа объекта, а атрибутом конкретного экземпляра в конкретных условиях.
почему это важно? почему нам необходимо для всех объектов всё время знать объект изменяем или нет?
почему нам недостаточно это знать (или получить/предоставить гарантию того или иного) только там, где это действительно необходимо, и только на тех операциях, которые нам необходимы.
DG>> тот же оптимизирующий компилятор, или там resharper — так и считает, когда, например, проводит оптимизации или refactoring, и этом им обеспечивает больше возможностей. S>Но для разработчика на стадии написания программы фактическая неизменяемость изменяемых объектов — слишком эфимерное понятие. Особенно, если оно никак не декларируется и не проверяется компилятором.
это противоречит тому, что утверждается, что хороший программист во всю оперирует готовыми паттернами, но при этом подразумевает их в уме, а не отливает каждое применение паттерна в программе в чугуне.
соответственно, immutable object — это такой же паттерн, и нет никакой необходимости его вовсю размечать в программе для того, чтобы им оперировать.
Здравствуйте, DarkGray, Вы писали:
S>>В любом компилируемом языке до сообщения не доходит, т.к. ошибка времени компиляции, а не выполнения.
DG>а ошибка компилятора — это что? знание данное нам свыше что ли? а не сообщение?
Ошибка компилятора это не сообщение в терминах ООП. DG>и потом ты как-то съехал на компиляторы, хотя на них мир не заканчивается.
Это ты съехал на компиляторы, попытавшись съехать на сообщения компиляторов с темы сообщений ООП. Или ты с самого начала подразумевал сообщения в более широком смысле, чем в ООП?
S>>Т.е. поле (которое на самом деле instance variable) объектом не считается, в отличии от local variable?
DG>поле считается объектом, если мы умеем получать на него прямую ссылку. часто поле имеет ограничение, что оно доступно лишь косвенно через управляющий объект. в этом случается поле тоже можно рассматривать как объект, но придется вводить более сложное понятие — что такое ссылка, и какими свойствами она обладает.
тогда как выглядит field=value в терминах setValue? Почему оно должно закончиться?
Для чего вообще нужна объектизация storage location, какие бенефиты она приносит?
DG>>>"а если что-то выглядит как кошка, то оно и является кошкой" (c). S>>Но отличия есть. См. 1 = 2, &(a + 1), ...
DG>для первого: переменной только на чтение тоже ничего присвоить нельзя.
Сначала мы должны отделить понятие переменной от значения, а уж потом определять свойство ее иммутабельности. Т.е. я полагаю что immutable variable прежде всего is a variable. DG>второе зависит от языка: где-то можно получить ссылку на промежуточнее значения, где-то нельзя, где-то вообще нет понятия ссылки.
А где-то нет понятия "переменной", а за него "name binding". В таком случае name — это тоже объект?
S>>Опасность в том, что мы отойдем от определения неизменяемого объекта и начнем фантазировать. Придется вводить понятие контекста неизменяемости, т.к. объект не сможет быть неизменяемым в классическом понимании, но раз мы захотим называть его изменяемым, то нужно будет оговариваться, с какого момента он неизменяем, в каком контексте, на протяжении каких вычислений. Неизменяемость будет не атрибутом типа объекта, а атрибутом конкретного экземпляра в конкретных условиях.
DG>почему это важно? почему нам необходимо для всех объектов всё время знать объект изменяем или нет? DG>почему нам недостаточно это знать (или получить/предоставить гарантию того или иного) только там, где это действительно необходимо, и только на тех операциях, которые нам необходимы.
А почему важно знать тип объекта? Не компилятору, решарперу, а разработчикам!
S>>Но для разработчика на стадии написания программы фактическая неизменяемость изменяемых объектов — слишком эфимерное понятие. Особенно, если оно никак не декларируется и не проверяется компилятором.
DG>это противоречит тому, что утверждается, что хороший программист во всю оперирует готовыми паттернами, но при этом подразумевает их в уме, а не отливает каждое применение паттерна в программе в чугуне. DG>соответственно, immutable object — это такой же паттерн, и нет никакой необходимости его вовсю размечать в программе для того, чтобы им оперировать.
Тогда и статическую типизацию можно подразумевать в уме. Нет никакой необходимости размечать программу типами.
S>Нет никакой точки зрения. Есть язык с платформой. Они определяют некоторую математическую модель. S>Рассуждения о том, что происходит за пределами этой модели, лишены смысла.
ты ставишь всё с ног на голову.
сначала есть модель, которой мы хотим оперировать, и только потом появляется язык, который нам помогает этой моделью оперировать.
при этом модель самого конкретного языка нас интересует вообще постольку поскольку.
если необходимо, чтобы с точки зрения языка было необходимо, чтобы переменная была не отличима от объекта, то приходится к разрабам языка и говорится: хочу, и они это обеспечивают.
S>Мы говорим о программировании — нас интересует только программа. S>Поэтому когда мы говорим об отношении эквивалентности — мы говорим об отношении, выраженном в терминах той же математической модели. То есть, к примеру, булевой функции двух аргументов.
тогда необходимо обосновать что это достаточно для решения реальных задач. а то иначе это напоминает анекдот, что я здесь ищу, потому что здесь светлее.
на реальных задачах всё очень не просто с идентичностью, а ты сейчас утверждаешь, что готов решать только задачи, где с идентичностью всё ясно. но тогда возникает вопрос, а кто будет и как решать остальные задачи?
возьмем, как пример анонимный чат — там всё еще как-то понятно с точки зрения идентичности сообщений, но с идентичностью субъектов, которые эти сообщения постят — всё очень и очень непросто. но ведь необходимо и эту задачу уметь решать.
или, например, возьмем машину — например, до какой степени машина идентична сама с собой по времени? по какому свойству определяется идентичность? по цвету, по номеру, по царапине на крыле?
или есть даже брать чисто программисткие заморочки — объект хранящийся в базе, он же на сервере, а потом на клиенте — это один и тот же объект? или это три разных?
и т.д.
и на всё это ответ один:
идентичность (и эквивалентность) имеет смысл только с точки зрения конкретной задачи с точки зрения конкретного набора операций и с точки зрения заданного набора объектов.
и соответственно, следствия:
1. два объекта могут одновременно быть эквиваленты (и не эквиваленты)
2. эквивалентность сама по себе нафиг не нужна, и не надо ее вводить, если она не требуется для задачи.
DG>>они эквиваленты лишь с точки зрения небольшого кол-ва операций над ними. DG>>например, с точки зрения компилятора, resharper-а и т.д. — они не эквиваленты, и можно привести примеры когда эта эквивалентность нарушается с их точки зрения. S>Нас не интересует точка зрения решарпера, компилятора, и прочих средств, не имеющих отношения к абстрактной машине, на которой работает программа.
S>>>И вы точно так же не сможете различить их ни в какой функции Compare(x, y).
DG>>если допустить, что ты говоришь правду, что это алиас для x.y.z, то следующий код должен выдать true(или 0), а это не так DG>>
DG>>значит это alias для чего-то другого, или a, вообще, не обладает семантикой алиаса S>Да ладно! Неужто не выдаёт 0? S>А по мне так должен выдавать. Компилятора плюсов под рукой нету. Открой же тайну — как ты определил x.y, и Compare, чтобы нарушить эквивалентность?
вот так, например:
struct X;
struct Y
{
Y(int z):z(z),x(0){}
int z;
X*x;
Y& operator = (const Y&y)
{
Y** py = reinterpret_cast<Y**>(x);
py[0] = new Y(120);
return *this;
}
};
struct X
{
X():y(*new Y(10)), y1(11)
{
y.x = this;
}
Y& y;
Y y1;
};
int _tmain(int argc, _TCHAR* argv[])
{
X x;
int&a = x.y.z;
std::cout << a << ", " << x.y.z << std::endl;
x.y = x.y1;
std::cout << a << ", " << x.y.z << std::endl;
return 0;
}
MS VC выдает
10, 10
10, 120
S>Я уже обосновал. Отложу продолжение разговора вплоть до написания функции compare, которая отличает a1 от a2. Или хотя бы a от x.y.z.
DG>>а ошибка компилятора — это что? знание данное нам свыше что ли? а не сообщение? S>Ошибка компилятора это не сообщение в терминах ООП.
а что это тогда? если в терминах ООП?
если это для тебя невыразимо в терминах ООП, значит ты используешь плохой вариант модели ООП, которая может выражать лишь небольшую часть реальных задач.
DG>>и потом ты как-то съехал на компиляторы, хотя на них мир не заканчивается. S>Это ты съехал на компиляторы, попытавшись съехать на сообщения компиляторов с темы сообщений ООП. Или ты с самого начала подразумевал сообщения в более широком смысле, чем в ООП?
сообщение компилятора есть сообщение ООП.
могу даже так завернуть: сообщение об ошибке компиляции — есть сообщение от объекта 1, отправленное через компилятор о том, что 1 не поддерживает данный вид операций.
и на всякий случай сразу добавлю, что у нас нет возможности отличить — это нам единица шлет сообщения через компилятор или это компилятор нам придумывает сообщения. поэтому оба утверждения одинаково верны.
S>>>Т.е. поле (которое на самом деле instance variable) объектом не считается, в отличии от local variable?
DG>>поле считается объектом, если мы умеем получать на него прямую ссылку. часто поле имеет ограничение, что оно доступно лишь косвенно через управляющий объект. в этом случается поле тоже можно рассматривать как объект, но придется вводить более сложное понятие — что такое ссылка, и какими свойствами она обладает. S>тогда как выглядит field=value в терминах setValue?
допустим так (если поля больше трактуются, как свойства):
class FieldRef
{
FieldRef(T& item, const Field& field)
{
this.item = item;
this.field = field;
}
T &item;
const Field& field;
public void setValue(TValue value)
{
field.setValue(item, value);
}
}
S> Почему оно должно закончиться?
кто должен закончиться?
S>Для чего вообще нужна объектизация storage location, какие бенефиты она приносит?
эта эквивалентность используется при том же МП, например — при оптимизациях, или там при преобразовании обычного кода в cps, и т.д.
например, в C# — это используется для того, чтобы использовать переменные из внешнего контекста внутри делегата.
и компилятор сам автоматически преобразует переменные в объекты
//надуманный пример
Func<int, int> F()
{
int x = 1;
return (value) => {x += value; return x;};
}
S>Сначала мы должны отделить понятие переменной от значения, а уж потом определять свойство ее иммутабельности. Т.е. я полагаю что immutable variable прежде всего is a variable.
либо она immutable, либо она variable — а неизменное изменяемое — это как-то слишком.
DG>>второе зависит от языка: где-то можно получить ссылку на промежуточнее значения, где-то нельзя, где-то вообще нет понятия ссылки. S>А где-то нет понятия "переменной", а за него "name binding". В таком случае name — это тоже объект?
только в очень узких рамках.
так name — это зависимая(относительная) ссылка.
кстати, так переменные из компилируемой среды тоже можно интерпретировать, если есть необходимость.
S>А почему важно знать тип объекта? Не компилятору, решарперу, а разработчикам!
потому что они хотят знать, что можно делать в каждой конкретной строчке кода с данной штуковиной, а что нельзя.
при этом сам по себе тип им нафиг не нужен, а изменяемость/неизменяемость тем более.
им хочется знать что-то более конкретное: например, как получить ФИО человека, и будет ли оно уже отнормированное (например, что оно с большой буквы, что имя с начала, потом фамилия, что оно в именительном падеже и т.д.), или его надо нормировать, и что надо сделать, чтобы вывести только инициалы?
S>>>Но для разработчика на стадии написания программы фактическая неизменяемость изменяемых объектов — слишком эфимерное понятие. Особенно, если оно никак не декларируется и не проверяется компилятором.
поэтому лучше, например, договориться, что объекты, например, не изменяемы вообще (или как-то изменяемы особо) — как это сделали в ФЯ.
и жизнь сразу стала проще.
DG>>это противоречит тому, что утверждается, что хороший программист во всю оперирует готовыми паттернами, но при этом подразумевает их в уме, а не отливает каждое применение паттерна в программе в чугуне. DG>>соответственно, immutable object — это такой же паттерн, и нет никакой необходимости его вовсю размечать в программе для того, чтобы им оперировать. S>Тогда и статическую типизацию можно подразумевать в уме. Нет никакой необходимости размечать программу типами.
в целом, верно. в идеальном мире, компилятор (или IDE) без всякой разметки бы подсказал всё что необходимо знать об объекте. но мир пока неидеален, и компиляторы такое выделение информации из кода делают не охотно, поэтому приходится использовать ручной труд, и размечать самому.
в контексте неизменяемость/изменяемость — компилятор(или ide) могли бы сами подсказать, что мы пытаемся использовать изменяемую переменную, как неизменяемую. или что пытаемся поменять переменную, в то время, когда другой код уже заложился на то, что переменная не будет меняться.
DG>>>а ошибка компилятора — это что? знание данное нам свыше что ли? а не сообщение? S>>Ошибка компилятора это не сообщение в терминах ООП.
DG>а что это тогда? если в терминах ООП?
Я могу представить ООП систему, в которой компилятор шлет сообщения. Но 1 в этой системе не объект. DG>если это для тебя невыразимо в терминах ООП, значит ты используешь плохой вариант модели ООП, которая может выражать лишь небольшую часть реальных задач.
Да, плохой. А хорошую модель ООП ты сам придумал?
DG>>>и потом ты как-то съехал на компиляторы, хотя на них мир не заканчивается. S>>Это ты съехал на компиляторы, попытавшись съехать на сообщения компиляторов с темы сообщений ООП. Или ты с самого начала подразумевал сообщения в более широком смысле, чем в ООП?
DG>сообщение компилятора есть сообщение ООП. DG>могу даже так завернуть: сообщение об ошибке компиляции — есть сообщение от объекта 1, отправленное через компилятор о том, что 1 не поддерживает данный вид операций.
Во время компиляции 1 не является объектом. DG>и на всякий случай сразу добавлю, что у нас нет возможности отличить — это нам единица шлет сообщения через компилятор или это компилятор нам придумывает сообщения. поэтому оба утверждения одинаково верны.
Скорее они одинаково неверны, т.к. идентичности во время компиляции не наблюдаю.
S>>тогда как выглядит field=value в терминах setValue?
DG>допустим так (если поля больше трактуются, как свойства): DG>
Я вижу, ты определил поле с помощью поля и метод setValue через метод T::setValue. Это тавтология.
S>> Почему оно должно закончиться?
DG>кто должен закончиться?
вычисление. Поле при создании присваивает значение полю
S>>Для чего вообще нужна объектизация storage location, какие бенефиты она приносит?
DG>эта эквивалентность используется при том же МП, например — при оптимизациях, или там при преобразовании обычного кода в cps, и т.д.
DG>например, в C# — это используется для того, чтобы использовать переменные из внешнего контекста внутри делегата. DG>и компилятор сам автоматически преобразует переменные в объекты
Это не так. Замыкание трансформирует локальную переменную в поле класса, но никакой объектизации переменной там нет. Как была переменная storage location, так им и осталась. Изменяется лишь ее принадлежность.
S>>Сначала мы должны отделить понятие переменной от значения, а уж потом определять свойство ее иммутабельности. Т.е. я полагаю что immutable variable прежде всего is a variable.
DG>либо она immutable, либо она variable — а неизменное изменяемое — это как-то слишком.
Поле — это переменная класса. Верно? Как только мы его пометили const/readonly, оно перестало быть переменной? А что если не пометили, а просто не стали изменять?
S>>А где-то нет понятия "переменной", а за него "name binding". В таком случае name — это тоже объект?
DG>только в очень узких рамках. DG>так name — это зависимая(относительная) ссылка. DG>кстати, так переменные из компилируемой среды тоже можно интерпретировать, если есть необходимость.
Не понял.
S>>А почему важно знать тип объекта? Не компилятору, решарперу, а разработчикам!
DG>потому что они хотят знать, что можно делать в каждой конкретной строчке кода с данной штуковиной, а что нельзя. DG>при этом сам по себе тип им нафиг не нужен, а изменяемость/неизменяемость тем более.
изменяемость/неизменяемость тоже говорит о том, что можно делать с данной штуковиной.
DG>поэтому лучше, например, договориться, что объекты, например, не изменяемы вообще (или как-то изменяемы особо) — как это сделали в ФЯ. DG>и жизнь сразу стала проще.
Лучше, но мы говорим о том, нафига переменную считать объектом. С ФЯ тут как-то выпадаем из русла обсуждения.
DG>>>соответственно, immutable object — это такой же паттерн, и нет никакой необходимости его вовсю размечать в программе для того, чтобы им оперировать. S>>Тогда и статическую типизацию можно подразумевать в уме. Нет никакой необходимости размечать программу типами.
DG>в целом, верно. в идеальном мире, компилятор (или IDE) без всякой разметки бы подсказал всё что необходимо знать об объекте. но мир пока неидеален, и компиляторы такое выделение информации из кода делают не охотно, поэтому приходится использовать ручной труд, и размечать самому.
В целом и разметка неизменяемости нужна для того что бы улучшить диагностику.
DG>в контексте неизменяемость/изменяемость — компилятор(или ide) могли бы сами подсказать, что мы пытаемся использовать изменяемую переменную, как неизменяемую. или что пытаемся поменять переменную, в то время, когда другой код уже заложился на то, что переменная не будет меняться.
Не пойму, как компилятор может понять что мы используем изменяемую переменную как неизменяемую? или что код заложен на то, что переменная меняться не будет. Как выглядит код, который заложен на то, что переменная меняться будет?
var a = 1;
var b = 2;
Foo();
return a + b;
Что может сказать компилятор/IDE по такому коду? На что он заложен?
Здравствуйте, VladD2, Вы писали:
VD>Да, этот форум стал просто фиеричен. Такие флэймы с такими аллегориями, по такому, казалось бы, прозаичному вопросу.
Только что хотел написать ровно такой же пост. Жесть какая-то, при том, что вполне уважаемые мною форумчане на полном серьезе ломают тут копья.
Люди, одумайтесь, вопрос выеденного яйца не стоит, просто некоторые готовы любую мысль довести до абсурда и и посчитать это философией.
S>Да, плохой. А хорошую модель ООП ты сам придумал?
модель обычная. надо лишь умееть ее видеть в реальности и применять.
DG>>сообщение компилятора есть сообщение ООП. DG>>могу даже так завернуть: сообщение об ошибке компиляции — есть сообщение от объекта 1, отправленное через компилятор о том, что 1 не поддерживает данный вид операций. S>Во время компиляции 1 не является объектом.
ты можешь это проверить? доказать?
S>Я вижу, ты определил поле с помощью поля и метод setValue через метод T::setValue. Это тавтология.
да. потому что это делается под соусом: допустим мы уже все понимаем, что такое трудно-определимое понятие поле и как оно присваивается, но давайте напишем код (на нем же самом) который продемонстрирует семантику присвоения поля.
это из разряда, что ни кого не удивляет, что компилятор C++ написан на самом же C++.
если же нужна самораскрутка компилятора, то понятие поля можно вводить через списки или массивы, но мне лень, если честно.
S>Это не так. Замыкание трансформирует локальную переменную в поле класса, но никакой объектизации переменной там нет. Как была переменная storage location, так им и осталась. Изменяется лишь ее принадлежность.
по видимому я не понимаю, что такое storage location.
что такое storage location? и чем оно отличается для переменной и объекта?
S>Поле — это переменная класса. Верно? Как только мы его пометили const/readonly, оно перестало быть переменной? А что если не пометили, а просто не стали изменять?
мы можем перечислить тех, кто к полю имеет доступ, и в какое время или нет?
если не можем, то почему?
если можем, то значит можем и понять — переменная изменяемая или нет, и в какие промежутки.
DG>>так name — это зависимая(относительная) ссылка. DG>>кстати, так переменные из компилируемой среды тоже можно интерпретировать, если есть необходимость. S>Не понял.
для переменных в следующем куске кода
void F()
{
int a = 5;
int b = a + 4;
}
можно считать, что это есть пары ключ-значения из словаря F (который создается при старте функции F) с ключами "a" и "b" (или с ключами 0 и 1).
или если мы знаем, что тред один (а из под функции F ни в коем случае F еще раз вызываться не может), то тогда значения a и b можно размещать в глобальном dictionary с ключами "F.a" и "F.b"
и т.д.
S>Лучше, но мы говорим о том, нафига переменную считать объектом. С ФЯ тут как-то выпадаем из русла обсуждения.
ты что-то имеешь против ФЯ-шного ООП (или ООП-шного ФЯ)?
DG>>>>соответственно, immutable object — это такой же паттерн, и нет никакой необходимости его вовсю размечать в программе для того, чтобы им оперировать. S>>>Тогда и статическую типизацию можно подразумевать в уме. Нет никакой необходимости размечать программу типами.
DG>>в целом, верно. в идеальном мире, компилятор (или IDE) без всякой разметки бы подсказал всё что необходимо знать об объекте. но мир пока неидеален, и компиляторы такое выделение информации из кода делают не охотно, поэтому приходится использовать ручной труд, и размечать самому. S>В целом и разметка неизменяемости нужна для того что бы улучшить диагностику.
S>Не пойму, как компилятор может понять что мы используем изменяемую переменную как неизменяемую? S>или что код заложен на то, что переменная меняться не будет.
например, код вида
int a = GetValue1();
var r= Foo(a);
a = GetValue2();
var r2 = Bar(a);
return r + r2;
сигнализирует или о том, что или в нем есть ошибка (Foo не пересчитывается на основе изменения состояния a), или он требует рефакторинга (нарушается правило, что переменная должна использоваться лишь для хранения одной сущности)
S> Как выглядит код, который заложен на то, что переменная меняться будет?
цикл for определенно закладывается на то, что переменная цикла будет меняться.
S>
S>var a = 1;
S>var b = 2;
S>Foo();
S>return a + b;
S>
S>Что может сказать компилятор/IDE по такому коду? На что он заложен?
для начала код требует рефакторинга — зачем-то искусственно увеличено время жизни переменных a и b, хотя они используются только в конце программы.
можно сказать, что переменные immutable, каких-то сомнительных зависимостей нет
Здравствуйте, DarkGray, Вы писали:
S>>Да, плохой. А хорошую модель ООП ты сам придумал?
DG>модель обычная. надо лишь умееть ее видеть в реальности и применять.
Я не вижу как обычную модель ООП можно применить к сущностям времени выполнения во время компиляции.
DG>>>сообщение компилятора есть сообщение ООП. DG>>>могу даже так завернуть: сообщение об ошибке компиляции — есть сообщение от объекта 1, отправленное через компилятор о том, что 1 не поддерживает данный вид операций. S>>Во время компиляции 1 не является объектом в смысле времени выполнения.
DG>ты можешь это проверить? доказать?
Во время компиляции не работает доставка сообщений, object identity в том смысле, в котором они работают во время выполнения.
S>>Я вижу, ты определил поле с помощью поля и метод setValue через метод T::setValue. Это тавтология.
DG>да. потому что это делается под соусом: допустим мы уже все понимаем, что такое трудно-определимое понятие поле и как оно присваивается, но давайте напишем код (на нем же самом) который продемонстрирует семантику присвоения поля. DG>это из разряда, что ни кого не удивляет, что компилятор C++ написан на самом же C++.
DG>если же нужна самораскрутка компилятора, то понятие поля можно вводить через списки или массивы, но мне лень, если честно.
Я понимаю, что такое самораскрутка компилятора. Но не очень представляю себе как семантика поля может быть продемонстрирована с помощью рекурсивного типа данных с отстуствием выхода из рекурсии и рекурсивного метода без выхода из рекурсии в рамках eager языка.
S>>Это не так. Замыкание трансформирует локальную переменную в поле класса, но никакой объектизации переменной там нет. Как была переменная storage location, так им и осталась. Изменяется лишь ее принадлежность.
DG>по видимому я не понимаю, что такое storage location.
Интересно, ты понимаешь слишком широко модель ООП, но не понимаешь терминологии из спецификации языков. DG>что такое storage location? и чем оно отличается для переменной и объекта?
Это место для хранения. Переменная представляет собой место для хранения, а объект/значение хранится в этом месте.
S>>Поле — это переменная класса. Верно? Как только мы его пометили const/readonly, оно перестало быть переменной? А что если не пометили, а просто не стали изменять?
DG>мы можем перечислить тех, кто к полю имеет доступ, и в какое время или нет?
В общем случае нет. DG>если не можем, то почему?
Потому как не знаем все единицы компиляции/модули. DG>если можем, то значит можем и понять — переменная изменяемая или нет, и в какие промежутки.
даже если можем, то только в рамках одного потока выполнения.
DG>>>так name — это зависимая(относительная) ссылка. DG>>>кстати, так переменные из компилируемой среды тоже можно интерпретировать, если есть необходимость. S>>Не понял.
DG>для переменных в следующем куске кода DG>можно считать, что это есть пары ключ-значения из словаря F (который создается при старте функции F) с ключами "a" и "b" (или с ключами 0 и 1). DG>или если мы знаем, что тред один (а из под функции F ни в коем случае F еще раз вызываться не может), то тогда значения a и b можно размещать в глобальном dictionary с ключами "F.a" и "F.b" DG>и т.д.
И какой в этом смысл кроме издевательства над инкапсуляцией?
S>>Лучше, но мы говорим о том, нафига переменную считать объектом. С ФЯ тут как-то выпадаем из русла обсуждения.
DG>ты что-то имеешь против ФЯ-шного ООП (или ООП-шного ФЯ)?
Нет, я просто говорю что в рамках ФЯ (чистого) тема переменных бессмысленна.
S>>Не пойму, как компилятор может понять что мы используем изменяемую переменную как неизменяемую? S>>или что код заложен на то, что переменная меняться не будет.
DG>например, код вида DG>
DG>int a = GetValue1();
DG>var r= Foo(a);
DG>a = GetValue2();
DG>var r2 = Bar(a);
DG>return r + r2;
DG>
DG>сигнализирует или о том, что или в нем есть ошибка (Foo не пересчитывается на основе изменения состояния a)
Почему же это ошибка? DG>, или он требует рефакторинга (нарушается правило, что переменная должна использоваться лишь для хранения одной сущности)
Одной сущности? Так будет одна сущность?
int a = GetValue1(init_value);
var r= Foo(a);
a = GetValue1(a);
var r2 = Bar(a);
return r + r2;
Если не одна, тогда где разница между одной сущностью и не одной, например в цикле со счетчиком?
Если одна, то требует ли этот код рефакторинга? S>> Как выглядит код, который заложен на то, что переменная меняться будет?
DG>цикл for определенно закладывается на то, что переменная цикла будет меняться.
Понимаешь, когда переменная не меняется, компилятор может сказать, что она не меняется. Как только она стала меняться, компилятор скажет что код заточен под то, что она меняется.
S>>
S>>var a = 1;
S>>var b = 2;
S>>Foo();
S>>return a + b;
S>>
S>>Что может сказать компилятор/IDE по такому коду? На что он заложен?
DG>для начала код требует рефакторинга — зачем-то искусственно увеличено время жизни переменных a и b, хотя они используются только в конце программы. DG>можно сказать, что переменные immutable, каких-то сомнительных зависимостей нет
А если переменные статические?
Здравствуйте, DarkGray, Вы писали:
DG>в этом рассуждении есть куча логических дыр, как минимум: DG>во-первых, у пары объектов идентичность легко может появляться или пропадать. хотя бы просто из-за того, что два объекта могут сливаться, а потом опять разделяться. как пример: два бегущих солнечных зайчика навстречу друг другу — будет момент когда они сольются и мы не сможем отличить один от другого, а потом они опять разделятся.
Это всего лишь означает, что солнечные зайчики нельзя трактовать как объекты в ООП.
DG>во-вторых, идентичность не является свойством самого по себе объекта. необходимо задать другие объекты, и необходимо задать набор операций на котором проверяется идентичность.
Нет никакого набора операций для "проверки идентичности". Операция ровно одна — IsIdentic(o1, o2).
Я ещё раз поясню, если непонятно: отношением идентичности является особое отношение эквивалентности. Его особость — в том, что идентичные объекты невозможно различить никаким другим отношением эквивалентности.
DG>ты так это говоришь, как будто это что-то плохое, и мы при этом что-то теряем. так что мы при этом теряем? и почему это плохо?
По определению. Для того, чтобы что-то можно было трактовать как объект ООП, оно должно обладать идентичностью. Причём всегда, а не так, что с утра идентичность была, а в обед её уже нету. Потому, что это означает, что построенные на идентичности решения с утра работают, а после обеда — нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали: DG>ты ставишь всё с ног на голову. DG>сначала есть модель, которой мы хотим оперировать, и только потом появляется язык, который нам помогает этой моделью оперировать. DG>при этом модель самого конкретного языка нас интересует вообще постольку поскольку. DG>если необходимо, чтобы с точки зрения языка было необходимо, чтобы переменная была не отличима от объекта, то приходится к разрабам языка и говорится: хочу, и они это обеспечивают.
Первичность языка или модели совершенно неважна здесь. Важно то, что сейчас язык соответствует модели. И то, о свойствах элементов модели за пределами этой модели рассуждать смысла не имеет.
DG>тогда необходимо обосновать что это достаточно для решения реальных задач. а то иначе это напоминает анекдот, что я здесь ищу, потому что здесь светлее.
С чего вдруг? Мы не говорили о достаточности. Мы говорили только о необходимости.
DG>возьмем, как пример анонимный чат — там всё еще как-то понятно с точки зрения идентичности сообщений, но с идентичностью субъектов, которые эти сообщения постят — всё очень и очень непросто. но ведь необходимо и эту задачу уметь решать.
Не вижу формулировки проблемы. Опять же, нужно понимать, что мы говорим не о реальном мире, а о программировании. Нас вопросы идентичности реальных субъектов вообще никак не интересуют.
DG>или, например, возьмем машину — например, до какой степени машина идентична сама с собой по времени? по какому свойству определяется идентичность? по цвету, по номеру, по царапине на крыле?
И какое отношение это имеет к программированию?
DG>или есть даже брать чисто программисткие заморочки — объект хранящийся в базе, он же на сервере, а потом на клиенте — это один и тот же объект? или это три разных?
Это зависит от выбранной модели. Разве это не очевидно?
DG>и на всё это ответ один: DG>идентичность (и эквивалентность) имеет смысл только с точки зрения конкретной задачи с точки зрения конкретного набора операций и с точки зрения заданного набора объектов.
DG>и соответственно, следствия: DG> 1. два объекта могут одновременно быть эквиваленты (и не эквиваленты)
Именно поэтому отношение идентичности отличают от любого другого отношения эквивалентности. Последних может быть бесконечно много. В том числе и вырожденное отношение Equal(o1, o2) { return true;} вполне себе определяет некоторую эквивалентность. DG> 2. эквивалентность сама по себе нафиг не нужна, и не надо ее вводить, если она не требуется для задачи.
Задач, в которых не нужна никакая эквивалентность, практически не встречается.
S>>Я уже обосновал. Отложу продолжение разговора вплоть до написания функции compare, которая отличает a1 от a2. Или хотя бы a от x.y.z.
DG>жду продолжения
А, не ну если мы будем баловаться с небезопасными фичами C++, то можно сразу же забить на любые рассуждения о свойствах С++ программ.
Чтож, можно считать утверждение "a является алиасом для x.y.z" опровергнутым. Осталось из этого вывести опровержение изначального тезиса о том, что в приведённом мной фрагменте кода есть одна переменная с двумя именами.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, samius, Вы писали:
S>В лингвистике отношение (Is-a) так же известно как "hyponym-hypernym relationship" (отношение частного и общего) или Subsumption(категоризация). Переменная здесь частное, имя — общее. И никак не наоборот.
А это к чему? То, что лингвистика может различать понятия переменная и имя переменной, я не оспариваю. И даже с точки зрения программирования эти два понятия можно различать, но тогда переменная будет означать то же, что объект.
Z>>Люди, одумайтесь, вопрос выеденного яйца не стоит, просто некоторые готовы любую мысль довести до абсурда и и посчитать это философией.
DG>а что стоит обсуждать? что такое Nemerle? и почему то, что он делает следует называть МП?
Казалось бы при чем тут Nemerle.
По существу. Как я заметил, тебе как раз интересно обсуждать, что и как следует называть. Это может быть философским вопросом, но конкретно твои рассуждения по этому поводу контрконструктивны. Я уверен, что ты прекрасно понимаешь собеседника, но регулярно уводишь в лес обсуждения терминов где оттачиваешь демагогию.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>В лингвистике отношение (Is-a) так же известно как "hyponym-hypernym relationship" (отношение частного и общего) или Subsumption(категоризация). Переменная здесь частное, имя — общее. И никак не наоборот.
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.
В этом предложении два утверждения (я не собираюсь оспаривать их истинность пока).
1. О том что объект это частный случай (подкатегория) куска памяти
2. О том что переменная это частный случай имени.
Иэ этих двух утверждений не следует, что переменная означает то же, что объект. Может быть ты не процитировал тот текст, из которого ты сделал такой вывод?
Неформально объект занимает память, а переменная предоставляет ее. Да, объект занимает ту самую память, которую предоставляет переменная. Но повода утверждать что переменная это то же что объект не больше, чем утверждать что банка из под пива тоже самое что и пиво на том основании, что пиво занимает емкость, предоставленную банкой.
Здравствуйте, samius, Вы писали:
S>Нет, не будет переменная означать то же, что объект.
В этом случае не будет, зато в этом случае (C++) имя переменной и переменная означают одно и то же с точки зрения программиста. Все зависит от соглашения, что договариваются называть словом переменная, либо переменная означает то же что объект, либо то же что имя переменной. В C++ никакой разницы между понятиями имя переменной и переменная нет.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Нет, не будет переменная означать то же, что объект.
I>В этом случае не будет, зато в этом случае (C++) имя переменной и переменная означают одно и то же с точки зрения программиста.
Если для тебя это одно и то же, то не надо подписывать сюда программистов в общем случае. Я тоже программист (и в том числе на C++), но различаю эти понятия.
I>Все зависит от соглашения, что договариваются называть словом переменная, либо переменная означает то же что объект, либо то же что имя переменной. В C++ никакой разницы между понятиями имя переменной и переменная нет.
Т.е. ты настаиваешь на каком-то соглашении, но не уверен, на каком именно?
Может дашь ссылку на компетентный источник, в котором бы было приведено такое соглашение? Только не как в прошлый раз, когда тебе пришлось расшифровывать то, о чем там написано с учетом лингвистических особенностей.
Еще раз, объект и переменную различать следует, хотя бы потому, что у них может быть разное время жизни. Переменную и имя переменной тоже следует отличать, т.к. одно может существовать без другого. В частности, в C++ имя существует во время разработки, а переменная — во время исполнения программы.
