Re[100]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 25.12.11 21:39
Оценка:
DG>>вообще, чтобы фраза "ты должен указать способ отличать ссылку-объект от объекта не ссылки" имела хоть какой-то смысл, для начала необходимо ввести, что такое ссылка в ООП вообще, и что такое ссылка в построении 1, при этом что такое ссылка в построении 0 было понятно, потому что использование понятие ссылка из .net-ных понятий, а не из понятий ООП.
S>А ты давал определение ссылки?

в данном случае, я не обязан его давать. потому что внутри построения 1 я это понятие не использовал.
и я не видел определения, в котором было бы написано, что понятие "ссылка" требуется для ООП

S> Если нет, почему я не могу использовать понятие из .net? Ты ведь упоминаешь ссылки в своих тезисах...


использовать можешь, но напрямую в рамках построения 1 смысла оно уже не имеет.
вопрос может быть другим: во что переходит .net-ссылка из построения 0 при переходе в построение 1, и во что переходит объект не ссылка из построения 0 при переходе в построение 1?
Re[102]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 25.12.11 21:56
Оценка:
DG>>не тормози.
S>Да, с этим я тормознул.

S>А покажи мне существование обратного элемента для false относительно сложения (and) для поля 2. Напомню, что сложение с обратным элементом должно дать ноль, т.е. true.


множество (true, false) есть взаимно-однозначное отображение множества (false, true).
при этом операция or переходит в операцию and и наоборот.
дальше догадаешься, как выглядит алгоритм построения обратного элемента?
Re[100]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 25.12.11 22:00
Оценка:
DG>>определению удовлетворяет, а остальное это всё религия
S>Не удовлетворяет.

тому которое ты приводил — удовлетворяет, этому определению что угодно удовлетворяет.

DG>>под определение "идентичные объекты" подходит, остальное — поиски еретиков.

S>Не подходит.

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

DG>>нет, же конечно.

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

в построении 0 существуют, в построении 1 — не существуют, пока не приведено конструктивного определения, что такое ссылка
Re[102]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 25.12.11 22:26
Оценка: 1 (1)
S>А покажи мне существование обратного элемента для false относительно сложения (and) для поля 2. Напомню, что сложение с обратным элементом должно дать ноль, т.е. true.

на самом деле, я действительно не прав. извини.
or и and не образуют группу, хотя я почему-то считал обратное.

зы
значит в построении 2 придется брать в качестве операции +: операцию эквивалентности
Re[65]: Immutable object
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.12.11 03:48
Оценка:
Здравствуйте, vdimas, Вы писали:

V>ЧТД. Наконец ты сознался. Не верно. Декларативность — это относительное понятие, ортогональное к побочным эффектам. Если есть неких два уровня абстракции, то один из них декларативен к другому, если примитивы более высокоуровневой абстракции выражаются в терминах операций над примитивами более низкоуровневой.

Это определение — ваше личное изобретение. Оно не имеет никакого отношения к традиционной трактовке разницы между императивным и декларативным программированием.
Но это бы ничего, если бы определение имело хоть какой-то практический смысл. Но нет — не имеет. В частности, по вашему определению РА одновременно более декларативна чем РИ, и менее декларативна чем оно же, и мы возвращаемся к тому, с чего начали: РА и РИ одинаково декларативны.

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

S>>А могут и быть.
V>Ну так вот тебе и умножение вместо сложения в том случае, где нет. Видел порой в плане запроса операцию сортировки промежуточных результатов перед join? А сложность алгоритмов внешней сортировки какова?
Вы путаете общее с частным, делая всеобщее утверждение на основе некоторго частного случая.

S>>Нет. Реляционная модель была разработана не для джойнов по "произвольной формуле". А джойны по значению атрибута отлично работают и для больших внешних хранилищ.

V>Еще раз — только при упорядоченности внешнего ключа одной и основного ключа другой таблицы.
Зачем вы продолжаете делать некорректные всеобщие утверждения? Очевидно, что для перехода от O(M*N) к O(M*log(N)) достаточно отсортированности только одного аргумента. И если мы говорим конкретно о таблицах и внешних ключах, как вы настаиваете, а не об общем случае табличных аргументов, то отсортированность — таки самый частый случай. Поэтому не надо думать, что ускорение вычисления каждого из аргументов на 50% даст вам 125% улучшения в скорости джойна.

