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

I>>Поскольку свою точку зрения ты отказываешься пояснить, смысла продолжать нету
S>Я пытался, но ты все время подразумеваешь что-то свое и пытаешься опровергнуть.

Дай ка ссылку, где ты пояснил напримерах свое высказывание ?

S>Вот ответь, контракт IEnumerator подразумевает иммутабельность?

Нет, в эти игры мы играть не будем. Сперва дай внятную, проверяемую трактовку своего высказывания, а потом продолжим.

Не способен приводить примеры — просто не отвечай, не переживай, не ты первый

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

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

I>>>Поскольку свою точку зрения ты отказываешься пояснить, смысла продолжать нету
S>>Я пытался, но ты все время подразумеваешь что-то свое и пытаешься опровергнуть.

I>Дай ка ссылку, где ты пояснил напримерах свое высказывание ?

Пытался пояснить и пытался пояснить на примерах — это разные вещи, не мухлюй

S>>Вот ответь, контракт IEnumerator подразумевает иммутабельность?

I>Нет, в эти игры мы играть не будем. Сперва дай внятную, проверяемую трактовку своего высказывания, а потом продолжим.
Какого именно высказывания? Мне все больше кажется, что ты начал спорить с тем, чего не понял. Ну да я тут не причем.

I>Не способен приводить примеры — просто не отвечай, не переживай, не ты первый
Я уже приводил примеры. Iterator, Observer, State. Что я получил в ответ?
Цитирую

yield return
...
CurrentState().Method()

Потом я начал выяснять, не считаешь ли ты IEnumerator иммутабельным. А ты отказываешься играть в эти игры.

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

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

I>>Дай ка ссылку, где ты пояснил напримерах свое высказывание ?
S>
S>Пытался пояснить и пытался пояснить на примерах — это разные вещи, не мухлюй

Я не заметил что бы ты пытался подвести. А вот выпендрёжа разного сорта было более чем достаточно. Может это по твоему "подвести" — я не в курсе

I>>Нет, в эти игры мы играть не будем. Сперва дай внятную, проверяемую трактовку своего высказывания, а потом продолжим.
S>Какого именно высказывания? Мне все больше кажется, что ты начал спорить с тем, чего не понял. Ну да я тут не причем.

Ну да, ты чисто д'артаньян, выдал нечто в духе КО и после этого "ни при чем"

I>>Не способен приводить примеры — просто не отвечай, не переживай, не ты первый

S>Потом я начал выяснять, не считаешь ли ты IEnumerator иммутабельным. А ты отказываешься играть в эти игры.

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

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

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

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

I>Ну это как бы просто — ты делаешь странные заявления, никак не поясняя свои высказывания, да еще хочешь что бы тебе все по полочкам раскладывал.

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

Все что я формулировал было достаточно внятно для моего собеседника, во всяком случае от него претензий не последовало. Ты походу что-то не понял и кинулся доказывать что я не прав. Я тебе что-то должен после этого?

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

G>>Вот сейчас занимаюсь веб-приложением для автоматизации проектного управления. У меня там нет ни одного объекта, который является моделью объекта реального мира.

DG>но значит у тебя модель другого мира. модель проекта, например.
Ничего не получится. ООП так же плохо подходит для описания "моделей первого порядка", как и для описания реального мира.
Возьмём тот же проект. Он обладает идентичностью и состоянием. Можем ли мы построить класс, описывающий объект "проект"?
Очень сомнительно. "Поведение" проекта не является прямой реакцией на происходящие с ним события; окажется, что детали того, как проект меняет своё состояние не являются для него "внутренне присущими". Ровно наоборот: ограничения на эволюцию состояний проекта определяются внешними по отношению к нему бизнес-правилами. Попытка инкапсулировать бизнес-правила внутрь класса "проект" обречена на провал.
Кроме того, на разных стадиях жизненного цикла поведение проекта настолько отличается, что мы затруднимся построить единый класс для описания этого поведения. С точки зрения ООП проект выглядит так, как будто его класс меняется радикальным образом. А в ООП связь класса с объектом является священной и неизменной.
Конечно же, паттерны для разрешения этого (и других) противоречия существуют и хорошо известны. Но их применение неизбежно приводит к тому, что мы получаем катастрофически далёкое от оригинальной модели описание.
В том же управлении проектами вместо "проекта" появятся какие-то абстрактные "issue", "transition", "attribute", "requirement" и мы быстро перейдём к программированию собственно прикладной логики на основе совсем другого "языка", в котором нет никакого ООП.

