Re[41]: ООП головного мозга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.10.11 18:44
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


G>>При том что "фаулер и ко" продолжают сейчас популяризировать те идеи, которые были актуальны 10-15 лет назад.


ANS>Зашел к Фаулеру на сайт. В самом верху ссылка на http://martinfowler.com/dsl.html А в низу есть:

ANS>

ANS>Popular Articles
ANS>* New Methodology
ANS>* Dependency Injection
ANS>* Mocks aren’t Stubs
ANS>* Is Design Dead?
ANS>* Continuous Integratio


ANS>имхо, зря ты на него бочку катиш


New Methodology, Is Design Dead? — все про agile, сплошной маркетинг, статья 10-летней давности. Половина из книжки Бека про XP.

Dependency Injection — все круто, только не написано зачем это все. Я с этого ачинал писать про IoC

Mocks aren’t Stubs — ага, щаз

Яж говорю, фаулер устарел. Он до сих пор "продает" то что было актуально 10 лет назад, а сейчас уже стало нормальным и перекочевало из разряда новшеств в разряд инструментов.
Re[91]: ООП головного мозга
От: samius Япония http://sams-tricks.blogspot.com
Дата: 07.10.11 20:07
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


G>>>А вообще, что ты хочешь доказать?

S>>Я хочу тебе доказать что опираться и зависеть — это не одно и то же. Тем более, я смутно понимаю, что такое опираться в отношении функций.
G>То есть ты что-то хочешь доказать когда этого не понимаешь?
Да

S>>Моя функция id не будет иметь отношения к ReferenceEquals и она не обязана будет возвращать те же результаты. Она будет удовлетворять определению identity OOP, а не ECMA-335.

G>Ок, напиши её.
Думаю, уже скоро.

G>>>>>>>Аксиомы две: 1) у каждого объекта есть identity, которая не зависит от состояния и поведения 2)для одинаковых (same) объектов identity совпадает, для разных — нет

S>>>>Это не аксиомы, это определение идентичности OOP.
G>>>В нашем случае аксимоы, так как они даны и их не нужно доказывать.
S>>Дано определение идентичности.
G>И в определении идентичности прописано что она не зависит от состояние и поведения. Также в нем написано что позволяет отличить объект от других объектов.
Это верно.

S>>Same объекты это те, для которы ID(obj) совпадает. У тебя это понятие относительно ООП по-другому выглядит?

G>Я тебе тоже самое писал. Читай внимательно 2), выше выделил жирным
Там, где ты выделил жирным, ты описал свойство identity через понятие одинаковых и разных объектов. Я пишу что наоборот, identity определяет где разные, а где одинаковые (same) объекты.
Но ECMA-335 вводит идентичность взаимно-однозначным образом с location: they are identical if and only if the locations of the values are the same, отсюда и путаница.
Призываю четко разделять где мы говорим об объектах OOP, а где об объектах ECMA-335. Не нужно проецировать ECMA-335 определение обратно на OOP. По ECMA если объекты в разных location, то это разные объекты. По OOP identity ничего такого нет. ECMA-335 identity гораздо сильнее OOP identity, что позволяет в некоторой степени ослаблять ECMA-335, оставаясь в рамках OOP.

S>>Ты же мне говоришь что ID опирается на понятие разных объектов.


G>http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm


G>

G>object identity — identity is that property of an object that distinguishes each object from all others

G>identity позволяет отличать объекты друг от друга.
Позволяет отличать — да. Но оно же и задает, где разные а где одинаковые объекты. Не путай с ECMA, где идентичность определена через location.

G>>>То что ты пытаешься сделать — даже записать не получится.

S>>Как и Дирихле на C#.
G>Ей вполне получится записать если сделать искусственный тип, свойством которого будет рациональность. Но это свойство не будет корректно обрабатываться при вычислениях. Поэтому толку от функции мало.
Я не понял, что такое искусственный тип со свойством рациональность.

S>>Окей. Но это ведь ECMA, а не OOP. Я утверждал что существует другое identity, которое не совпадает с identity на memory location. Потому я не собираюсь доказывать какое-либо отношение того identity к ReferenceEquals.

G>ты утверждал это конкретно в контексте C#. но так и не смог показать функцию.
Кое-какую функцию я, скорее всего, покажу. Позже.
G>Потом расширил границы, выдумывая системы где ООП реализованно без сравнения ссылок, но id в такой системе не смог.
Предоставить код id без сравнения ссылок я не пытался и не обещал. Обвинять меня в том что я этого не смог не надо. Но предоставить альтернативное отношение идентичности я смогу. Оно будет рабочим на C# и будет формально удовлетворять определению идентичности OOP ничуть не хуже чем идентичность от ECMA-335. Надо только заметить, что "рабочим" это не значит что FCL будет с ним корректно работать вместе со всеми коллекциями и т.п.

G>>>

