у двух друзей есть общая машина красного цвета
каждый из друзей может сказать, какого цвета машина
пока первый друг уезжал, второй перекрасил машину с красного в черный
что ответит первый друг на вопрос, какого цвета машина?
для каждого из друзей машина — один и тот же объект или нет?
Здравствуйте, madlax, Вы писали:
M>у двух друзей есть общая машина красного цвета M>каждый из друзей может сказать, какого цвета машина M>пока первый друг уезжал, второй перекрасил машину с красного в черный
M>что ответит первый друг на вопрос, какого цвета машина? M>для каждого из друзей машина — один и тот же объект или нет?
Ты бы еще сказал "этично ли передавать объект по ссылке"
А сама проблема у тебя имеет отношение не к ссылкам, а к правильной работе с разделяемыми ресурсами.
Если ты хочешь чтобы машина была именно общая, то "сказать какого цвета машина" любой из друзей может только глядя на нее. Это и есть ссылка. Если же при попытке определить цвет не по объекту "машина" а по объекту "воспоминание о машине", которое не имеет прямой ссылки на машину — то тут и будут неоднозначности.
Если после перекраски машины у первого (уехавшего) друга спросить о цвете машины и он при этом "по ссылке" (по видеокамере, например), может на нее посмотреть — то он уверенно ответит что цвет у нее — черный.
[skipped]
Цвет машины — характеристика машины, а то, что первый друг думает о цвете машины — это сугубо его в данном случае не очень лестная характеристика.
Здравствуйте, madlax, Вы писали:
M>у двух друзей есть общая машина красного цвета M>каждый из друзей может сказать, какого цвета машина M>пока первый друг уезжал, второй перекрасил машину с красного в черный
M>что ответит первый друг на вопрос, какого цвета машина? M>для каждого из друзей машина — один и тот же объект или нет?
Вообще, язык дает вам возможности, а вы должны понимать, когда их нужно использовать, а когда нет. Однозначного ответа на этот вопрос вам никто не даст. В описанном случае ИМХО логичнее передавать отдельный обьект "воспоминание о машине", если второй друг не имеет доступа к данным машины в данный момент времени.
Здравствуйте, madlax, Вы писали:
M>у двух друзей есть общая машина красного цвета M>каждый из друзей может сказать, какого цвета машина M>пока первый друг уезжал, второй перекрасил машину с красного в черный
M>что ответит первый друг на вопрос, какого цвета машина? M>для каждого из друзей машина — один и тот же объект или нет?
Для каждого — один и тот же. Некоторые методы обращаются к машине ПО ССЫЛКЕ (аналог прямого наблюдения). Но одновременно у каждого объект по ссылке закеширован, и есть методы, которые работают именно с кешем ("воспоминания", как было выше сказано). Если моделировать в нашу реальную жизнь, то человек при вопросе "какого цвета у тебя машина" будет брать ответ из кеша.
Здравствуйте, VGn, Вы писали:
M>>что ответит первый друг на вопрос, какого цвета машина? M>>для каждого из друзей машина — один и тот же объект или нет?
VGn>Давайте обзовём тему SOA vs Proxy и отправим в Священные войны, которые я, например, не просматриваю.
Тут может даже дойти до ООП vs ФП. Ибо в ФП со ссылками как раз проблема. Из-за отсутствия identity объектов невозможны структуры данных, содержащих ссылки, что ИМХО один из минусов ФП, из-за которых возможности моделирования и прототипирования сильно ограничены.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, lse, Вы писали:
lse>>Тут может даже дойти до ООП vs ФП. ...
D>Не может. В ФП перекрашенная машина — другая машина D>
D>changeColour :: Car -> Car
D>
D>
Вот-вот. А почему в фп невозможны ссылки? Скажем, каждый из друзей содержит константную ссылку на машину. Эта сслыка константная (именно константная, не путать с final), т е машина не может перекрашиваться. То бишь побочные эффекты невозможны. Так почему такие ссылки невозможны в фп?
Здравствуйте, lse, Вы писали:
lse>Вот-вот. А почему в фп невозможны ссылки? Скажем, каждый из друзей содержит константную ссылку на машину. Эта сслыка константная (именно константная, не путать с final), т е машина не может перекрашиваться. То бишь побочные эффекты невозможны. Так почему такие ссылки невозможны в фп?
А потому, что нет разницы — ссылка она или копия. Есть значния, а конкретная реализация может выбирать, делать ли копию, лили просто передавать ссылку. Причём, как правило, добиваются за счёт хитроумных оптимизаций (преобразование в комбинаторы, memoize и т.п.) свести всё к присвоениям ссылок и избежать копирования громоздких объектов.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, lse, Вы писали:
lse>>Вот-вот. А почему в фп невозможны ссылки? Скажем, каждый из друзей содержит константную ссылку на машину. Эта сслыка константная (именно константная, не путать с final), т е машина не может перекрашиваться. То бишь побочные эффекты невозможны. Так почему такие ссылки невозможны в фп?
K>А потому, что нет разницы — ссылка она или копия.
Хм, и в самом деле никакой. Только вот тут такой момент есть. Представим АТД, состоящий из двух друзей, у каждого из друзей есть копия машины вместо ссылки. Тогда при изменении цвета машины нужно будет создать новый экземпляр АТД, и не забыть установить цвет машины в двух местах — у каждого из друзей. А в случае ссылки достаточно было бы изменить цвет машины один раз в одном месте. Понятно конечно, что такой подход чреват побочными эффектами, но все же в этом отдельном случае ручками поменьше работать приходится. Я уже не говорю о том, что памяти в 2 раза больше нужно для хранения экземпляра такого АТД (хотя реализация может в самом деле попытаться оптимизировать это).
PS пример машинами и друзьями дурацкий, ибо такой АТД нафиг не нужен. Но вот с кажем, моделирование конкретного технического объекта — например, электрической схемы.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, lse, Вы писали:
lse>>Вот-вот. А почему в фп невозможны ссылки? Скажем, каждый из друзей содержит константную ссылку на машину. Эта сслыка константная (именно константная, не путать с final), т е машина не может перекрашиваться. То бишь побочные эффекты невозможны. Так почему такие ссылки невозможны в фп?
K>А потому, что нет разницы — ссылка она или копия. Есть значния, а конкретная реализация может выбирать, делать ли копию, лили просто передавать ссылку. Причём, как правило, добиваются за счёт хитроумных оптимизаций (преобразование в комбинаторы, memoize и т.п.) свести всё к присвоениям ссылок и избежать копирования громоздких объектов.
+1
И более того, если копирование неизбежно, то ему может подвергаться только мутировавший кусок объекта, а не весь объект целиком. Но работа на уровне объектов с identity — это епархия компилятора/оптимизатора. Это как в SQL — порядок join'ов определяет не пользователь, а оптимизатор.
Здравствуйте, lse, Вы писали:
lse>Здравствуйте, konsoletyper, Вы писали:
K>>Здравствуйте, lse, Вы писали:
lse>>>Вот-вот. А почему в фп невозможны ссылки? Скажем, каждый из друзей содержит константную ссылку на машину. Эта сслыка константная (именно константная, не путать с final), т е машина не может перекрашиваться. То бишь побочные эффекты невозможны. Так почему такие ссылки невозможны в фп?
K>>А потому, что нет разницы — ссылка она или копия.
lse>Хм, и в самом деле никакой. Только вот тут такой момент есть. Представим АТД, состоящий из двух друзей, у каждого из друзей есть копия машины вместо ссылки. Тогда при изменении цвета машины нужно будет создать новый экземпляр АТД, и не забыть установить цвет машины в двух местах — у каждого из друзей. А в случае ссылки достаточно было бы изменить цвет машины один раз в одном месте. Понятно конечно, что такой подход чреват побочными эффектами, но все же в этом отдельном случае ручками поменьше работать приходится. Я уже не говорю о том, что памяти в 2 раза больше нужно для хранения экземпляра такого АТД (хотя реализация может в самом деле попытаться оптимизировать это).
Это всё ООП-рассуждения. Что у тебя в предметной области-то, одна машина? Тогда тупл такой
(Friend, Friend, Car)
А если две разных — работай с туплом туплов
((Friend,Car), (Friend, Car))
lse>PS пример машинами и друзьями дурацкий, ибо такой АТД нафиг не нужен. Но вот с кажем, моделирование конкретного технического объекта — например, электрической схемы.
Здравствуйте, deniok, Вы писали:
lse>>Хм, и в самом деле никакой. Только вот тут такой момент есть. Представим АТД, состоящий из двух друзей, у каждого из друзей есть копия машины вместо ссылки. Тогда при изменении цвета машины нужно будет создать новый экземпляр АТД, и не забыть установить цвет машины в двух местах — у каждого из друзей. А в случае ссылки достаточно было бы изменить цвет машины один раз в одном месте. Понятно конечно, что такой подход чреват побочными эффектами, но все же в этом отдельном случае ручками поменьше работать приходится. Я уже не говорю о том, что памяти в 2 раза больше нужно для хранения экземпляра такого АТД (хотя реализация может в самом деле попытаться оптимизировать это).
D>Это всё ООП-рассуждения. Что у тебя в предметной области-то, одна машина? Тогда тупл такой D>
D>(Friend, Friend, Car)
D>
Одна машина, но она общая для обеих друзей. Если сделать, как у тебя выше, то нужно, чтобы функции (методы) Friend могли работать с Car. Поэтому нужно, чтобы Car был в каждом из них (копии Car), либо предавать Car из родителя при вызове функции, где этот Car требуется.
Скажем на псевдоязыке:
type Friend
{
Car car;
Car getCarColor = return getColor(car)
}
type Family
{
Friend friend1;
Friend friend2;
Color getFamilyCarColor = getCarColor(friend1)
}
либо
type Friend
{
Car getCarColor car = return getColor(car)
}
type Family
{
Friend friend1;
Friend friend2;
Car car;
Color getFamilyCarColor = getColor(car)
}
lse>>PS пример машинами и друзьями дурацкий, ибо такой АТД нафиг не нужен. Но вот с кажем, моделирование конкретного технического объекта — например, электрической схемы.
D>И что? Не поддаётся декларативному описанию?
Представь себе, нет. Декларативное описание суть дерево. А там такие бл-кие взаймосвязи между элементами схемы, без ссылок никак.
Здравствуйте, lse, Вы писали:
lse>Представь себе, нет. Декларативное описание суть дерево. А там такие бл-кие взаймосвязи между элементами схемы, без ссылок никак.
type Graph 'v 'e = Set 'v * Set 'e
Так?
А ещё есть всякие непонятные зипперы и т.д. Но там без матана не разберёшься. Зато они быстрее
Меня всегда в ООП-никах удивляет, что вместо задачи, которую нужно решить, они выкатывают объектную модель. Что в том, что ты написал, не содержится в преамбуле "Два друга, общая машиина, машину можно красить"
lse>>>PS пример машинами и друзьями дурацкий, ибо такой АТД нафиг не нужен. Но вот с кажем, моделирование конкретного технического объекта — например, электрической схемы.
D>>И что? Не поддаётся декларативному описанию?
lse>Представь себе, нет. Декларативное описание суть дерево. А там такие бл-кие взаймосвязи между элементами схемы, без ссылок никак.
Ага, декларативное описание — граф, в узлах которого может лежать что угодно, в т.ч. функции, моделирующие "бл-кие взаймосвязи"
M>у двух друзей есть общая машина красного цвета M>каждый из друзей может сказать, какого цвета машина M>пока первый друг уезжал, второй перекрасил машину с красного в черный
M>что ответит первый друг на вопрос, какого цвета машина? M>для каждого из друзей машина — один и тот же объект или нет?
Поправка, первый увозит с собой не машину, и даже не ссылку на машину. Он увозит с собой объект "представления о машине", в который копируются те свойства машины, которые он считает существенными. Поэтому он на запрос цвета машины извлечет данные именно из представлений, а не из машины.
Вообще говоря он всегда будет любые данные извлекать из представлений, которые, вообще говоря могут даже не соответствовать реальности. Скажем первый друг дальтоник, и не различает красный. Тогда он, порывшись в своих представлениях, ответит что цвет машины серый.
Здравствуйте, madlax, Вы писали:
M>у двух друзей есть общая машина красного цвета M>каждый из друзей может сказать, какого цвета машина M>пока первый друг уезжал, второй перекрасил машину с красного в черный
А также перебил номера кузова и мотора и продал по поддельному техпаспорту.
Спрашивается: что ответит первый друг, когда вернётся?
Это и называется — инвалидировать ссылку/указатель
Перекуём баги на фичи!