S>Возьмём тот же проект. Он обладает идентичностью и состоянием. Можем ли мы построить класс, описывающий объект "проект"?

конечно, можно. как минимум можно в виде набора классов

S>Очень сомнительно. "Поведение" проекта не является прямой реакцией на происходящие с ним события; окажется, что детали того, как проект меняет своё состояние не являются для него "внутренне присущими". Ровно наоборот: ограничения на эволюцию состояний проекта определяются внешними по отношению к нему бизнес-правилами. Попытка инкапсулировать бизнес-правила внутрь класса "проект" обречена на провал.

и кто сказал, что класс должен описывать лишь внутреннее состояние объекта? и не должен описывать поведение набора объектов?
есть даже набор паттернов, которые описывают именно поведение набора объектов

S>Кроме того, на разных стадиях жизненного цикла поведение проекта настолько отличается, что мы затруднимся построить единый класс для описания этого поведения. С точки зрения ООП проект выглядит так, как будто его класс меняется радикальным образом. А в ООП связь класса с объектом является священной и неизменной.

но это лишь main-stream языки утверждают, что класс у объекта должен быть статичным

S>Конечно же, паттерны для разрешения этого (и других) противоречия существуют и хорошо известны. Но их применение неизбежно приводит к тому, что мы получаем катастрофически далёкое от оригинальной модели описание.
S>В том же управлении проектами вместо "проекта" появятся какие-то абстрактные "issue", "transition", "attribute", "requirement" и мы быстро перейдём к программированию собственно прикладной логики на основе совсем другого "языка", в котором нет никакого ООП.

как это без ООП, если issue, transition, attrubute и requirement — это есть всамделишные объекты?

Здравствуйте, DarkGray, Вы писали:
DG>конечно, можно. как минимум можно в виде набора классов
И чему в "реальной модели" будут соответствовать эти классы из "набора"?
В реальности объектная модель, якобы построенная на основе той модели, которая описывает предмет автоматизации, стремительно разъезжается.

DG>и кто сказал, что класс должен описывать лишь внутреннее состояние объекта? и не должен описывать поведение набора объектов?
Не понял про описание поведения набора объектов в классе. С точки зрения классического ООП, класс описывает поведение своих объектов.

DG>есть даже набор паттернов, которые описывают именно поведение набора объектов
Я про них написал ниже — не забегайте вперёд.

DG>но это лишь main-stream языки утверждают, что класс у объекта должен быть статичным
Ок, покажите мне немейнстрим-ООП, в котором работает смена класса объекта на лету.

DG>как это без ООП, если issue, transition, attrubute и requirement — это есть всамделишные объекты?
Какие же они всамделишные? Их не было в той модели, которая задокументирована на входе. Это в чистом виде артефакт изготовления. Уже из них строится реальная программа для решения конечной задачи, а не из классов, методов и прочих свойств и интерфейсов.

DG>>конечно, можно. как минимум можно в виде набора классов
S> И чему в "реальной модели" будут соответствовать эти классы из "набора"?
S>В реальности объектная модель, якобы построенная на основе той модели, которая описывает предмет автоматизации, стремительно разъезжается.

той или иной грани проекта.
только чисто из языка у проекта есть 4 смысла
1) (план) design [], (technical) plan
2) (рд.; черновой вариант) draft (attr)
3) (замысел) scheme, plan, project
4) (предприятие, инициатива) project