S>>>>>ссылка обеспечивает все что нужно, что бы обратится к объекту с identity. Но из этого не следует что из идентичности следует совпадение ссылок. По крайней мере для логической идентичности это не следует (http://c2.com/cgi/wiki?ObjectIdentity).
G>>>>Для конкретного языка — следует, можешь обратный пример привести? Я таких не знаю.
G>>>Для C# две строки с одинаковым содержимым.

S>>Все верно. Я говорил об идентичности OOP. Но ты об идентичности ECMA-335.
G>Мы ведь за C# говорили. В ECMA явно прописано что является identity, ты этому противоречить пытаешься.
Слушай, не надо из меня делать идиота. Я с самого начала противопоставлял различные виды идентичности, логическую и физическую. Там я так и написал, что из логической идентичности (это НЕ идентичность ECMA-335) не следует совпадение ссылок (идентичность ECMA-335).
Было бы слишком наглым бредом брать разные объекты по ECMA-335 и утверждать что они идентичны по ECMA-335.
Re[85]: ООП головного мозга
От: artelk  
Дата: 07.10.11 20:32
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

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


A>>Когда может такое случиться, что мы не сможем предоставить коллекции свой equals (вычисляемый как функция состояния объекта) не выходя за рамки ООП парадигмы?


G>Например когда мы хотим поместить в коллекцию объекты класса, который не имеет equals и написан не нами.

G>Как объекты такого класса будут сравниваться? Ты же понимаешь что equals переопределяет очень малый процент классов
Например, назначать коллекции стратегию сравнивания. А вообще, вопрос был не в том, с какими проблемами мы можем столкнуться в текущем проекте, если с завтрашнего дня внезапно появится запрет на вызов ReferenceEquals и всего, что его использует. Вопрос в том, можно ли будет писать объектно ориентированные программы после этого; т.е. возможна ли ситуация, что для реализации какого-то функционала (напр. требуемого заказчиком) будет невозможно не выйти за рамки ООП, хотя с наличием ReferenceEquals оно еще будет возможно?

A>>Ок, берем код ExposedObject, меняем там BindingFlags.NonPublic на BindingFlags.FlattenHierarchy, переопределяем методы из Equals, GetHashCode, ToString и создаем GetType. Делегируем все в агрегируемый объект.

A>>
A>>Console.WriteLine(ex.Equals(o));//true
A>>Console.WriteLine(object.ReferenceEquals(a, ex));//false!!!
A>>


G>Ты привел пример эквивалентных, но не идентичных объектов.

G>Мог бы не напрягаться, а взять две строки.


G>>>Тебе нужен пример где два объекта идентичны, то есть это один объект по сути. Но ссылки на него не равны.

A>>Ссылки ссылаются на идентичные объекты, если они взаимозаменыемы с сохранением поведения программы.
G>Бред. Смотри определения:
G>http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm
Хорошая ссылка.
G>Читай ECMA-335
.NET — это единственная возможная реализация ООП?

G>

G>8.2.5.1 Identity

G>The identity operator is defined by the CTS as follows.
G>• If the values have different exact types, then they are not identical.
G>• Otherwise, if their exact type is a value type, then they are identical if and only if the bit
G>sequences of the values are the same, bit by bit.
G>• Otherwise, if their exact type is a reference type, then they are identical if and only if the
G>locations of the values are the same.

G>Identity is implemented on System.Object via the ReferenceEquals method.

Определение через locations — слишком узко.

G>То что ты приводишь называется эквивалентностью

Так в примере не только ж Equals работает.

A>>Ок, другой пример:

A>>
A>>class Something
A>>{
A>>  private readonly ID id;
  
A>>  public Something()
A>>  {
A>>    id = ID.GetUniqueId();
A>>    //INSERT INTO table (ID, State) VALUES ($id, 0)
A>>  }

A>>  private Something(ID id)
A>>  {
A>>    this.id = id;
A>>  }
  
A>>  public static IEnumerable<Something> GetAll()
A>>  { 
A>>     foreach(id in //SELECT ID FROM table)
A>>       yield return new Something(id)
A>>  }

A>>  public int State
A>>  {
A>>    get { //SELECT State FROM table WHERE ID = $id }
A>>    set { //UPDATE table SET State=$value WHERE ID = $id }
A>>  }
A>>}
A>>

A>>Разжевать?
G>Это ты чего понаписал? И зачем?
Если два объекта типа Something имеют одинаковый id, то они идентичны, независимо от того, что вернет object.ReferenceEquals.
Re[92]: ООП головного мозга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.10.11 20:34
Оценка:
Здравствуйте, samius, Вы писали:

S>>>Same объекты это те, для которы ID(obj) совпадает. У тебя это понятие относительно ООП по-другому выглядит?

G>>Я тебе тоже самое писал. Читай внимательно 2), выше выделил жирным
S>Там, где ты выделил жирным, ты описал свойство identity через понятие одинаковых и разных объектов. Я пишу что наоборот, identity определяет где разные, а где одинаковые (same) объекты.
Если некоторое свойство позволяет отличить разные объекты, то оно же позволяет определить что это один и тот же объект.
Иначе (доказательство от противного), если id(a) != id(b) когда a и b — один и тот же объект, то для любых id(a) и id(b) невозможно сказать это разные или одинаковые объекты.
Поэтому прими за данное что функция id(a) = id(b) только кода a и b — один и тот же объект и не равна в остальных случаях.

S>Но ECMA-335 вводит идентичность взаимно-однозначным образом с location: they are identical if and only if the locations of the values are the same, отсюда и путаница.

Ты и пытался с этим спорить Ладно, не прокатило, вычеркиваем.

S>Призываю четко разделять где мы говорим об объектах OOP, а где об объектах ECMA-335. Не нужно проецировать ECMA-335 определение обратно на OOP. По ECMA если объекты в разных location, то это разные объекты. По OOP identity ничего такого нет. ECMA-335 identity гораздо сильнее OOP identity, что позволяет в некоторой степени ослаблять ECMA-335, оставаясь в рамках OOP.

Да, все верно. НО! Знаешь ли ты еще хоть одну систему где идентичность не реализуется сравнением ссылок?

S>>>Ты же мне говоришь что ID опирается на понятие разных объектов.


G>>http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm


G>>

G>>object identity — identity is that property of an object that distinguishes each object from all others

G>>identity позволяет отличать объекты друг от друга.
S>Позволяет отличать — да. Но оно же и задает, где разные а где одинаковые объекты. Не путай с ECMA, где идентичность определена через location.
См выше. С точки зрения математики позволяет отличать == позволяет найти одинаковые, ecma тут не при чем.

G>>>>То что ты пытаешься сделать — даже записать не получится.

S>>>Как и Дирихле на C#.
G>>Ей вполне получится записать если сделать искусственный тип, свойством которого будет рациональность. Но это свойство не будет корректно обрабатываться при вычислениях. Поэтому толку от функции мало.
S>Я не понял, что такое искусственный тип со свойством рациональность.

interface INumebr
{
    bool IsRational { get ; }
}



S>>>Окей. Но это ведь ECMA, а не OOP. Я утверждал что существует другое identity, которое не совпадает с identity на memory location. Потому я не собираюсь доказывать какое-либо отношение того identity к ReferenceEquals.

G>>ты утверждал это конкретно в контексте C#. но так и не смог показать функцию.
S>Кое-какую функцию я, скорее всего, покажу. Позже.
С нетерпением ждем.

G>>Потом расширил границы, выдумывая системы где ООП реализованно без сравнения ссылок, но id в такой системе не смог.

S>Предоставить код id без сравнения ссылок я не пытался и не обещал. Обвинять меня в том что я этого не смог не надо. Но предоставить альтернативное отношение идентичности я смогу. Оно будет рабочим на C# и будет формально удовлетворять определению идентичности OOP ничуть не хуже чем идентичность от ECMA-335. Надо только заметить, что "рабочим" это не значит что FCL будет с ним корректно работать вместе со всеми коллекциями и т.п.
Чтобы механизм был рабочим надо:
1)Придумать как обращаться с ними в программе (ссылки, которые при этом нельзя сравнить)
2)Придумать механизм отправки сообщения по ссылке
3)Придумать identity, как функцию id(object)
4)Придумать как сравнивать identity
5)Доказать что между значением id(object) и ссылкой нет взаимно однозначного соответствия.
5 пункт очень важный так как иначе нет смысла вводить искусственную функцию id. При этом помним что ссылка не есть адрес в памяти, и возможные выкрутасы с сегментацией, виртуальной памятью и подобное тому что сделано в COM не катят.