V>У меня тоже свой опыт... когда были пни-200, то нейтивный сервер, со складом-бухгалтерией, использующий DCOM для клиентов в одноранговой сети с низлежащей базой на JET просто летал как бабочка, а поставили выделенный MS SQL в кач-ве базы на втрое более мощный комп — и все стало гораздо печальнее минимум на год, пока еще вдвое характеристики компов не подросли. Это и спасло при росте базы, потому как пришлось уже делать меньше оперативный период, что не всегда удобно.

Я ваш опыт обсуждать не буду. Не глядя в исходники невозможно сказать, движок ли виноват или плохо написанное приложение.

V>Тогда твоя боязнь очень избирательна, на примере разницы логического и физического плана запроса. Ты взял, да и привязался к конкретной реализации конкретной СУБД.

Я нигде не привязался к конкретной реализации. Разница между логическим и физическим планами есть везде, где есть оптимизатор запросов. Читайте литературу.

V>Да и вообще, сия боязнь странная. Ведь о чем мы там изначально? Я считал, что надо знать хотя бы самые популярные техники исполнения абстракций, чтобы писать адекватные современной аппаратуре программы. Поэтому знания техник исполнения замыканий в используемом инструменте всяко на пользу. Особенно если это замыкания дотнета, приводимые тут же к делегатам. Ты же считаешь, что эти знания во вред по приписываемой оппонентам несуразной причине "монолитности в голове". Демагогия как она есть.

Нет, я не считаю, что сами по себе знания во вред. Вред приносят заблуждения. Вы продолжаете их изрекать со скоростью 2-5 заблуждения за пост. И я вижу некоторую систему в отдельных заблуждениях. Как глядя на реку, я не вижу валунов, лежащих на дне; но по ряби на поверхности я могу делать выводы об их наличии и расположении.
Так же и здесь — глядя на форум, я не вижу валунов у вас в голове. Но они проявляются в виде ряби на поверхности — некорректных утверждений, которые вы делаете.

V>Ты ткнул несоответствием в плане возможной неуникальности промежуточных и даже итоговых данных.

V>Давай уже ближе к телу. Обоснуй, как более широкие возможности SQL мешают использовать наработки более узкой модели?
ОМГ. Вы сейчас какое конкретно моё утверждение пытаетесь оспорить? Найдите его и процитируйте. Я понимаю, вам удобнее спорить с тезисом, которого я не высказывал. Но всё же постарайтесь держаться в рамках беседы.

V>Таки придется, иначе просто заумная балаболка. Реализация всегда отличается от модели, на то она и модель, я не понимаю, почему у тебя проблема конкретно в СУБД.

Да у меня-то нигде проблем нет. Я вам СУБД привёл как один только пример. Я не виноват, что вы полезли в дебри, в которых плохо разбираетесь.
V>Ведь обыгрывают переполнения целых чисел в программах?
Да, я вам даже привёл пример на эту тему.

V>И даже ограничения по точности чисел в плавающей. Однако же не мешает пользоваться всем аппаратом математики в вычислениях.

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

V>Улыбнуло, я думал ты уже понял, что тебе говорили.

V>Покажи-ка мне стоимость нахождения записи в случае кластерного индекса внутри страницы, если размер самой записи нефиксированный?
Что вы называете "нахождением"? Указать, где начинается запись? Или прочесть некоторое поле F, не входящее в ключ индекса? Если второе — то стоимость в терминах логических чтений, очевидно, равна log(N, KeysPerPage)+ PagesPerRecord, где PagesPerRecord — количество страниц, занятых записью.
Встречный вопрос: а что, для некластерного индекса ситуация будет какой-то другой? И вообще, давайте так: вы прекратите намекать с умным видом, а просто напишете своими словами вид логической цепочки, которая приводит от утверждения "кластерный индекс — такой вид индекса, при котором значения ключей хранятся в самих данных, а порядок расположения данных определяется порядком значений ключа" к утверждению "размер записи таблицы, по которой строится кластерный индекс, должен быть меньше размера страницы".
И, кстати, выходные прошли. Что там у вас со смелым экспериментом по определению количества логических чтений в кластерных и некластерных индексах? Удалось получить разницу хотя бы в одну страницу?

V>Э нет, аргументами для рассмотренного случая являются атрибуты и скалярные выражения, т.е. заведомо уже вычисленные вещи, а вот декомпозиция самих ограничений и возможность смены их порядка при повторных "накатываниях" ограничений действительно управляется коммутативностью операций составляющих аналитический вид ф-ии ограничения. Ты путаешь применение произвольной ф-ии к отношению (чего НЕТ в реляционной алгебре по определению, все операции над отношениями перечисленны), и собственно ф-ию ограничения, которая всегда над атрибутами.

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