DG>>и кто сказал, что класс должен описывать лишь внутреннее состояние объекта? и не должен описывать поведение набора объектов?
S>Не понял про описание поведения набора объектов в классе. С точки зрения классического ООП, класс описывает поведение своих объектов.

спорно.
например, operator + , в общем случае, описывает поведение не только своего объекта, но при этом operator + является частью класса и частью ООП.

DG>>но это лишь main-stream языки утверждают, что класс у объекта должен быть статичным
S>Ок, покажите мне немейнстрим-ООП, в котором работает смена класса объекта на лету.

Objects in Python can change their class by setting the __class__ attribute

DG>>как это без ООП, если issue, transition, attrubute и requirement — это есть всамделишные объекты?
S>Какие же они всамделишные? Их не было в той модели, которая задокументирована на входе. Это в чистом виде артефакт изготовления. Уже из них строится реальная программа для решения конечной задачи, а не из классов, методов и прочих свойств и интерфейсов.

и чему это противоречит?
цемента, арматуры, а тем более лесов и крана тоже нет при постановке задачи построить дом, но при строительстве всё это появляется

при переходе от постановки к реализации прошел этап детализации, и появились более атомарные сущности (объекты).
что в этом такого странного? и в чем противоречие с ООП?

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

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

DG>чтобы не быть голословными лучше опираться на какую-нибудь задачу.
DG>давай постановку задачи про проекты, которая по твоему плохо описывается при помощи ООП.
Посмотрите на MS Project. Прикиньте, с какими сущностями имеет дело пользователь. Ну там — ресурсы, задачи, расписания. Задача там, в сущности, ровно одна — выполнить leveling.

Здравствуйте, DarkGray, Вы писали:
DG>той или иной грани проекта.
DG>только чисто из языка у проекта есть 4 смысла
DG>1) (план) design [], (technical) plan
DG>2) (рд.; черновой вариант) draft (attr)
DG>3) (замысел) scheme, plan, project
DG>4) (предприятие, инициатива) project
Никакой грани того проекта, в терминах которго мыслит пользователь эти объекты соответствовать не будут.
Упрощённый пример на ту же тему — детям всегда рассказывают про прямоугольники и квадраты при иллюстрации ООП. А в жизни там ровно один тип данных — Polyline, никакого красивого наследования и полиморфизма.

DG>спорно.
DG>например, operator + , в общем случае, описывает поведение не только своего объекта, но при этом operator + является частью класса и частью ООП.
Догадываюсь, что вы имеете в виду, но всё же покажите код этого оператора, чтобы показать, как он влияет на поведение чужих объектов. Желательно ещё чтобы это всё-таки были объекты, а не экземпляры АТД с value-семантикой.

DG>Objects in Python can change their class by setting the __class__ attribute
Спасибо, не знал. Буду иметь в виду.

DG>и чему это противоречит?
Это противоречит утверждению о том, что в ООП классы используются для воспроизведения каких-то компонентов исходной модели.

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

DG>при переходе от постановки к реализации прошел этап детализации, и появились более атомарные сущности (объекты).
Они не более атомарные. Они просто другие. Вообще другие.

DG>что в этом такого странного? и в чем противоречие с ООП?
Противоречие не с ООП. Противоречие — с идиотским предположением о том, что ООП предлагает лепить классы с сущностей модели. Если у вас встанет задача смоделировать управление стройкой, то в вашем коде не будет никаких TКран, ТБульдозер, ТКаменщик или ТЦементМарки400.
Ничего из того, во что можно ткнуть пальцем на стройке, не проникнет в реальную модель вашей программы. Зато будет дохрена всяких штук типа TEditingSession, TChange, TMainWindow и прочего, что моделирует устройство исключительно самой программы. Никто в здравом уме не будет наследовать TПрораба от ТБригадира. Будет (в лучшем случае!) класс TEmployee. А то и его не будет — прекрасно обойдёмся тупо DataSet/DataRow, потому что никакого полиморфизма поведения у работников на стройке не предусмотрено.