G>>Мы ведь за C# говорили. В ECMA явно прописано что является identity, ты этому противоречить пытаешься.

S>Слушай, не надо из меня делать идиота.
Я ниче не делаю, ты сам. Я приводил цитаты из твоих сообщений.

S>Я с самого начала противопоставлял различные виды идентичности, логическую и физическую. Там я так и написал, что из логической идентичности (это НЕ идентичность ECMA-335) не следует совпадение ссылок (идентичность ECMA-335).

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

S>Было бы слишком наглым бредом брать разные объекты по ECMA-335 и утверждать что они идентичны по ECMA-335.

Нет, ты просто слишком много читал википедии и сам запутался с своих идентичностях.
Re[79]: ООП головного мозга
От: samius Япония http://sams-tricks.blogspot.com
Дата: 07.10.11 20:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


S>>>Если это можно обеспечить идентификатором, то идентификатор выполняет роль ссылки. По определению ссылки.

S>>выполняет роль, но не является.
S>С точки зрения математики, "выполнять роль" и "являться" — одно и то же.
Вы меня удивляете. "являться" изоморфно "is a", "принадлежит к"...
"42 является натуральным числом" означает что 42 принадлежит множеству натуральных чисел.
Что означает фраза "42 выполняет роль натурального числа"? Вы будете утвреждать что это одно и то же?

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

Нет желания отвечать на это

S>>Это своя реализация идентичности. Не интересно.

S>Что значит "своя"? А вы хотели чужую? Идентичность — это математическое понятие. Реализация идентичности — она всегда своя.
Не так выразился. Там свое определение идентичности. Они его определили через memory location. Хотелось бы увидеть эквивалентность определению из ООП. Но мы видим только то что идентичность ECMA удовлетворяет определению идентичности ООП, но не исчерпывает его.

S>>Компилировать FCL в C#-- не надо, нет такой цели

S>А в чём цель? Я думал, вы хотите получить работоспособную ОО-модель.
Она работоспособна, пока мы не вызовем ID.
S>>Имеет смысл если ID вычислима. Но я не говорил что она вычислима.
S>Если она невычислима, то у нас нет "способа отличать один объект от любого другого объекта". Упс.
Есть, но он невычислим.
S>>В той трактовке, что позволяет отличать любой объект от всех остальных — да.
S>Это не трактовка, это само определение.
Идентичность сама и регулирует, где один объект, а где другой.

S>>Ну дак мы их отличать можем в теории, по некой невычислимой функции. Существования такой функции достаточно, вычислимость ее — это просто очень полезный бонус

S>Хм. Тут мои познания в computer science заканчиваются. Остаётся только смутное сомнение в
S>а) существовании невычислимых функций (чем оно отличается от несуществования такой функции?)
computer science непричем. Есть математическое понятие функции как отображения множеств. Оно не требует вычислимости. Я не думал о том что computer science может использовать какое-то другое понятие. Конечно,когда мы спускаемся к конкретному языку, мы пользуемся его определением функции, которое может отличаться от общего и даже нарушать его. Например, отсутствием детерминированности. Но это не означает что в концептуальной модели мы должны пользоваться определением функции в языках. Кстати, C# не требует вычислимости функций что бы называть ее функцией. И детерминированности не требует. Вообще ничего не требует.

S>б) в применимости невычислимых функций в определениях моделей, применяемых для прикладного программирования. Мне кажется, что во всех местах, когда говорят "свойство того-то" или "функция от того-то", то везде неявно продразумевают "вычислимая детерминированная".

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