S>>Понятно. Просто есть два движка с одинаковым названием: Jet Blue и Jet Red. Внутри они принципиально разные.

V>Ну, в VB тоже была своя встроенная ADO, так же была либа для С и ADO-обертка над ней в MFC.
Обёртки тут ни при чём. Я про engine. В MS Access использовался Jet Red. Jet Blue используется в Microsoft Exchange и Active Directory.

V>Коль индекс неуникальный и мы договорились, что в отличие от основной таблицы этот индекс может быть кластерным, то по основной таблице для выборки M неуникальных записей по одному ключу из таблицы размером N понадобится O(log N)+O(M) чтений.

V>Для случая кластерного индекса по нашей искусственой избыточной таблицы порядок будет O(log N) — это время на поиск первого значения, остальные достаются за O(1) или даже за трудоемкость равную 0, т.к. преполагаются повторные чтения с той же страницы.
По-моему, вы хитрите. Вот у нас таблица T(A1..Ax, IK). В ней IK — это один или несколько атрибутов, входящих в ключ нашего неуникального индекса. A1..Ax — атрибуты, не входящие в ключ индекса.
Итак, поиск значений атрибутов A1..Ax по фиксированному значению ключа IK = IK1, занимает, как вы верно подметили, log(N) чтений для нахождения списка RID, и ещё M чтений для собственно доступа к записям (bookmark lookup).
Что именно вы собрались "обыгрывать" в дополнительной таблице T2? Вынести туда IK и ссылку на PK основной таблицы? Ну так для чтения атрибутов A1..Ax вы получите по-прежнему log(N) чтений на поиск значения, + log(N)+M чтений на доступ к основной таблице.
Если вы планируете включить в T2 что-то из A1..Ax, то их же можно включить в тот же неуникальный индекс и иметь те же преимущества доступа за log(N) без накладных расходов, связанных с поддержкой отдельной таблицы.

V>Для случая вставки в кластерный индекс всегда трудоемкость минимум O(n), помимо операции обновления дерева индекса, которая будет одинаковой стоимости что для исходной таблицы, что для избыточной. Но с этой сложностью борются, оставляя "зазоры" после удаления, чтобы свести ее ближе к логарифму.

Откуда вы взяли трудоёмкость вставки в O(N)? Стоимость всегда логарифмическая — это же дерево.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[65]: Immutable object
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.12.11 04:05
Оценка:
Здравствуйте, vdimas, Вы писали:


V>Это будет эквивалент такой операции:

V>select X.* from X inner join Y on X.x1 = Y.y1

V>Что ближе к такой последовательности 3-х операций РА, являющихся решением обоих уравнений:

V>tmp1 = X x Y
V>tmp2 = ограничение(x1=y1) tmp1
V>result = проекция{x1, x2, .. xN} tmp2
V>Можно записать в виде одной формулы, не суть, все равно будет 3 примитивные операции РА в ней.
Или две. Задача решается через переименование и полуджоин. Или через equi-джоин и проекцию. Но не суть.
Суть в том, что порядок вычисления X и Y не важен. Можно сначала рассчитать Y, а потом уже X. А можно — наоборот. Нам не важно, какие формулы стоят на местах X и Y, т.к. эти формулы заведомо не имеют побочных эффектов. Именно в этом суть декларативности РА.

V>Нету сайд-эффектов, а последовательность вычислений есть.

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

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

G>>Это будет перестановка вычислений. Просто у тебя в мозгу засело что "порядок вычислений" == "порядок аргументов", что как раз не верно в большинстве случаев.

V>Знаешь ли, если формулы ДРУГИЕ, то они просто ДРУГИЕ. Не надо ничего изобретать. А для ДУРГИХ формул может быть коль угодно другой порядок вычислений. Разумеется, что все варианты выражений РА, эквивалентных одному РИ, приводимы друг к другу. Но я утверждал, что это в общем случае не возможно на уровне РА, только через уровень РИ, т.е. через подстановку отношений, управляемую зависимостями конкретной схемы. Мы же, на самом деле, не рассмотрели целый большой класс преобразований, который делается НАД РА. А спор вообще возник вокруг случая применения РА уже на уровне выбора — какие индексы для сканирования таблицы использовать при составлении "физического плана запроса". Я наоборот вижу, что как раз здесь весь аппарат реляционной теории и может разгуляться, ведь у базы есть вся информация о декомпозиции таблицы и ее индексов.