DG>>чтобы не быть голословными лучше опираться на какую-нибудь задачу.
DG>>давай постановку задачи про проекты, которая по твоему плохо описывается при помощи ООП.
S>Посмотрите на MS Project. Прикиньте, с какими сущностями имеет дело пользователь. Ну там — ресурсы, задачи, расписания. Задача там, в сущности, ровно одна — выполнить leveling.

не знаю, что такое leveling.
но знаю, что ms project можно считать редактором проекта, в смысле, плана

т.е. ты предлагаешь поговорить о задаче редактировании проекта?

S>Никакой грани того проекта, в терминах которго мыслит пользователь эти объекты соответствовать не будут.

голословное утверждение

S>Упрощённый пример на ту же тему — детям всегда рассказывают про прямоугольники и квадраты при иллюстрации ООП. А в жизни там ровно один тип данных — Polyline, никакого красивого наследования и полиморфизма.

не будет, если прямоугольники и квадраты не предлагает специфичного поведения, по сравнению с polyline
и будет — если предлагает.

при этом ты говоришь, о каких-то своих заморочках, если брать реальные реализации, то там есть и прямоугольники, и polyline-ы.

в wpf — есть и то, и другое,
в svg — тоже есть

DG>>спорно.
DG>>например, operator + , в общем случае, описывает поведение не только своего объекта, но при этом operator + является частью класса и частью ООП.
S>Догадываюсь, что вы имеете в виду, но всё же покажите код этого оператора, чтобы показать, как он влияет на поведение чужих объектов. Желательно ещё чтобы это всё-таки были объекты, а не экземпляры АТД с value-семантикой.

допустим мы описываем тип int с насыщением
тогда такой тип удобнее описать как

class BoundedInt<Range>
{
  public BoundedInt(int value)
  {
    if (value < Range.MinValue)
       value = Range.MinValue;
    else if (value > Range.MaxValue)
       value = Range.MaxValue;
    this.value = value;
  }
  public int value; 

  static BoundedInt<Range> operator + (BoundedInt<Range> v1, BoundedInt<Range> v2)
  {
     return new BoundedInt<Range>(v1.value + v2.value);
  }
}

DG>>что в этом такого странного? и в чем противоречие с ООП?
S>Противоречие не с ООП. Противоречие — с идиотским предположением о том, что ООП предлагает лепить классы с сущностей модели. Если у вас встанет задача смоделировать управление стройкой, то в вашем коде не будет никаких TКран, ТБульдозер, ТКаменщик или ТЦементМарки400.

не будет, если будет абстрактное моделирование стройки — например, на уровне проектных граней, например, распределения ресурсов или там начисление зарплаты
но если будет моделирование именно стройки, например, игра-стройка, то все эти объекты появятся.

S>Ничего из того, во что можно ткнуть пальцем на стройке, не проникнет в реальную модель вашей программы. Зато будет дохрена всяких штук типа TEditingSession, TChange, TMainWindow и прочего, что моделирует устройство исключительно самой программы. Никто в здравом уме не будет наследовать TПрораба от ТБригадира. Будет (в лучшем случае!) класс TEmployee. А то и его не будет — прекрасно обойдёмся тупо DataSet/DataRow, потому что никакого полиморфизма поведения у работников на стройке не предусмотрено.

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

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

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

Здравствуйте, DarkGray, Вы писали:
S>>Посмотрите на MS Project. Прикиньте, с какими сущностями имеет дело пользователь. Ну там — ресурсы, задачи, расписания. Задача там, в сущности, ровно одна — выполнить leveling.