S>>мы можем отличать объекты с отличным поведением (но только их). Отличать объекты с неотличимым поведением не нужно. Но это уже видимо моя додумка.

S>Да, это ваша додумка.
Да. Только вот идентичность сама и указывает, что считать отличным объектом, а что нет. Естественно, что как только мы отказываемся от ECMA идентичности, то понятие ECMA отличий объектов перестает иметь место. На это место встает то понятие отличия объектов, которое задано новой идентичностью. Если моя идентичность укажет что два объекта класса без состояния идентичны, то так оно и будет, невзирая на то что по ECMA они будут различными объектами.

S>>Про "следовать" погорячился. можем одновременно наблюдать неравенство ссылок и same identity.

S>Это правда, и это явно описано в википедии, хотя и не обосновано формально.
Да, кое-что там напутали. Но другая identity задает другое отношение same object.
S>>Вот по этим изменениям я и предлагал определять идентичность.
S>Такая идентичность не будет сохраняться.
S>Поясню примером:
S>[c#]
S>public class NonIdentic
S>{
S> public int A { get; set; }
S>}

S>...

S>Опять то же самое. Какую бы цепочку сообщений getA/setA мы ни придумали, цепочка ответов от объектов a и b будет совершенно одинаковой. То есть их поведение — одинаково. Значит, у них должна быть одинаковая "логическая identity".
S>Однако, стоит нам сделать хоть что-то несимметричное, как их поведение тут же станет различным. Упс.
Вот по несимметричным действиям мы и можем их отличать. На самом деле в изменениях нет необходимости. Можно пошуршать в IL коде и увидеть, позволяет ли объект изменять свои поля или нет. Если позволяет — определять его идентичность по location, т.е. по ReferenceEquals. Если не нет — то по полям. Это довольно грубо, но надеюсь, что идея понятна.
Re[86]: ООП головного мозга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.10.11 20:44
Оценка:
Здравствуйте, artelk, Вы писали:

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


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


A>>>Когда может такое случиться, что мы не сможем предоставить коллекции свой equals (вычисляемый как функция состояния объекта) не выходя за рамки ООП парадигмы?


G>>Например когда мы хотим поместить в коллекцию объекты класса, который не имеет equals и написан не нами.

G>>Как объекты такого класса будут сравниваться? Ты же понимаешь что equals переопределяет очень малый процент классов
A>Например, назначать коллекции стратегию сравнивания.
Коллекция тоже не тобой написана. Счиатй что у тебя изначально нет возможности переопределит операцию сравнения. Как будет выполняться операция Collection.Remove(item)

A>А вообще, вопрос был не в том, с какими проблемами мы можем столкнуться в текущем проекте, если с завтрашнего дня внезапно появится запрет на вызов ReferenceEquals и всего, что его использует.

Как минимум BCL не соберется\перестанет работать. Ты кстати скорее всего можешь сымитировать ситуацию через profile api, подменив вызов RefenceEquals, если он не intrsink какойнить.


G>>>>Тебе нужен пример где два объекта идентичны, то есть это один объект по сути. Но ссылки на него не равны.

A>>>Ссылки ссылаются на идентичные объекты, если они взаимозаменыемы с сохранением поведения программы.
G>>Бред. Смотри определения:
G>>http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm
A>Хорошая ссылка.
Конечно, прочитай внимательно все три определения. Все три верны и отражают разные аспекты одного и того же.

G>>Читай ECMA-335

A>.NET — это единственная возможная реализация ООП?
Нет, но придумай другую где идентичность не сравнением через ссылок делается.

A>Определение через locations — слишком узко.

Для чего? Практика показывает что для CLR самое то. Ты не можешь расширить это определение (то есть получить идентичность без равенства ссылок) оставаясь в рамках ECMA-335.

G>>То что ты приводишь называется эквивалентностью

A>Так в примере не только ж Equals работает.
А без разницы.

A>Если два объекта типа Something имеют одинаковый id, то они идентичны, независимо от того, что вернет object.ReferenceEquals.

Это бред. Твое определение идентичности опирается на состояние, что противоречит определению идентичности. Более того два объекта не будут ни идентичны, ни эквивалентны с точки зрения ecma-335

Источник твоего "вдохновения" в этом случае — РСУБД, которая не является ОО-системой если что
Re[83]: ООП головного мозга
От: artelk  
Дата: 07.10.11 20:55
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Читай определения: http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm


G>

G>object identity — a characteristic of an object that provides a means to uniquely denote or refer to the object independent of its state or behavior


G>Независимо от состояния и поведения


Только сдается мне такому определению удовлетворит идентичность, реализованная на основе функции
bool IsIdentical(object o1, object o2)
{
  return false;
}

и смысл полностью теряется, т.к. такую функцию можно реализовать вообще для чего угодно.
Re[80]: ООП головного мозга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.10.11 20:56
Оценка:
Здравствуйте, samius, Вы писали:

S>Можно пошуршать в IL коде и увидеть, позволяет ли объект изменять свои поля или нет. Если позволяет — определять его идентичность по location, т.е. по ReferenceEquals. Если не нет — то по полям. Это довольно грубо, но надеюсь, что идея понятна.


Это противоречит определению так как ты на состояние будешь ориентироваться.

Это получится как раз определение эквивалентности, но не идентичности.
Re[84]: ООП головного мозга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.10.11 21:03
Оценка:
Здравствуйте, artelk, Вы писали:

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


G>>Читай определения: http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm


G>>

G>>object identity — a characteristic of an object that provides a means to uniquely denote or refer to the object independent of its state or behavior


G>>Независимо от состояния и поведения


A>Только сдается мне такому определению удовлетворит идентичность, реализованная на основе функции

A>
A>bool IsIdentical(object o1, object o2)
A>{
A>  return false;
A>}
A>

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

Нет.

var a = new object();
var b = a;
var c = new object();
Debug.Assert(IsIdentical(a,b) != IsIdentical(a,c));


Ассерт отвалится, с такой функцией мы не можем сказать являются ли разными два объекта или это один и тот же объект. То есть мы не можем отличить объект от других.
Re[88]: ООП головного мозга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.10.11 21:09
Оценка:
Здравствуйте, samius, Вы писали:

S>Identity в ECMA-335 — это двоичное отношение, основанное на memory location. Так?


Прочитал стандарт. Оказывается не так.


8.3 Locations
Values are stored in locations. A location can hold only one value at a time. All locations are typed. The type
of the location embodies the requirements that shall be met by values that are stored in the location.


Ни слова про memory.
Re[93]: ООП головного мозга
От: samius Япония http://sams-tricks.blogspot.com
Дата: 07.10.11 21:16
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


G>Если некоторое свойство позволяет отличить разные объекты, то оно же позволяет определить что это один и тот же объект.

G>Иначе (доказательство от противного), если id(a) != id(b) когда a и b — один и тот же объект, то для любых id(a) и id(b) невозможно сказать это разные или одинаковые объекты.
G>Поэтому прими за данное что функция id(a) = id(b) только кода a и b — один и тот же объект и не равна в остальных случаях.
Это тафтология, потому как именно id определяет, один и тот же объект или нет. В случае с ECMA это не так, потому как они определяют один и тот же объект или нет по расположению в памяти.

G>Да, все верно. НО! Знаешь ли ты еще хоть одну систему где идентичность не реализуется сравнением ссылок?

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

G>>>

G>>>object identity — identity is that property of an object that distinguishes each object from all others

G>>>identity позволяет отличать объекты друг от друга.
S>>Позволяет отличать — да. Но оно же и задает, где разные а где одинаковые объекты. Не путай с ECMA, где идентичность определена через location.
G>См выше. С точки зрения математики позволяет отличать == позволяет найти одинаковые, ecma тут не при чем.
Тут все верно. Моя мысль была что OOP ID первичен, а одинаковость определяется им. Коренное отличие ECMA в том, что они определили идентичность через location и поставили <=>. А то что ID позволяет отличать и говорить что "это одно и то же" — это верно.

S>>Я не понял, что такое искусственный тип со свойством рациональность.

G>
G>interface INumebr
G>{
G>    bool IsRational { get ; }
G>}
G>

а, ну даже если экземпляр new Sqrt(2) сможет корректно определить что он не рациональный, это вряд ли приблизит к написанию рабочей версии функции Дирихле.
Предлагаю забить на это с выводом что существование математических объектов не опровергается невозможностью реализации их на C#.

S>>Предоставить код id без сравнения ссылок я не пытался и не обещал. Обвинять меня в том что я этого не смог не надо. Но предоставить альтернативное отношение идентичности я смогу. Оно будет рабочим на C# и будет формально удовлетворять определению идентичности OOP ничуть не хуже чем идентичность от ECMA-335. Надо только заметить, что "рабочим" это не значит что FCL будет с ним корректно работать вместе со всеми коллекциями и т.п.

G>Чтобы механизм был рабочим надо:
G>1)Придумать как обращаться с ними в программе (ссылки, которые при этом нельзя сравнить)
Ссылки будут теми же самыми, сравнивать их можно будет, но делать выводы об идентичности отличной от ECMA-335 по этому сравнению будет очевидно нельзя.
G>2)Придумать механизм отправки сообщения по ссылке
Он останется неизменным.
G>3)Придумать identity, как функцию id(object)
Видишь ли, что бы придумать такую функцию, нужно будет задать область значений, отличную от множества всевозможных ссылок. Что делать с этими значениями не совсем понятно. Сравнивать их? Ну так результат сравнения мы можем получить другим способом, не определяя область значений и саму функцию id.
G>4)Придумать как сравнивать identity
с помощью функции MyIdEquals.
G>5)Доказать что между значением id(object) и ссылкой нет взаимно однозначного соответствия.
Для этого ведь достаточно будет показать что результаты MyIdEquals будут отличаться от ReferenceEquals
G>5 пункт очень важный так как иначе нет смысла вводить искусственную функцию id. При этом помним что ссылка не есть адрес в памяти, и возможные выкрутасы с сегментацией, виртуальной памятью и подобное тому что сделано в COM не катят.
нене, ломать рантайм я не собираюсь.

