S>Можно продолжить, что всевозможные строки это один объект, т.к. могут быть получены из пустой строки путем добавления значения, равного заданной строке.
область значений объекта в рамках object identity имеет низкую значимость. соответственно, из такого предположения никаких интересных выводов сделать невозможно.
с точки зрения object identity важна, в первую очередь, трасса объекта: на что и как влияет объект в какой момент времени.
S>>>Я не даю определения тем вещам, которым они уже даны не мной.
DG>>в мире для одного и того же слова, есть сотни, а то и тысячи определений с разным уровнем точности, соответственно как минимум ты обязан зафиксировать какое именно определение используешь и на каком уровне точности. S>Тут разве не было ссылки на определение ООП идентичности ?
определения в виде остенсивного термина точно не было.
в лучшем случае было: что для такой-то системы в качестве object identity можно взять вот такую штуку.
DG>>опять же как только выписываются все определения, то выясняется что никакого противоречия нет. S>Никакого противоречия тому что всевозможные строки идентичны?
где вся логическая цепочка: определения, выводы, противоречие?
в данной фразе я вижу только следующую цепочку: допустим что все строки идентичны, а такого не может потому что не может быть никогда: получили противоречие.
но во-первых само по себе доказательство какое-то странное, а во вторых даже если допустить что доказательство верное, то получается что не надо лишь делать допущение, что все строки идентичны.
DG>>здесь есть две плоскости (две модели) — версионная и не версионная. DG>>с точки зрения модели, которая не знает что такое версионность — функция идентичности считает объект одним и тем же, если совпадает идентичность объекта(из модели версионной) и версия объекта(из модели версионной), при этом эта модель считает две версии объекта совершенно разными объектами, которые никак между собой не связаны, что неудобно при рассмотрении многих сценариев. S>Ты уже приводил определение идентичности версионной модели?
для начала стоит зафиксировать, что такое object identity в ООП вообще:
object identity — это аксиоматическое(неопределяемое) понятие, которое можно описать как, эта штука, которая определяет что объект является сам собой. отмечу, что в науке термин неопределяемое понятие, это такое понятие, которое не может быть выражено через более простые(базовые) понятия.
в рамках дискуссии object identity удобно ввести через другое неопределяемое понятие "ссылка" (штука, через которую мы общаемся с объектом): object identity — есть функция, которая для двух ссылок возвращает true, если объект является тем же самым.
для версионной модели — такая функция в дополнении к true, возвращает еще какая перед нами версия, и является ли она актуальной.
S>А ты можешь ответить на вопрос, является ли объект предыдущим состоянием некого объекта, или это самостоятельный объект?
конечно, в рамках конкретной задачи, когда зафиксировано что из чего хотели получить.
S>Это значит что никогда не ясно, является ли string объектом, или неактуальной версией какого-то объекта?
ты это так говоришь, как будто это нарушает какой-то фундаментальный закон.
тут можно провести полную аналогию со светом, про который тоже никогда не ясно — частица он или волна.
всё относительно.
S>>>У меня нет сомнений. Я вижу что твои определения и примеры несовместимы с традиционным ООП.
DG>>опять религиозный догматический вывод. для полного образа тебе еще не хватает криков "сжечь еретика на костре!. S>Почему догматический? Идентичность строк с одним значением + сохранение идентичности при операции "+" влечет идентичность всевозможных строк вне зависимости от их происхождения по твоим определениям.
нет, же конечно. область значений имеет очень отдаленное отношение к идентичности.
если так же рассуждать, то выяснится, что в .net-е все объекты одинаковы, потому что адрес объекта из-за gc может принимать все значения за время жизни объекта.
S> Идентичность строк с одним значением + сохранение идентичности при операции "+" влечет идентичность всевозможных строк
переход не верен.
первая часть утверждения говорит про идентичность экземпляра объекта: операция '+' сохраняет идентичность переданного ей экземпляра объекта, вторая же часть — говорит про область значений.
и вот эту монолитность можно увидеть, только если аккуратно формулировать определения и аккуратно делать выкладки.
Здравствуйте, DarkGray, Вы писали:
S>>Можно продолжить, что всевозможные строки это один объект, т.к. могут быть получены из пустой строки путем добавления значения, равного заданной строке.
DG>область значений объекта в рамках object identity имеет низкую значимость. соответственно, из такого предположения никаких интересных выводов сделать невозможно.
Можно сделать вывод о том что ты не можешь отличать строковые объекты, т.к. они все идентичны. DG>с точки зрения object identity важна, в первую очередь, трасса объекта: на что и как влияет объект в какой момент времени.
С точки зрения identity важно уметь отличать объекты. Если ты их не можешь отличать, то трасса не нужна.
S>>Тут разве не было ссылки на определение ООП идентичности ?
DG>определения в виде остенсивного термина точно не было. DG>в лучшем случае было: что для такой-то системы в качестве object identity можно взять вот такую штуку.
Устроит? http://en.wikipedia.org/wiki/Identity_%28object-oriented_programming%29
An identity in object-oriented programming, object-oriented design and object-oriented analysis describes the property of objects that distinguishes them from other objects.
DG>>>опять же как только выписываются все определения, то выясняется что никакого противоречия нет. S>>Никакого противоречия тому что всевозможные строки идентичны?
DG>где вся логическая цепочка: определения, выводы, противоречие?
определения использованы твои. В частности об идентичности двух строк с одинаковым значением и сохранением идентичности операции сложения. Вывод я выделил выше (о том что всевозможные строки есть один объект). Противоречит определению ООП идентичности.
DG>в данной фразе я вижу только следующую цепочку: допустим что все строки идентичны, а такого не может потому что не может быть никогда: получили противоречие.
Это не допустим, что они идентичны. Это вывод из твоих определений. DG>но во-первых само по себе доказательство какое-то странное, а во вторых даже если допустить что доказательство верное, то получается что не надо лишь делать допущение, что все строки идентичны.
это не допущение, а следствие из твоих определений.
Если хочешь — сделай утверждение что в рамках твоих определений две строки с различным содержанием — разные объекты, и я докажу тебе с учетом транзитивности идентичности по твоим определениям это не так.
S>>Ты уже приводил определение идентичности версионной модели?
DG>для начала стоит зафиксировать, что такое object identity в ООП вообще: DG>object identity — это аксиоматическое(неопределяемое) понятие, которое можно описать как, эта штука, которая определяет что объект является сам собой. отмечу, что в науке термин неопределяемое понятие, это такое понятие, которое не может быть выражено через более простые(базовые) понятия. DG>в рамках дискуссии object identity удобно ввести через другое неопределяемое понятие "ссылка" (штука, через которую мы общаемся с объектом): object identity — есть функция, которая для двух ссылок возвращает true, если объект является тем же самым. DG>для версионной модели — такая функция в дополнении к true, возвращает еще какая перед нами версия, и является ли она актуальной.
Туманное дополнение. И что же такое актуальность версии? Когда версии становятся неактуальными? Твоя идентичность динамическая? Т.е. со временем она может меняться? Если да, то это противоречит определению ООП идентичности, в частности тому, что идентичность объекта сохраняется все его время жизни.
S>>А ты можешь ответить на вопрос, является ли объект предыдущим состоянием некого объекта, или это самостоятельный объект? DG>конечно, в рамках конкретной задачи, когда зафиксировано что из чего хотели получить.
если эта конкретная задача является частью другой задачи, то твой ответ не будет справедлив для другой задачи. Не смущает?
S>>Это значит что никогда не ясно, является ли string объектом, или неактуальной версией какого-то объекта?
DG>ты это так говоришь, как будто это нарушает какой-то фундаментальный закон. DG>тут можно провести полную аналогию со светом, про который тоже никогда не ясно — частица он или волна. DG>всё относительно.
Понятно. Т.е. когда тебе удобно, она объект, когда нет — версия. И всегда можно доказать что она и то и другое.
S>>>>У меня нет сомнений. Я вижу что твои определения и примеры несовместимы с традиционным ООП.
DG>>>опять религиозный догматический вывод. для полного образа тебе еще не хватает криков "сжечь еретика на костре!. S>>Почему догматический? Идентичность строк с одним значением + сохранение идентичности при операции "+" влечет идентичность всевозможных строк вне зависимости от их происхождения по твоим определениям.
DG>нет, же конечно. область значений имеет очень отдаленное отношение к идентичности. DG>если так же рассуждать, то выяснится, что в .net-е все объекты одинаковы, потому что адрес объекта из-за gc может принимать все значения за время жизни объекта.
За время жизни объекта — да, но не одновременно. Точно так же мутабельная строка за время жизни может принимать любые значения. И она ничего не нарушает в ООП идентичности.
S>> Идентичность строк с одним значением + сохранение идентичности при операции "+" влечет идентичность всевозможных строк
DG>переход не верен. DG>первая часть утверждения говорит про идентичность экземпляра объекта: операция '+' сохраняет идентичность переданного ей экземпляра объекта, вторая же часть — говорит про область значений.
Про область значений говорит другое твое определение, согласно которому все строки с одинаковым значением считаются одним объектом. DG>и вот эту монолитность можно увидеть, только если аккуратно формулировать определения и аккуратно делать выкладки.
Аккуратно как ты?
DG>>область значений объекта в рамках object identity имеет низкую значимость. соответственно, из такого предположения никаких интересных выводов сделать невозможно. S>Можно сделать вывод о том что ты не можешь отличать строковые объекты, т.к. они все идентичны.
нельзя сделать такой вывод.
я умею отличать трассы, а этого достаточно для идентификации объекта.
DG>>с точки зрения object identity важна, в первую очередь, трасса объекта: на что и как влияет объект в какой момент времени. S>С точки зрения identity важно уметь отличать объекты. Если ты их не можешь отличать, то трасса не нужна.
я утверждаю, что если трасса разная, то это разные объекты. ты же говоришь, что трасса не нужна, потому что это не дает отличия.
что значит "трасса не нужна", если как раз она и определяет одинаковость объектов?
S>An identity in object-oriented programming, object-oriented design and object-oriented analysis describes the property of objects that distinguishes them from other objects.
утверждение "давай отличать объекты по их трассам" подходит под данное определение, и никакого противоречия не возникает.
с чем ты тогда не согласен?
DG>>>>опять же как только выписываются все определения, то выясняется что никакого противоречия нет. S>>>Никакого противоречия тому что всевозможные строки идентичны?
DG>>где вся логическая цепочка: определения, выводы, противоречие? S>определения использованы твои. В частности об идентичности двух строк с одинаковым значением и сохранением идентичности операции сложения. Вывод я выделил выше (о том что всевозможные строки есть один объект). Противоречит определению ООП идентичности.
во-первых: какому слову из твоего определения это противоречит, и в чем?
во-вторых, еще раз повторю, что операция "+" сохраняет идентичность не произвольного объекта, а только того, который ей передали в данной конкретной программе.
DG>>в данной фразе я вижу только следующую цепочку: допустим что все строки идентичны, а такого не может потому что не может быть никогда: получили противоречие. S>Это не допустим, что они идентичны. Это вывод из твоих определений. DG>>но во-первых само по себе доказательство какое-то странное, а во вторых даже если допустить что доказательство верное, то получается что не надо лишь делать допущение, что все строки идентичны. S>это не допущение, а следствие из твоих определений. S>Если хочешь — сделай утверждение что в рамках твоих определений две строки с различным содержанием — разные объекты, и я докажу тебе с учетом транзитивности идентичности по твоим определениям это не так.
разные трассы — разные объекты.
S>Туманное дополнение. И что же такое актуальность версии? Когда версии становятся неактуальными? Твоя идентичность динамическая? Т.е. со временем она может меняться? Если да, то это противоречит определению ООП идентичности, в частности тому, что идентичность объекта сохраняется все его время жизни.
ты это сейчас сам придумал, в определении которое ты привел такого требования нет.
S>>>А ты можешь ответить на вопрос, является ли объект предыдущим состоянием некого объекта, или это самостоятельный объект? DG>>конечно, в рамках конкретной задачи, когда зафиксировано что из чего хотели получить. S>если эта конкретная задача является частью другой задачи, то твой ответ не будет справедлив для другой задачи. Не смущает?
нет, конечно. потому что этого требования (что различие объектов должно сохраняться для разных задач) в твоем определении тоже нет.
S>>>Это значит что никогда не ясно, является ли string объектом, или неактуальной версией какого-то объекта?
DG>>ты это так говоришь, как будто это нарушает какой-то фундаментальный закон. DG>>тут можно провести полную аналогию со светом, про который тоже никогда не ясно — частица он или волна. DG>>всё относительно. S>Понятно. Т.е. когда тебе удобно, она объект, когда нет — версия. И всегда можно доказать что она и то и другое.
конечно, в этом и смысл моделей. что они используются когда они удобны, и не используются когда не удобны.
например, отрезок можно рассматривать как две точки, как точку + вектор, как другую точку и обратный вектор, как центр + "радиус-вектор" и т.д. все эти рассмотрения одинаково верны, и в каждый момент времени будет использоваться то рассмотрение, которое более удобно именно в этот момент.
S>Про область значений говорит другое твое определение, согласно которому все строки с одинаковым значением считаются одним объектом.
только в конкретный момент времени, и при условии, что одинаковость сохраняется для всех вариантов входных данных
Здравствуйте, DarkGray, Вы писали:
DG>утверждение "давай отличать объекты по их трассам" подходит под данное определение, и никакого противоречия не возникает.
Не подходит. identity не должно зависеть от состояния и поведения и должно работать для любой пары объектов, даже тех типов, которые ты определишь после определения identity.
Попробуй такую функцию построить.
DG>>утверждение "давай отличать объекты по их трассам" подходит под данное определение, и никакого противоречия не возникает.
G>Не подходит. identity не должно зависеть от состояния и поведения и должно работать для любой пары объектов, даже тех типов, которые ты определишь после определения identity.
что здесь ООП-объект? и что здесь object identity?
так же стоит попробовать ответить на вопросы:
1. сколько объектов будет выведено?
2. сколько раз будет выведен каждый объект?
если на первые вопросы ответы:
в качестве ООП-объекта берется .net-объект
в качестве object identity берется ECMA-identity
то получается, что на последующие вопросы невозможно дать определенные ответы, и можно дать лишь ответы с высокой долей неопределенности:
1. будет выведено объектов от 1 до items.Count (или 0, если items.Count == 0)
2. каждый объект из списка может быть выведен от 1 до items.Count раз (утверждение имеет смысл только для items.Count > 0)
если же на первые вопросы ответы:
каждая ссылка из items есть ООП-объект
в качестве object identity берется условная ссылка items[x], где x — это последовательный номер от 0 до items.Count. при этом объекты, взятые по ссылкам items[x1] и items[x2] считаются разными объектами, если x1 != x2
такие ответы уже помогают получить определенные ответы на последующие вопросы:
1. будет выведено items.Count объектов
2. каждый объект будет выведен 1 раз (утверждение имеет смысл только для items.Count > 0)
при втором подходе даже для очень больших программ можно делать сложные утверждения с высокой долей определенности(что полезно при анализе корректности программы, оптимизации, трансляции и т.д.),
первый подход не дает ничего полезного даже на маленьких программах (и соответственно тогда не понятно — а на хрена его исповедовать?)
DG>>>область значений объекта в рамках object identity имеет низкую значимость. соответственно, из такого предположения никаких интересных выводов сделать невозможно. S>>Можно сделать вывод о том что ты не можешь отличать строковые объекты, т.к. они все идентичны.
DG>нельзя сделать такой вывод.
Я сделал такой вывод. Если хочешь — опровергни его. DG>я умею отличать трассы, а этого достаточно для идентификации объекта.
Этого не достаточно для идентификации объектов внутри трассы. Кроме этого, дополнение идентичности равнозначных строк ломает тебе идентификацию трасс объектов.
S>>С точки зрения identity важно уметь отличать объекты. Если ты их не можешь отличать, то трасса не нужна.
DG>я утверждаю, что если трасса разная, то это разные объекты. ты же говоришь, что трасса не нужна, потому что это не дает отличия. DG>что значит "трасса не нужна", если как раз она и определяет одинаковость объектов?
В том числе и она. Смотри свои определения.
S>>Устроит?
DG>в первом приближении — да. тем более что из этого определения следует, что функцию идентичности можно брать какую угодно, и тогда не понятно откуда у тебя берутся сомнения.
Какая угодно функция не может отличать объекты. Смотри свои трассы, например.
S>>http://en.wikipedia.org/wiki/Identity_%28object-oriented_programming%29 S>>
S>>An identity in object-oriented programming, object-oriented design and object-oriented analysis describes the property of objects that distinguishes them from other objects.
DG>утверждение "давай отличать объекты по их трассам" подходит под данное определение, и никакого противоречия не возникает. DG>с чем ты тогда не согласен?
Возникает. Ты не можешь отличить две строки. Программа не знает что такое трасса, нет способа определения принадлежности объектов одной трассе.
DG>>>где вся логическая цепочка: определения, выводы, противоречие? S>>определения использованы твои. В частности об идентичности двух строк с одинаковым значением и сохранением идентичности операции сложения. Вывод я выделил выше (о том что всевозможные строки есть один объект). Противоречит определению ООП идентичности.
DG>во-первых: какому слову из твоего определения это противоречит, и в чем?
Слову "отличать" и противоречит. В том, что ты не можешь отличить две строки.
DG>во-вторых, еще раз повторю, что операция "+" сохраняет идентичность не произвольного объекта, а только того, который ей передали в данной конкретной программе.
Интересное замечание. Ты определил идентичность только для "тех" объектов, которые переданы в операцию "+". А как ты их отличаешь до того как передаешь их в "+"? Ты ведь уже до передачи делишь объекты на "те" и не те".
Но это и не важно.
string s1 = "" + "1";
string s2 = "" + "2";
по твоим определениям "", s1 и s2 один и тот же объект.
DG>>>но во-первых само по себе доказательство какое-то странное, а во вторых даже если допустить что доказательство верное, то получается что не надо лишь делать допущение, что все строки идентичны. S>>это не допущение, а следствие из твоих определений. S>>Если хочешь — сделай утверждение что в рамках твоих определений две строки с различным содержанием — разные объекты, и я докажу тебе с учетом транзитивности идентичности по твоим определениям это не так.
DG>разные трассы — разные объекты.
Смотри свое определение о том что строки с равным значением это один и тот же объект.
S>>Туманное дополнение. И что же такое актуальность версии? Когда версии становятся неактуальными? Твоя идентичность динамическая? Т.е. со временем она может меняться? Если да, то это противоречит определению ООП идентичности, в частности тому, что идентичность объекта сохраняется все его время жизни.
DG>ты это сейчас сам придумал, в определении которое ты привел такого требования нет.
Вообще это не я придумал.
А в твоем определении нет понятия "версия"
S>>если эта конкретная задача является частью другой задачи, то твой ответ не будет справедлив для другой задачи. Не смущает?
DG>нет, конечно. потому что этого требования (что различие объектов должно сохраняться для разных задач) в твоем определении тоже нет.
Подскажи, какой смысл в идентичности без ее сохранения объектом? Вот определил ты что объекты разные, и в той же строчке не можешь гарантировать что они останутся разными. Foo("1", "2"). На входе разные объекты, внутри — один объект, на выходе один объект. Что дает такая идентичность?
DG>>>ты это так говоришь, как будто это нарушает какой-то фундаментальный закон. DG>>>тут можно провести полную аналогию со светом, про который тоже никогда не ясно — частица он или волна. DG>>>всё относительно. S>>Понятно. Т.е. когда тебе удобно, она объект, когда нет — версия. И всегда можно доказать что она и то и другое.
DG>конечно, в этом и смысл моделей. что они используются когда они удобны, и не используются когда не удобны.
Я не вижу в чем удобство твоей модели и нафига ее использовать.
DG>например, отрезок можно рассматривать как две точки, как точку + вектор, как другую точку и обратный вектор, как центр + "радиус-вектор" и т.д. все эти рассмотрения одинаково верны, и в каждый момент времени будет использоваться то рассмотрение, которое более удобно именно в этот момент.
Отрезок рассматривается как интервал. И это единственно верное его рассмотрение. Очевидно что интервал и две точки обладают различными свойствами, и не могут быть одинакого верны.
S>>Про область значений говорит другое твое определение, согласно которому все строки с одинаковым значением считаются одним объектом.
DG>только в конкретный момент времени, и при условии, что одинаковость сохраняется для всех вариантов входных данных
Я не понял смысла этой оговорки. И откуда она взялась? В твоих определениях ничего не было о времени и вариантов входных данных.
Здравствуйте, DarkGray, Вы писали:
DG>понятие объекта относительно (зависит от контекста), и также относительно понятие object identity.
DG>это отчасти видно на следующем примере DG>
DG>что здесь ООП-объект? и что здесь object identity?
DG>так же стоит попробовать ответить на вопросы: DG>1. сколько объектов будет выведено? DG>2. сколько раз будет выведен каждый объект?
DG>если на первые вопросы ответы: DG>в качестве ООП-объекта берется .net-объект DG>в качестве object identity берется ECMA-identity
DG>то получается, что на последующие вопросы невозможно дать определенные ответы, и можно дать лишь ответы с высокой долей неопределенности:
Можно дать ответы очень определенные. И сколько объектов, и сколько раз каждый. DG>1. будет выведено объектов от 1 до items.Count (или 0, если items.Count == 0)
Не факт. Может быть выведено 0 объектов при items.Count > 0. DG>2. каждый объект из списка может быть выведен от 1 до items.Count раз (утверждение имеет смысл только для items.Count > 0)
DG>если же на первые вопросы ответы: DG>каждая ссылка из items есть ООП-объект DG>в качестве object identity берется условная ссылка items[x], где x — это последовательный номер от 0 до items.Count. при этом объекты, взятые по ссылкам items[x1] и items[x2] считаются разными объектами, если x1 != x2
DG>такие ответы уже помогают получить определенные ответы на последующие вопросы: DG>1. будет выведено items.Count объектов DG>2. каждый объект будет выведен 1 раз (утверждение имеет смысл только для items.Count > 0)
DG>при втором подходе даже для очень больших программ можно делать сложные утверждения с высокой долей определенности(что полезно при анализе корректности программы, оптимизации, трансляции и т.д.), DG>первый подход не дает ничего полезного даже на маленьких программах (и соответственно тогда не понятно — а на хрена его исповедовать?)
Извини, но ты редкий извращенец. Сначала задаешь конкретные вопросы про объекты, потом вводишь определение объекта и его идентичности в ответе. Какой смысл в вопросе, если он не подразумевает конкретную систему объектов? Ты ответил не на вопрос "сколько будет выведено объектов", а на вопрос, сколько элементов в списке.
Давай я немного утрирую ситуацию. На вопрос "сколько денег на счету у X" ты отвечаешь "если считать что монеты и купюры одного достоинства идентичны, и являются версиями одной монетой, то ...". Такой ли ответ нужен вопрошающему?
DG>>то получается, что на последующие вопросы невозможно дать определенные ответы, и можно дать лишь ответы с высокой долей неопределенности: S>Можно дать ответы очень определенные. И сколько объектов, и сколько раз каждый.
дай определенные ответы, раз можно
S>Извини, но ты редкий извращенец. Сначала задаешь конкретные вопросы про объекты, потом вводишь определение объекта и его идентичности в ответе. Какой смысл в вопросе, если он не подразумевает конкретную систему объектов? Ты ответил не на вопрос "сколько будет выведено объектов", а на вопрос, сколько элементов в списке.
ты ввел новое понятие "элемент в списке", что это такое и чем это понятие отличается от понятия "ООП-объект"?
S> Какой смысл в вопросе, если он не подразумевает конкретную систему объектов?
при использовании библиотечного кода — пофигу, что именно он считает объектом, главное чтобы гарантировались определенные свойства:
возможность конструирования таких объектов,
возможность внешнего различия,
инвариантность кол-ва,
и т.д.
возьмем все ту же функцию Output, и ее спецификацию — эту функцию можно использовать из произвольного кода? ответ можно, потому что всегда можно взять паттерн адаптер и преобразовать один вид объектов в другой.
спецификация функцию Output:
1. каждая ссылка из items есть ООП-объект (включая null)
2. в качестве object identity берется условная ссылка items[x], где x — это последовательный номер от 0 до items.Count. при этом
объекты, взятые по ссылкам items[x1] и items[x2] считаются разными объектами, если x1 != x2
3. каждый объект будет последовательно выведен на экран с разделителем перевод строки.
можно объекты с ecma-identity преобразовать в объекты с вышеуказанной object idenity? без проблем. даже ничего делать не надо.
S>Давай я немного утрирую ситуацию. На вопрос "сколько денег на счету у X" ты отвечаешь "если считать что монеты и купюры одного достоинства идентичны, и являются версиями одной монетой, то ...". Такой ли ответ нужен вопрошающему?
если этот ответ является более сильным (из него можно сконструировать тот ответ, который необходим вопрошающему), то такого ответа достаточно.
S>Не факт. Может быть выведено 0 объектов при items.Count > 0.
это сложный (с высокой неопределенностью) вопрос, является ли null объектом или не является? в одних случаях его удобно рассматривать, как отсутствие объекта, а в других случаях как вырожденный случай объекта
в данном примере, если рассматривать только вход (список) и выход(строки на экране), и конструируя минимальную спецификацию описывающую что произошло, то приходится сделать вывод, что каждое присутствие null в списке является объектом, который на получение сообщения ToString возвращает пустую строку.
у меня был очень важный вопрос: в каких сценариях реально необходима object identity? когда нам действительно необходимо знать, что объект является одним и тем же?
ответ на этот вопрос, к сожалению, в теме так и не дали, поэтому приходится отвечать самому.
object identity реально необходима лишь при использовании функций, которые меняют объекты. в остальных случаях нет необходимости знать объект является тем же самым или нет.
например, в следующем коде корректность результата работы функции InversePoints (что она инвертирует все переданные точки) можно гарантировать лишь для случая, когда в InversePoints передаются строго различные объекты, и не передается один и тот же объект несколько раз:
class Point
{
public int X;
public int Y;
public void Inverse()
{
X = -X;
Y = -Y;
}
}
public void InversePoints(IEnumerable<Point> points)
{
foreach (var point in points)
point.Inverse();
}
возникает вопрос можно ли даже в таких сценариях избавиться от требования "должны передаваться строго различные объекты", и при этом продолжать обеспечивать гарантии на результат?
ответ — можно, если использовать объекты с immutable-версионностью (причем здесь утверждается, что и функция Inverse и функция InversePoints возвращает те же самые объекты, но измененные, потому что именно в этих терминах можно кратко специфицировать, что эти функции делают).
class Point
{
public Point(int x = 0, int y = 0)
{
this.X = x; this.Y = y;
}
public readonly int X;
public readonly int Y;
public Point Inverse()
{
return new Point(x:-X, y:-Y);
}
}
public IEnumerable<Point> InversePoints(IEnumerable<Point> points)
{
foreach (var point in points)
yield return point.Inverse();
}
данный код не имеет требования, что объекты должны быть строго различны.
при этом сама функция InversePoints считает, что она на вход получает последовательность различных объектов, каждый из которых она инвертирует.
внешний код при этом может иметь и другое мнение, что есть один и тот же объект, но для функции InversePoint это не имеет значения, она все равно будет обеспечивать внятные гарантии на результат.
для первого кода — такое свойство не соблюдалось, там было необходимо, чтобы совпадало мнение — что есть различный объект, как снаружи функции, так и внутри.
ps
данный код может быть так же усилен для варианта, когда null считается вырожденным объектом (и любое изменение такого объекта дает его самого же), при чем даже без изменения самой функции InversePoints
class Point
{
public Point(int x = 0, int y = 0)
{
this.X = x; this.Y = y;
}
public readonly int X;
public readonly int Y;
}
static class PointHlp
{
public static Point Inverse(this Point point)
{
if (point == null)
return null;
return new Point(x:-point.X, y:-point.Y);
}
}
public IEnumerable<Point> InversePoints(IEnumerable<Point> points)
{
foreach (var point in points)
yield return point.Inverse();
}
DG>>>то получается, что на последующие вопросы невозможно дать определенные ответы, и можно дать лишь ответы с высокой долей неопределенности: S>>Можно дать ответы очень определенные. И сколько объектов, и сколько раз каждый.
DG>дай определенные ответы, раз можно
Дай определенную реализацию IList, определенный набор данных, и я тебе дам определенные ответы.
S>>Извини, но ты редкий извращенец. Сначала задаешь конкретные вопросы про объекты, потом вводишь определение объекта и его идентичности в ответе. Какой смысл в вопросе, если он не подразумевает конкретную систему объектов? Ты ответил не на вопрос "сколько будет выведено объектов", а на вопрос, сколько элементов в списке.
DG>ты ввел новое понятие "элемент в списке", что это такое и чем это понятие отличается от понятия "ООП-объект"?
Ты сослался на IList<object> и не поморщился. А теперь спрашиваешь с меня определение понятия, которым пользуется твой код?
S>> Какой смысл в вопросе, если он не подразумевает конкретную систему объектов?
DG>при использовании библиотечного кода — пофигу, что именно он считает объектом, главное чтобы гарантировались определенные свойства: DG>возможность конструирования таких объектов, DG>возможность внешнего различия,
И как ты различаешь свои трассы?
DG>инвариантность кол-ва, DG> и т.д.
DG>возьмем все ту же функцию Output, и ее спецификацию — эту функцию можно использовать из произвольного кода? ответ можно, потому что всегда можно взять паттерн адаптер и преобразовать один вид объектов в другой. DG>спецификация функцию Output: DG>1. каждая ссылка из items есть ООП-объект (включая null) DG>2. в качестве object identity берется условная ссылка items[x], где x — это последовательный номер от 0 до items.Count. при этом DG>объекты, взятые по ссылкам items[x1] и items[x2] считаются разными объектами, если x1 != x2 DG>3. каждый объект будет последовательно выведен на экран с разделителем перевод строки.
DG>можно объекты с ecma-identity преобразовать в объекты с вышеуказанной object idenity? без проблем. даже ничего делать не надо.
А теперь вопрос. А нафига? Ты не можешь сформулировать спецификацию Output в терминах штатной identity и понятий IList?
S>>Давай я немного утрирую ситуацию. На вопрос "сколько денег на счету у X" ты отвечаешь "если считать что монеты и купюры одного достоинства идентичны, и являются версиями одной монетой, то ...". Такой ли ответ нужен вопрошающему?
DG>если этот ответ является более сильным (из него можно сконструировать тот ответ, который необходим вопрошающему), то такого ответа достаточно.
Продемонстрируй как ты из ответа про Output с твоей идентичностью сконструируешь ответ с идентичностью ECMA
Здравствуйте, DarkGray, Вы писали:
S>>Не факт. Может быть выведено 0 объектов при items.Count > 0.
DG>это сложный (с высокой неопределенностью) вопрос, является ли null объектом или не является? в одних случаях его удобно рассматривать, как отсутствие объекта, а в других случаях как вырожденный случай объекта
Можно просто заглянуть в матчасть.
DG>в данном примере, если рассматривать только вход (список) и выход(строки на экране), и конструируя минимальную спецификацию описывающую что произошло, то приходится сделать вывод, что каждое присутствие null в списке является объектом, который на получение сообщения ToString возвращает пустую строку.
Не нужно делать такие выводы. Просто подумай об этом в том ракурсе, что список хранит не объекты а ссылки в случае когда параметризован референс типом.
Здравствуйте, DarkGray, Вы писали:
DG>у меня был очень важный вопрос: в каких сценариях реально необходима object identity? когда нам действительно необходимо знать, что объект является одним и тем же?
DG>ответ на этот вопрос, к сожалению, в теме так и не дали, поэтому приходится отвечать самому.
DG>object identity реально необходима лишь при использовании функций, которые меняют объекты. в остальных случаях нет необходимости знать объект является тем же самым или нет.
Вот те на. А где без identity будет гарантия того что ты посылаешь сообщения одному и тому же объекту? Пусть он иммутабельный, но сообщение может уйти и другому. Как быть с полиморфизмом?
DG>например, в следующем коде корректность результата работы функции InversePoints (что она инвертирует все переданные точки) можно гарантировать лишь для случая, когда в InversePoints передаются строго различные объекты, и не передается один и тот же объект несколько раз: DG>
DG>class Point
DG>{
DG> public int X;
DG> public int Y;
DG> public void Inverse()
DG> {
DG> X = -X;
DG> Y = -Y;
DG> }
DG>}
DG>public void InversePoints(IEnumerable<Point> points)
DG>{
DG> foreach (var point in points)
DG> point.Inverse();
DG>}
DG>
DG>возникает вопрос можно ли даже в таких сценариях избавиться от требования "должны передаваться строго различные объекты", и при этом продолжать обеспечивать гарантии на результат?
Ответ — можно и без immutable. Но ты решил поиграться с identity ради нескольких строчек кода.
DG>ответ — можно, если использовать объекты с immutable-версионностью (причем здесь утверждается, что и функция Inverse и функция InversePoints возвращает те же самые объекты, но измененные, потому что именно в этих терминах можно кратко специфицировать, что эти функции делают).
Ради чего собственно ты утверждаешь что возвращаются те же самые объекты? Функция делает не то что ты утверждаешь, и ты подменил identity с целью втиснуть функцию в спецификацию.
Интересно, а нарушив закон, ты в суде тоже будешь подменять понятия? DG>
DG>public IEnumerable<Point> InversePoints(IEnumerable<Point> points)
DG>{
DG> foreach (var point in points)
DG> yield return point.Inverse();
DG>}
DG>
DG>данный код не имеет требования, что объекты должны быть строго различны. DG>при этом сама функция InversePoints считает, что она на вход получает последовательность различных объектов, каждый из которых она инвертирует. DG>внешний код при этом может иметь и другое мнение, что есть один и тот же объект, но для функции InversePoint это не имеет значения, она все равно будет обеспечивать внятные гарантии на результат.
Если внешний код при этом будет иметь другое мнение на природу объекта, то взаимодействовать с InversePoint он не сможет. Спецификация — она не только для функции. Это контракт на взаимодействие вызывающего кода с вызываемым прежде всего.
DG>для первого кода — такое свойство не соблюдалось, там было необходимо, чтобы совпадало мнение — что есть различный объект, как снаружи функции, так и внутри.
DG>ps DG>данный код может быть так же усилен для варианта, когда null считается вырожденным объектом (и любое изменение такого объекта дает его самого же), при чем даже без изменения самой функции InversePoints
Только это уже не про identity.
S>Вот те на. А где без identity будет гарантия того что ты посылаешь сообщения одному и тому же объекту? Пусть он иммутабельный, но сообщение может уйти и другому.
это гарантия сохраняется в независимости от того, какая object identity выбрана — ecma, ссылочная, версионная и т.д.
S> Как быть с полиморфизмом?
полиморфизм как был так и остается. и примере с null как раз применение полиморфизма и показывает.
или ты на самом деле не знаешь что такое полиморфизм?
DG>>возникает вопрос можно ли даже в таких сценариях избавиться от требования "должны передаваться строго различные объекты", и при этом продолжать обеспечивать гарантии на результат?
S>Ответ — можно и без immutable. Но ты решил поиграться с identity ради нескольких строчек кода.
ты все грозишься что всё можно, а сам еще даже ни одного вывода не сделал, ни строчки кода не привел...
S> Интересно, а нарушив закон, ты в суде тоже будешь подменять понятия?
так ты уже смог показать, что из твоего определения object identity хоть что-то следует?
DG>>ответ — можно, если использовать объекты с immutable-версионностью (причем здесь утверждается, что и функция Inverse и функция InversePoints возвращает те же самые объекты, но измененные, потому что именно в этих терминах можно кратко специфицировать, что эти функции делают). S>Ради чего собственно ты утверждаешь что возвращаются те же самые объекты? Функция делает не то что ты утверждаешь, и ты подменил identity с целью втиснуть функцию в спецификацию.
S>Если внешний код при этом будет иметь другое мнение на природу объекта, то взаимодействовать с InversePoint он не сможет.
сможет, если можно сконструировать адаптер, которую преобразует одну спецификацию в другую.
а в данном случае таким адаптером является тождественное преобразование
DG>>данный код может быть так же усилен для варианта, когда null считается вырожденным объектом (и любое изменение такого объекта дает его самого же), при чем даже без изменения самой функции InversePoints S>Только это уже не про identity.
и опять религиозное мнение без каких-либо выводов из определения.
Здравствуйте, DarkGray, Вы писали: DG>object identity реально необходима лишь при использовании функций, которые меняют объекты. в остальных случаях нет необходимости знать объект является тем же самым или нет.
Совершенно верно. Вот только классическое ООП как раз разработано для объектов, изменяющих своё состояние.
DG>ответ — можно, если использовать объекты с immutable-версионностью
Заумное определение "объекты с immutable-версионностью" можно заменить просто на "immutable объекты".
Ничего плохого в этом нет, просто вы получите существенно другую модель, чем в классическом ООП. Во избежание неконструктивных дискуссий я бы рекомендовал вам воздержаться от называния такой модели объектно-ориентированной. В частности потому, что в такой модели у объектов нет ни идентичности, ни состояния, ни поведения — в тех смыслах, которые вкладываются в эти определения в классическом ООП.
DG>(причем здесь утверждается, что и функция Inverse и функция InversePoints возвращает те же самые объекты, но измененные, потому что именно в этих терминах можно кратко специфицировать, что эти функции делают).
Непонятно, что вы называете "теми же самыми" объектами. Вы только что отказались от identity, которая и была способом отличить "те же самые" объекты от "не тех же самых".
DG>при этом сама функция InversePoints считает, что она на вход получает последовательность различных объектов, каждый из которых она инвертирует.
Нет. Функция InversePoints никак не завязана на различность получаемых объектов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
S>>Вот те на. А где без identity будет гарантия того что ты посылаешь сообщения одному и тому же объекту? Пусть он иммутабельный, но сообщение может уйти и другому.
DG>это гарантия сохраняется в независимости от того, какая object identity выбрана — ecma, ссылочная, версионная и т.д.
Лишь за счет того, что выполняется ecma identity, обеспечивая то, что ссылка ссылается на объект с конкретной identity.
S>> Как быть с полиморфизмом?
DG>полиморфизм как был так и остается. и примере с null как раз применение полиморфизма и показывает.
identity является основой для работы полиморфизма. DG>или ты на самом деле не знаешь что такое полиморфизм?
Твой пример с null показывает что ты не знаешь что такое полиморфизм.
S>>Ответ — можно и без immutable. Но ты решил поиграться с identity ради нескольких строчек кода.
DG>ты все грозишься что всё можно, а сам еще даже ни одного вывода не сделал, ни строчки кода не привел...
Я сделал достаточно выводов относительно твоих определений. И строчки тоже приводил, даже не одну.
Добавь в свой первый вариант Distinct() и каждый объект будет меняться лишь однажды.
S>> Интересно, а нарушив закон, ты в суде тоже будешь подменять понятия?
DG>так ты уже смог показать, что из твоего определения object identity хоть что-то следует?
Ты уже смог показать что из твоих определений не следует что все строки есть один объект, или смирился с этим?
DG>>>ответ — можно, если использовать объекты с immutable-версионностью (причем здесь утверждается, что и функция Inverse и функция InversePoints возвращает те же самые объекты, но измененные, потому что именно в этих терминах можно кратко специфицировать, что эти функции делают). S>>Ради чего собственно ты утверждаешь что возвращаются те же самые объекты? Функция делает не то что ты утверждаешь, и ты подменил identity с целью втиснуть функцию в спецификацию.
S>>Если внешний код при этом будет иметь другое мнение на природу объекта, то взаимодействовать с InversePoint он не сможет.
DG>сможет, если можно сконструировать адаптер, которую преобразует одну спецификацию в другую.
Т.е. ты будешь выдумывать identity под каждую функцию и конструировать адаптеры? Браво. DG>а в данном случае таким адаптером является тождественное преобразование
Тождественное преобразование не является таким адаптером в данном случае. Или ты не знаешь, что такое тождественное преобразование?
DG>>>данный код может быть так же усилен для варианта, когда null считается вырожденным объектом (и любое изменение такого объекта дает его самого же), при чем даже без изменения самой функции InversePoints S>>Только это уже не про identity.
DG>и опять религиозное мнение без каких-либо выводов из определения.
Ты игнорируешь мои выводы. Зачем мне утруждаться?
S>>> Как быть с полиморфизмом?
DG>>полиморфизм как был так и остается. и примере с null как раз применение полиморфизма и показывает. S>identity является основой для работы полиморфизма. DG>>или ты на самом деле не знаешь что такое полиморфизм? S>Твой пример с null показывает что ты не знаешь что такое полиморфизм.
одно из классических определений полиморфизма:
возможность работать одинаковым образом с разнородными объектами.
при этом реализация полиморфизма через vtable, это частный случай реализации полиморфизма.
например, в следующем коде полиморфизм есть — функция Main обрабатывает вывод разнородных объектов (строка, целое число, дробное число) одинаковым образом, но реализация полиморфизма сделана без vtable-а
void Main()
{
foreach (var x in new object[]{"Hello", "world", 37, 21.1})
{
Output(x);
}
}
void Output(object x)
{
if (x is double)
Console.WriteLine("{0,13f2}", x);
if (x is int)
Console.WriteLine("{0,10}", x);
Console.WriteLine(x);
}
для строго наличия наличия полиморфизма или отсутствия полиморфизма — необходимо сначала зафиксировать для какого кода по отношению к какому набору объектов делается утверждение.
следующий код полиморфен для всех объектов, которые реализуют IDisposable, и не полиморфен для набора объектов, которые реализуют IDisposable и не реализуют
var disposable = x as IDisposable;
if (x != null)
disposable.Dispose();
null и полиформизм
следующий код не полиморфен для набора объектов: null и не null, и при наличии такого кода и делается утверждение, что null разрушает полиморфизм
if (point != null)
point.Inverse();
в следующем примере Main полиморфно обрабатывает набор объектов: null и не null.
и null наоборот полиморфизм добавляет, а не разрушает.
void Main()
{
foreach (var p in new Point[]{new Point(x:1, y:2), null, new Point()})
{
p.Inverse();
}
}
static class PointHlp
{
public static void Inverse(this Point p)
{
if (p == null)
return null;
return p._Inverse();
}
}
class Point
{
...
public void _Inverse()
{
..
}
}
S>>>Ответ — можно и без immutable. Но ты решил поиграться с identity ради нескольких строчек кода.
DG>>ты все грозишься что всё можно, а сам еще даже ни одного вывода не сделал, ни строчки кода не привел... S>Я сделал достаточно выводов относительно твоих определений. И строчки тоже приводил, даже не одну. S>Добавь в свой первый вариант Distinct() и каждый объект будет меняться лишь однажды.
согласен будет. только при этом код станет O(n*logn) вместо O(n) и концепция Нулевые побочные затраты, если не используется, пойдут к черту, а так все замечательно.
это я намекаю на то, что определения подбираются такие, чтобы код был хорошим, а не наоборот — подбирается код (в том числе ужасный) под раз зафиксированные определения.