DG>не знаю, что такое leveling.
Назначение задач ресурсам и срокам так, чтобы удовлетворить зависимости и ограничения.
DG>но знаю, что ms project можно считать редактором проекта, в смысле, плана

DG>т.е. ты предлагаешь поговорить о задаче редактировании проекта?
Да, например.

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

DG>в wpf — есть и то, и другое,
DG>в svg — тоже есть
И где там ООП? Неужели прямоугольник в WPF является наследником квадрата? Или наоборот?


DG>допустим мы описываем тип int с насыщением
DG>тогда такой тип удобнее описать как
DG>

DG>class BoundedInt<Range>
DG>{
DG>  public BoundedInt(int value)
DG>  {
DG>    if (value < Range.MinValue)
DG>       value = Range.MinValue;
DG>    else if (value > Range.MaxValue)
DG>       value = Range.MaxValue;
DG>    this.value = value;
DG>  }
DG>  public int value; 

DG>  static BoundedInt<Range> operator + (BoundedInt<Range> v1, BoundedInt<Range> v2)
DG>  {
DG>     return new BoundedInt<Range>(v1.value + v2.value);
DG>  }
DG>}
DG>

Нет, ну так не интересно. Это же не ООП — где тут сообщение, которое мы посылаем объекту? В ООП оператор + является методом, который применяется к левому аргументу. Так что это левый аргумент "решает", что именно вернуть, и это его поведение.
А статик метод поведение никакого объекта не описывает.


DG>>>что в этом такого странного? и в чем противоречие с ООП?
S>>Противоречие не с ООП. Противоречие — с идиотским предположением о том, что ООП предлагает лепить классы с сущностей модели. Если у вас встанет задача смоделировать управление стройкой, то в вашем коде не будет никаких TКран, ТБульдозер, ТКаменщик или ТЦементМарки400.

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

S>>Ничего из того, во что можно ткнуть пальцем на стройке, не проникнет в реальную модель вашей программы. Зато будет дохрена всяких штук типа TEditingSession, TChange, TMainWindow и прочего, что моделирует устройство исключительно самой программы. Никто в здравом уме не будет наследовать TПрораба от ТБригадира. Будет (в лучшем случае!) класс TEmployee. А то и его не будет — прекрасно обойдёмся тупо DataSet/DataRow, потому что никакого полиморфизма поведения у работников на стройке не предусмотрено.

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

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

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

Здравствуйте, DarkGray, Вы писали:
DG>>>что в этом такого странного? и в чем противоречие с ООП?
S>>Противоречие не с ООП. Противоречие — с идиотским предположением о том, что ООП предлагает лепить классы с сущностей модели. Если у вас встанет задача смоделировать управление стройкой, то в вашем коде не будет никаких TКран, ТБульдозер, ТКаменщик или ТЦементМарки400.

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

DG>но если речь идет о моделировании взаимодействия между прорабом и бригадиром, то прорабы и бригадиры появятся.
И кто из них от кого будет отнаследован? Не смешите меня — будет в лучшем случае один класс на всех, при этом в нём не будет никакого поведения.

DG>разные классы появляются, когда необходимо описать разное поведение.
DG>если мы при моделировании отойдем слишком далеко, что нам уже будет пофигу — это стройка, магазин или дет.сад — то да, никаких объектов прораб, кирпич и арматура не будет.
Да, будет 1с.
DG>если мы при моделировании подойдем слишком близко, и будет моделировать мир на уровне атомов — то да, тоже никаких объектов прораб, кирпич или арматура не будет.
DG>да, все эти объекты появятся лишь только если мы будем моделировать именно саму стройку, а не что-то еще.
Вы вообще реальные программы когда-нибудь писали? К чему эти абстрактные рассуждения про атомы и арматуру? Программа является моделью решаемой задачи не в большей степени, чем токарный станок является моделью вытачиваемого изделия.
ООП обманывает людей, обещая им решить задачу через построение модели. Да нихрена!
Если вы пишете программу для расчёта падения камня на луну, у вас не будет модели камня, модели луны, и модели вакуума. У вас будет квадратное уравнение и код, который его решает.

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