S>>Я с самого начала противопоставлял различные виды идентичности, логическую и физическую. Там я так и написал, что из логической идентичности (это НЕ идентичность ECMA-335) не следует совпадение ссылок (идентичность ECMA-335).

G>Ты так и не смог сказать что такое логическая идентичность, оно у тебя больше похоже на эквивалентность, которая в общем случае идентичностью не является.
Вообще говоря, хорошая идентичность будет эквивалентностью. И идентичность ECMA-335 не то что бы похожа на эквивалентность, а прямо таки удовлетворяет определению эквивалентности (бинарное + рефлексивное + транзитивное + симметричное отношение).

S>>Было бы слишком наглым бредом брать разные объекты по ECMA-335 и утверждать что они идентичны по ECMA-335.

G>Нет, ты просто слишком много читал википедии и сам запутался с своих идентичностях.
Возможно. Но мне кажется что без оговорок ECMA-335 и OOP было довольно легко запутаться в них и тебе тоже. Во всяком случае с оговорками мы стали в некоторых аспектах понимать друг-друга.
Re[81]: ООП головного мозга
От: samius Япония http://sams-tricks.blogspot.com
Дата: 07.10.11 21:21
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


S>>Можно пошуршать в IL коде и увидеть, позволяет ли объект изменять свои поля или нет. Если позволяет — определять его идентичность по location, т.е. по ReferenceEquals. Если не нет — то по полям. Это довольно грубо, но надеюсь, что идея понятна.