V>Не совсем так. Я уже пояснял каждый пример, где речь действительно идет об оптимизации. Например, повторные ограничения никто не делает, они объдиняются по AND ф-ий ограничений. но это происходит еще до РА, еще во время автоматической генерации алгоритма запроса.

В целом правильно, хотя и несколько наивно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[101]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.12.11 06:55
Оценка:
Здравствуйте, DarkGray, Вы писали:


DG>>>определению удовлетворяет, а остальное это всё религия

S>>Не удовлетворяет.

DG>тому которое ты приводил — удовлетворяет, этому определению что угодно удовлетворяет.


DG>>>под определение "идентичные объекты" подходит, остальное — поиски еретиков.

S>>Не подходит.

DG>приведи логический вывод.

ты сам сказал, что идентичность может быть неопределена.

DG>(хотя это может быть тяжело для человека, которые не понимает как связаны между собой операции and и or.)

Это ты о том, что они не образуют группу?

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

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

DG>в построении 0 существуют, в построении 1 — не существуют, пока не приведено конструктивного определения, что такое ссылка

Но это не мешает тебе использовать термин для своего построения
Re[103]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.12.11 07:00
Оценка:
Здравствуйте, DarkGray, Вы писали:


S>>А покажи мне существование обратного элемента для false относительно сложения (and) для поля 2. Напомню, что сложение с обратным элементом должно дать ноль, т.е. true.


DG>на самом деле, я действительно не прав. извини.

DG>or и and не образуют группу, хотя я почему-то считал обратное.

DG>зы

DG>значит в построении 2 придется брать в качестве операции +: операцию эквивалентности
И что будет обратным элементом для false?
Re[104]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 26.12.11 10:30
Оценка:
DG>>значит в построении 2 придется брать в качестве операции +: операцию эквивалентности
S>И что будет обратным элементом для false?

false
Re[105]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.12.11 10:33
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>>>значит в построении 2 придется брать в качестве операции +: операцию эквивалентности

S>>И что будет обратным элементом для false?

DG>false

Точно, эквивалентность же.

С "полем 1" будем разбираться?
Re[106]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 26.12.11 10:43
Оценка:
S>С "полем 1" будем разбираться?

а что с ним разбираться, если оно сейчас такое же как поле 2 с точностью до взаимно-однозначного отображения
Re[107]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.12.11 10:45
Оценка:
Здравствуйте, DarkGray, Вы писали:


S>>С "полем 1" будем разбираться?


DG>а что с ним разбираться, если оно сейчас такое же как поле 2 с точностью до взаимно-однозначного отображения

Можешь указать обратный элемент для true на операции or?
Re[65]: Immutable object
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.12.11 10:56
Оценка: +1
Здравствуйте, vdimas, Вы писали:

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


V>>>>>А как мы ее представим в SQL или РА?

G>>>>Функция, которая всегда возвращает пустую реляцию.

V>>>Я таки настаиваю ее изобразить. Потому что если это именно ф-ия как "черный ящик", то аргументы будут для такой ф-ии вычислены, хоть и не будут использованы внутри самой ф-ии, а если не черный ящик, то таки хотелось посмотреть на примере SQL (откуда она пойдет в РА).

G>>SQL, в отличие от РА предполагает аппликативный порядок вычислений. Найдешь реализацию SQL где это не так — спокойно сделаю.

V>И где это ограничение явно указано?

В семантике функций.

V>Опять же, ты не забыл замечание про минимум 2 вида аналитических выражений в РА — это собственно выражения РА и выражения-ограничения в выборке или разновидностях соединений. Какой уровень ты имел ввиду?

А ты какие когда говорил про коммутативность?


G>>Значит можно аналогичное. Сути не меняет.


V>Меняет. Ты же походя присвоил коммутативность некоей произвольной ф-ии, показав затем, что она нихрена не коммутативна из своего определения. Меня это улыбнуло, понятное дело, просто любопытно таки докопаться до всей цепочки рассуждений, которое могло ТАКОЕ породить.


Я привел функцию, которая формальному определению коммутативности соответствует. У тебя какое-то другое определение?

V>>>Речь о коммутативных операциях, а они даны были по ссылке. В остальном рассуждения такие же как для предыдущего примера, т.е. ты изобрел не операцию РА, а просто некую ф-ию и спекулируешь на порядке вычисления ее аргументов. Ты еще не забыл, ф-ии в РА применимы к каждому кортежу, а не ко всему отношению?