Это не делает ООП плохим. ООП прекрасно подходит; только нужно помнить, что объекты будут моделировать решение, а не задачу. DataSet/DataRow — это элементы решения; никто не спорит, что они прекрасно описываются в терминах ООП.
Большинство книжек про ООП вводят людей в заблуждение. "О, у нас есть теплица, датчики и нагреватели. Давайте заведём ТТеплица, ТДатчик, ТНагреватель и посмотрим, не удастся ли нам нарисовать какую-нибудь забавную иерархию наследования". Это — бред. Гораздо более конструктивный способ — это сосредоточиться на решении: что именно мы хотим сделать. Из каких частей должен состоять автомат, управляющий теплицей? И вот эти части уже можно моделировать в ООП.
Понимаете? Выключатель не должен содержать в себе модель лампочки, которой он управляет. Он должен содержать разумно устроенную модель выключателя.

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


I>>А где ты в них мутабельности углядел ?
S>Хочется спросить навстречу, где ты в них мутабельности не углядел?
S>итератор сохраняет позицию, в наблюдателе subject сохраняет список наблюдателей.
Это потому, что имеющаяся реализация yield return реализует стандартный IEnumerable<T>. Её можно было бы "починить", если бы результат GetEnumerator реализовывал бы ICloneable<IEnumerator<T>>.
А окончательно её можно было бы починить, если бы в IEnumerator<T> MoveNext возвращал не void, а IEnumerator<T>.
Тогда бы за хранение состояния отвечал бы клиентский код, вместо $iterator.MoveNext было бы $iterator=$iterator.MoveNext.

S>Тогда попрошу продемонстрировать, как объект меняет свое поведение без изменения состояния
Классика жанра — результатом вызова модифицирующих методов является новый объект.
См. напр. System.String.

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

S>Я тебе поясню так: если ты считаешь IEnumerator иммутабельным, то для тебя и State и Iterator и Observer будут иммутабельными, как и многое другое. Разубеждать тебя не собираюсь.
Ну, вот в нашем любимом дотнете обзёрвер таки реализован на иммутабельных делегатах.

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

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


I>>>А где ты в них мутабельности углядел ?
S>>Хочется спросить навстречу, где ты в них мутабельности не углядел?
S>>итератор сохраняет позицию, в наблюдателе subject сохраняет список наблюдателей.
S>Это потому, что имеющаяся реализация yield return реализует стандартный IEnumerable<T>. Её можно было бы "починить", если бы результат GetEnumerator реализовывал бы ICloneable<IEnumerator<T>>.
S>А окончательно её можно было бы починить, если бы в IEnumerator<T> MoveNext возвращал не void, а IEnumerator<T>.
S>Тогда бы за хранение состояния отвечал бы клиентский код, вместо $iterator.MoveNext было бы $iterator=$iterator.MoveNext.
Задача перебора будет решена, но это уже не паттерн Iterator

S>>Тогда попрошу продемонстрировать, как объект меняет свое поведение без изменения состояния
S>Классика жанра — результатом вызова модифицирующих методов является новый объект.
S>См. напр. System.String.
Но при этом исходный объект свое наблюдаемое состояние не меняет. Классика жанра основана именно на этом.

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

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

S>>Я тебе поясню так: если ты считаешь IEnumerator иммутабельным, то для тебя и State и Iterator и Observer будут иммутабельными, как и многое другое. Разубеждать тебя не собираюсь.
S>Ну, вот в нашем любимом дотнете обзёрвер таки реализован на иммутабельных делегатах.
Да, но при этом наблюдаемый объект не может быть иммутабельным.
Я не утверждаю что задачу паттерна наблюдатель нельзя решить в иммутабельном стиле. Я утверждаю что это будет не ООП паттерн наблюдатель.