G>Это противоречит определению так как ты на состояние будешь ориентироваться.

Определение не запрещает ориентироваться. Оно запрещает id изменяться вместе с состоянием объекта.

G>Это получится как раз определение эквивалентности, но не идентичности.

И эквивалентности и идентичности.
Re[89]: ООП головного мозга
От: samius Япония http://sams-tricks.blogspot.com
Дата: 07.10.11 21:22
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


S>>Identity в ECMA-335 — это двоичное отношение, основанное на memory location. Так?


G>Прочитал стандарт. Оказывается не так.



G>

G>8.3 Locations
G>Values are stored in locations. A location can hold only one value at a time. All locations are typed. The type
G>of the location embodies the requirements that shall be met by values that are stored in the location.


G>Ни слова про memory.

Хорошо, давай уберем memory.
Re[85]: ООП головного мозга
От: artelk  
Дата: 07.10.11 21:26
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


A>>Только сдается мне такому определению удовлетворит идентичность, реализованная на основе функции

A>>
A>>bool IsIdentical(object o1, object o2)
A>>{
A>>  return false;
A>>}
A>>

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

G>Нет.


G>
G>var a = new object();
G>var b = a;
G>var c = new object();
G>Debug.Assert(IsIdentical(a,b) != IsIdentical(a,c));
G>


G>Ассерт отвалится, с такой функцией мы не можем сказать являются ли разными два объекта или это один и тот же объект. То есть мы не можем отличить объект от других.

Ты пытаешься поднять себя за волосы, как Мюнхгаузен. Ты считаешь, что a в первой строке, во второй и последней ссылаются на один и тот же объект. Нет, в каждой точке программы мы имеем дело с новым объектом, согласно нашей реализации идентичности.
Re[94]: ООП головного мозга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.10.11 00:59
Оценка:
Здравствуйте, samius, Вы писали:

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


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


G>>Если некоторое свойство позволяет отличить разные объекты, то оно же позволяет определить что это один и тот же объект.

G>>Иначе (доказательство от противного), если id(a) != id(b) когда a и b — один и тот же объект, то для любых id(a) и id(b) невозможно сказать это разные или одинаковые объекты.
G>>Поэтому прими за данное что функция id(a) = id(b) только кода a и b — один и тот же объект и не равна в остальных случаях.
S>Это тафтология, потому как именно id определяет, один и тот же объект или нет.
Нет, объекты априори бывают разные. А id позволяет это определять в программе. В определении так и написано: "id позволяет различать разные объекты", не написано что "id определяет объект".

G>>Да, все верно. НО! Знаешь ли ты еще хоть одну систему где идентичность не реализуется сравнением ссылок?

S>Именно OOP систему — нет. Это имеет значение?
Да, огромное значение.


S>>>Я не понял, что такое искусственный тип со свойством рациональность.

G>>
G>>interface INumebr
G>>{
G>>    bool IsRational { get ; }
G>>}
G>>

S>а, ну даже если экземпляр new Sqrt(2) сможет корректно определить что он не рациональный, это вряд ли приблизит к написанию рабочей версии функции Дирихле.
Нет, исходя из интерфейса выше функцию дирихле написать легко. И даже алгебру таких объектов посторить легко. Можно даже написать функцию Sqrt, которая вернет правильный результат. А вот логарифм, тригонометрия — уже не получится. Но ведь на функцию дирихле оно никак не повлияет.


S>>>Предоставить код id без сравнения ссылок я не пытался и не обещал. Обвинять меня в том что я этого не смог не надо. Но предоставить альтернативное отношение идентичности я смогу. Оно будет рабочим на C# и будет формально удовлетворять определению идентичности OOP ничуть не хуже чем идентичность от ECMA-335. Надо только заметить, что "рабочим" это не значит что FCL будет с ним корректно работать вместе со всеми коллекциями и т.п.

G>>Чтобы механизм был рабочим надо:
G>>1)Придумать как обращаться с ними в программе (ссылки, которые при этом нельзя сравнить)
S>Ссылки будут теми же самыми, сравнивать их можно будет, но делать выводы об идентичности отличной от ECMA-335 по этому сравнению будет очевидно нельзя.
Тогда их сравнивать бессмысленно и можно просто запретить операцию.

G>>2)Придумать механизм отправки сообщения по ссылке

S>Он останется неизменным.
Ок

G>>3)Придумать identity, как функцию id(object)

S>Видишь ли, что бы придумать такую функцию, нужно будет задать область значений, отличную от множества всевозможных ссылок. Что делать с этими значениями не совсем понятно. Сравнивать их? Ну так результат сравнения мы можем получить другим способом, не определяя область значений и саму функцию id.
Вот, ты уже понимаешь что это как минимум нетривиально.

G>>4)Придумать как сравнивать identity

S>с помощью функции MyIdEquals.
Так её надо написать и она должна быть вычислимой.

G>>5)Доказать что между значением id(object) и ссылкой нет взаимно однозначного соответствия.

S>Для этого ведь достаточно будет показать что результаты MyIdEquals будут отличаться от ReferenceEquals
Нет, не достаточно.

Если у тебя MyIdEquals(a,b) != ReferenceEquals(a,b),
то вполне возможно существует f, такая что MyIdEquals(a,b) == MyIdEquals(f(a),f(b)) == ReferenceEquals(f(a),f(b))