G>>А что мешает такую функцию представить как функцию отношения? Например t — отношение, s — органичение, f — функция. если рассмотреть композицию s(f(t)), то она не равна f(s(t)), но ведь никто не мешает построить ограничение s' такое что s(f(t)) = f(s'(t)), причем при некоторых условиях на для f получится s семантически эквивалентно s'. Причем эти условия элементарно можно проверить.

V>Мешает то, что ф-ии ограничения, где аргументами идут отношения — это уровень исчисления кортежей, но не уровень РА. Задача РА как раз преобразовать "структурные" формулы РИ в "плоские" операции РА, где ф-ии ограничения будут в терминах операций над атрибутами кортежей. Курить определение ограничения в РА.

То есть ты признаешь что далеко не любые коммутативные функции соответствуют тому что ты написал. Теперь давай выясним какие все таки соответствуют.


V>Попробуй кстате, "просто поменять вычисления местами" (С), мне любопытно. Замечания про ленивые vs энергичные я уже делал — ничего не меняется на уровне вычисления атрибутов кортежей.


G>>При этом f(s'(t)) может вычисляться быстрее, чем s(f(t)). И конечно любой движок субд пытается по-максимуму такие преобразования делать.


V>Я это понимаю, и даже давал больше по этой теме, но ты невнимательно читал. Да, именно, уровень РА нужен для того, чтобы в его терминах породить ВСЕВОЗМОЖНЫЕ решения исходной формулы, потому что коль на уровне РА отсутствуют ф-ии над отношениями, т.е. отстуствует вложенность в ограничениях, т.е. отсутствует рекурсия формул, становится возможным произвести оценку сложности операций. Так вот, там, где некий автоматический движок, перечисляющий всевозможные решения в терминах РА знает об декомпозиции исходной схемы на отношения, он может не просто породить s'(t), он может породить s'(t'), где t' — другое отношение, но сохраняющее зависимости исходной схемы. Прочувствовал разницу?


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


G>>Конечно движок субд опирается на семантику того что происходит и некоммутативность некоторых операций в общем случае ему не помеха.


V>Так вот, к большому пребольшому сожалению, движки СУБД не имеют понятия о семантике, т.к. обычно не реализовано одно из самых важных правил Кодда, позволяющее сохранять зависимости исходного прикладного отношения и проведенной конкретной декомпозиции. СУБД не делает никаких предположений относительно избыточности данных, принадлежащих одному домену и одному "логическому" атрибуту в рамках всей схемы.


Это тебя совсем не туда понесло.

V>>>Да, именно. Утверждал что перестановку в общем случае проводить нельзя. Можно только для случаев, являющихся заведомо коммутативными.

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

V>Нету сайд-эффектов, а последовательность вычислений есть.

Она всегда есть, но она не совпадает с порядком записи аргументов и композиции функций.

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

А что значит "зависимые вычисления" если у нас есть ленивость? А по сути ничего. Если итоговый результат не не нужен или нужен не полностью, то "зависимые вычисления" можно и не вычислять. И опять таки коммутативность тут никакой роли не играет.
Re[102]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 26.12.11 11:00
Оценка:
DG>>приведи логический вывод.
S>ты сам сказал, что идентичность может быть неопределена.

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

DG>>в построении 0 существуют, в построении 1 — не существуют, пока не приведено конструктивного определения, что такое ссылка

S>Но это не мешает тебе использовать термин для своего построения

конечно. алгоритм построения 1 работает в терминах построения 0, поэтому он может использовать понятия из построения 0, но внутри построения 1 эти понятия уже становятся бессмысленными

как отдаленный пример:
(x+y)*(x+y) = x+y //построение 0
x*x = x //построение 1, построенное заменой переменной x = x+y

и в рамках построения 1 бессмысленно говорить, а чему же равен y? он там просто не определен.

мир -> построение -> мир 1
когда построение переопределяет какие-то элементы, то в мир 1, в общем случае, переходят лишь независимые элементы от переопределенных элементов. например, в примере выше операция * и операция + автоматически перешли в мир 1, при этом использование операции + выродилось.
ссылка же это зависимое (производное) понятие от объекта, потому оно меняется при переходе, если переопределяется понятие объекта.
как именно меняется зависит от того, как оно определено в рамках данной теории.
соответственно, как только ты скажешь, что такое ссылка в рамках теории ООП, то я тебе скажу как именно оно меняется при переходе.
Re[108]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 26.12.11 11:05
Оценка:
DG>>а что с ним разбираться, если оно сейчас такое же как поле 2 с точностью до взаимно-однозначного отображения
S>Можешь указать обратный элемент для true на операции or?

true — это 0, а or — это *, поэтому это требование его не касается.
у 0 для операции * нет обратного элемента, и это зафиксировано в свойствах поля
Re[103]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.12.11 04:43
Оценка:
Здравствуйте, DarkGray, Вы писали:


DG>>>приведи логический вывод.

S>>ты сам сказал, что идентичность может быть неопределена.

DG>это лишь означает, что:

DG>1. во-первых, для данного программы можно определить как хочется
DG>2. во-вторых, что для данной программы такое построение делать не стоит, но из этого не следует, что его не стоит делать для произвольной программы
Это означает что твоя идентичность не позволяет отличать объекты.

DG>>>в построении 0 существуют, в построении 1 — не существуют, пока не приведено конструктивного определения, что такое ссылка

S>>Но это не мешает тебе использовать термин для своего построения

DG>ссылка же это зависимое (производное) понятие от объекта, потому оно меняется при переходе, если переопределяется понятие объекта.

DG>как именно меняется зависит от того, как оно определено в рамках данной теории.
То есть ты не знаешь, но термином пользуешься.
DG>соответственно, как только ты скажешь, что такое ссылка в рамках теории ООП, то я тебе скажу как именно оно меняется при переходе.
Re[109]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.12.11 04:49
Оценка:
Здравствуйте, DarkGray, Вы писали:


DG>>>а что с ним разбираться, если оно сейчас такое же как поле 2 с точностью до взаимно-однозначного отображения

S>>Можешь указать обратный элемент для true на операции or?

DG>true — это 0, а or — это *, поэтому это требование его не касается.

DG>у 0 для операции * нет обратного элемента, и это зафиксировано в свойствах поля

Да я забыл что у тебя там Xor, а не or.

Давай вернемся к полю 2, где у тебя эквивалентность в качестве аддитивной операции.
Что там у тебя является нулевым элементом?
Re[110]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 27.12.11 10:59
Оценка:
S>Давай вернемся к полю 2, где у тебя эквивалентность в качестве аддитивной операции.
S>Что там у тебя является нулевым элементом?

написано же:
поле 1:
операция + поля: xor
операция * поля: and
нулевой элемент поля: false
единичный элемент поля: true
поле 2:
операция + поля: ==
операция * поля: or
нулевой элемент поля: единичный элемент поля 1 (true)
единичный элемент поля: нулевой элемент поля 1 (false)
Re[104]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 27.12.11 11:06
Оценка:
DG>>это лишь означает, что:
DG>>1. во-первых, для данного программы можно определить как хочется
DG>>2. во-вторых, что для данной программы такое построение делать не стоит, но из этого не следует, что его не стоит делать для произвольной программы
S>Это означает что твоя идентичность не позволяет отличать объекты.

да, для "плохих" программ не позволяет. зато позволяет в хороших

DG>>>>в построении 0 существуют, в построении 1 — не существуют, пока не приведено конструктивного определения, что такое ссылка

S>>>Но это не мешает тебе использовать термин для своего построения

DG>>ссылка же это зависимое (производное) понятие от объекта, потому оно меняется при переходе, если переопределяется понятие объекта.

DG>>как именно меняется зависит от того, как оно определено в рамках данной теории.
S>То есть ты не знаешь, но термином пользуешься.

я встречал штук 20 определений понятия ссылка (часть из них хорошая, часть не очень).
но на текущий момент, именно ты узурпировал право решать — определения какого авторитета считать правильным.
поэтому я жду, когда ты примешь решение какое определение ссылки ты считаешь правильным.
Re[111]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.12.11 12:04
Оценка:
Здравствуйте, DarkGray, Вы писали:


S>>Давай вернемся к полю 2, где у тебя эквивалентность в качестве аддитивной операции.

S>>Что там у тебя является нулевым элементом?

DG>написано же:

DG>
DG>поле 1:
DG>операция + поля: xor
DG>операция * поля: and
DG>нулевой элемент поля: false
DG>единичный элемент поля: true
DG>поле 2:
DG>операция + поля: ==
DG>операция * поля: or
DG>нулевой элемент поля: единичный элемент поля 1 (true)
DG>единичный элемент поля: нулевой элемент поля 1 (false)
DG>


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