На примере COM, там в качестве f будет QueryInterface(IUnknown)


S>>>Я с самого начала противопоставлял различные виды идентичности, логическую и физическую. Там я так и написал, что из логической идентичности (это НЕ идентичность ECMA-335) не следует совпадение ссылок (идентичность ECMA-335).

G>>Ты так и не смог сказать что такое логическая идентичность, оно у тебя больше похоже на эквивалентность, которая в общем случае идентичностью не является.
S>Вообще говоря, хорошая идентичность будет эквивалентностью.
Вообще говоря любая Даже без ООП

S>>>Было бы слишком наглым бредом брать разные объекты по ECMA-335 и утверждать что они идентичны по ECMA-335.

G>>Нет, ты просто слишком много читал википедии и сам запутался с своих идентичностях.
S>Возможно. Но мне кажется что без оговорок ECMA-335 и OOP было довольно легко запутаться в них и тебе тоже. Во всяком случае с оговорками мы стали в некоторых аспектах понимать друг-друга.
Я как-то с самого начала не запутался. Хотя надо было сразу прочитать Ecma-335, а не пытаться тебе доказывать очевидные вещи.
Re[82]: ООП головного мозга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.10.11 01:03
Оценка:
Здравствуйте, samius, Вы писали:

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


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


S>>>Можно пошуршать в IL коде и увидеть, позволяет ли объект изменять свои поля или нет. Если позволяет — определять его идентичность по location, т.е. по ReferenceEquals. Если не нет — то по полям. Это довольно грубо, но надеюсь, что идея понятна.


G>>Это противоречит определению так как ты на состояние будешь ориентироваться.

S>Определение не запрещает ориентироваться. Оно запрещает id изменяться вместе с состоянием объекта.

Ну так оно у тебя будет меняться. Даже readonly можно поменять с помощью рефлексии, все еще оставаясь в рамках CLR.

G>>Это получится как раз определение эквивалентности, но не идентичности.

S>И эквивалентности и идентичности.
Нет, не идентичности.
Re[86]: ООП головного мозга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.10.11 01:05
Оценка:
Здравствуйте, artelk, Вы писали:

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


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


A>>>Только сдается мне такому определению удовлетворит идентичность, реализованная на основе функции

A>>>
A>>>bool IsIdentical(object o1, object o2)
A>>>{
A>>>  return false;
A>>>}
A>>>

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

G>>Нет.


G>>
G>>var a = new object();
G>>var b = a;
G>>var c = new object();
G>>Debug.Assert(IsIdentical(a,b) != IsIdentical(a,c));
G>>


G>>Ассерт отвалится, с такой функцией мы не можем сказать являются ли разными два объекта или это один и тот же объект. То есть мы не можем отличить объект от других.

A>Ты пытаешься поднять себя за волосы, как Мюнхгаузен. Ты считаешь, что a в первой строке, во второй и последней ссылаются на один и тот же объект. Нет, в каждой точке программы мы имеем дело с новым объектом, согласно нашей реализации идентичности.

Нет. в Ecma-335 ясно сказано что идентичные объекты те, у которых same location. a и b — same location.
Re[95]: ООП головного мозга
От: samius Япония http://sams-tricks.blogspot.com
Дата: 08.10.11 08:49
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


S>>Это тафтология, потому как именно id определяет, один и тот же объект или нет.

G>Нет, объекты априори бывают разные. А id позволяет это определять в программе. В определении так и написано: "id позволяет различать разные объекты", не написано что "id определяет объект".
ECMA335 определяет идентичность и тем самым устанавливает, где один объект, а где другой. Другая идентичность введет другое отношение. Почему ты ожидаешь от другой идентичности что она будет оперировать "объектами по ECMA335"? ECMA335 объект != объект по любой другой идентичности, отличающейся от ECMA335. Есть какие-то проблемы с пониманием этого?

G>>>Да, все верно. НО! Знаешь ли ты еще хоть одну систему где идентичность не реализуется сравнением ссылок?

S>>Именно OOP систему — нет. Это имеет значение?
G>Да, огромное значение.

G>Нет, исходя из интерфейса выше функцию дирихле написать легко. И даже алгебру таких объектов посторить легко. Можно даже написать функцию Sqrt, которая вернет правильный результат. А вот логарифм, тригонометрия — уже не получится. Но ведь на функцию дирихле оно никак не повлияет.

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

G>>>1)Придумать как обращаться с ними в программе (ссылки, которые при этом нельзя сравнить)

S>>Ссылки будут теми же самыми, сравнивать их можно будет, но делать выводы об идентичности отличной от ECMA-335 по этому сравнению будет очевидно нельзя.
G>Тогда их сравнивать бессмысленно и можно просто запретить операцию.
Зачем запрещать? Идентичность по ECMA останется. Вдруг, запретив ReferenceEquals, мы не сможем поднять рантайм?

G>>>3)Придумать identity, как функцию id(object)

S>>Видишь ли, что бы придумать такую функцию, нужно будет задать область значений, отличную от множества всевозможных ссылок. Что делать с этими значениями не совсем понятно. Сравнивать их? Ну так результат сравнения мы можем получить другим способом, не определяя область значений и саму функцию id.
G>Вот, ты уже понимаешь что это как минимум нетривиально.
Это лишь немного сложнее чем тривиально. Больше играет тот фактор, что это ненужно. Нам надо сравнивать и посылать. И то и другое можно будет обеспечить без такой функции.

G>>>4)Придумать как сравнивать identity

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

G>>>5)Доказать что между значением id(object) и ссылкой нет взаимно однозначного соответствия.

S>>Для этого ведь достаточно будет показать что результаты MyIdEquals будут отличаться от ReferenceEquals
G>Нет, не достаточно.

G>Если у тебя MyIdEquals(a,b) != ReferenceEquals(a,b),

G>то вполне возможно существует f, такая что MyIdEquals(a,b) == MyIdEquals(f(a),f(b)) == ReferenceEquals(f(a),f(b))

G>На примере COM, там в качестве f будет QueryInterface(IUnknown)

Ты требуешь чего-то непонятного. Даже при существовании такой функции f (забудем пока про взаимную однозначность) MyIdEquals будет отличаться от ReferenceEquals
MyIdEquals(a,b) == MyIdEquals(f(a),f(b)) == ReferenceEquals(f(a),f(b)) != ReferenceEquals(a, b)

А теперь по поводу взаимной однозначности f. Если она взаимно однозначна, то существует обратная ей взаимно однозначная f' такая что f'(f(a))==a и f'(f(b))==b. Из равенства ссылок f(a)==f(b) будет следовать a==b.
Отсюда, если вдруг ReferenceEquals(a, b) == true но MyIdEquals(a,b) == false, то это будет означать нерефлексивность MyIdEquals (нарушение эквивалентности, неверный посыл).
Тепрь наоборот, MyIdEquals(a,b) == true и ReferenceEquals(a, b) == false
По твоим выкладкам
true = MyIdEquals(a,b) = MyIdEquals(f(a),f(b)) = ReferenceEquals(f(a),f(b)) = ReferenceEquals(f'(f(a)),f'(f(b))) = ReferenceEquals(a,b) = false
По-моему мы подвергли сомнению существование такой взаимнооднозначной f

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

S>>Вообще говоря, хорошая идентичность будет эквивалентностью.
G>Вообще говоря любая Даже без ООП
Давай тогда разберемся. чем идентичность отличается от отношения эквивалентности кроме требований возможности отправки сообщения по ссылке, сохранения идентичности при смене состояния?
Что может мою идентичность сделать неидентичностью в общем смысле? Что ее отличает от идентичности ECMA — я догадываюсь

G>Я как-то с самого начала не запутался. Хотя надо было сразу прочитать Ecma-335, а не пытаться тебе доказывать очевидные вещи.

По-моему ты все еще пытаешься найти опровержение другим идентичностям, оперируюя идентичностью ECMA-335. Залез в скафандр ECMA-335 и говоришь что другие скафандры фуфло, потому как в них нельзя влезть, не снимая ECMA-335. Извини, если что.
Re[83]: ООП головного мозга
От: samius Япония http://sams-tricks.blogspot.com
Дата: 08.10.11 08:55
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

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


G>>>Это противоречит определению так как ты на состояние будешь ориентироваться.

S>>Определение не запрещает ориентироваться. Оно запрещает id изменяться вместе с состоянием объекта.

G>Ну так оно у тебя будет меняться. Даже readonly можно поменять с помощью рефлексии, все еще оставаясь в рамках CLR.

Но не в рамках OOP

G>>>Это получится как раз определение эквивалентности, но не идентичности.

S>>И эквивалентности и идентичности.
G>Нет, не идентичности.
Я читаю определени идентичности так: независит от состояния == сохраняется при изменении состояния.
Re[87]: ООП головного мозга
От: samius Япония http://sams-tricks.blogspot.com
Дата: 08.10.11 09:05
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


A>>Например, назначать коллекции стратегию сравнивания.

G>Коллекция тоже не тобой написана. Счиатй что у тебя изначально нет возможности переопределит операцию сравнения. Как будет выполняться операция Collection.Remove(item)
По назначенному компареру

A>>А вообще, вопрос был не в том, с какими проблемами мы можем столкнуться в текущем проекте, если с завтрашнего дня внезапно появится запрет на вызов ReferenceEquals и всего, что его использует.

G>Как минимум BCL не соберется\перестанет работать. Ты кстати скорее всего можешь сымитировать ситуацию через profile api, подменив вызов RefenceEquals, если он не intrsink какойнить.
Нет цели заставить работать BCL, нет нужды подменять вызов ReferenceEquals. Мы просто показываем, что остаемся в рамках OOP, ослабив идентичность ECMA~location. Других целей нет.

G>>>http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm

A>>Хорошая ссылка.
G>Конечно, прочитай внимательно все три определения. Все три верны и отражают разные аспекты одного и того же.
Все три допускают идентичность более слабую, чем ECMA.

G>>>Читай ECMA-335

A>>.NET — это единственная возможная реализация ООП?
G>Нет, но придумай другую где идентичность не сравнением через ссылок делается.
Вот мы этим и занимаемся.

A>>Определение через locations — слишком узко.

G>Для чего? Практика показывает что для CLR самое то. Ты не можешь расширить это определение (то есть получить идентичность без равенства ссылок) оставаясь в рамках ECMA-335.
Отказываясь от идентичности ECMA-335 мы уже выходим за его рамки просто по определению. Раз выходим — нет нужды в них обратно лезть.

A>>Если два объекта типа Something имеют одинаковый id, то они идентичны, независимо от того, что вернет object.ReferenceEquals.

G>Это бред. Твое определение идентичности опирается на состояние, что противоречит определению идентичности. Более того два объекта не будут ни идентичны, ни эквивалентны с точки зрения ecma-335
Мы же вышли за его рамки. Какой смысл продолжать измерять объекты екмой?

G>Источник твоего "вдохновения" в этом случае — РСУБД, которая не является ОО-системой если что

Ну и что? Я не понимаю, чего ты боишься? Что вдруг окажется что альтернативная идентичность может иметь место? Тебя ведь не заставляют ее использовать вместо ECMA?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.