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

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

S>>Имхо, да. Вы поймите — не всё, что можно запрограммировать на ОО-языке является реализацией корректной объектной модели. На C# можно, к примеру, сделать чисто статический класс. С точки зрения ООП его не может быть.

V>Может. Это аналог объекта-синглтона. Разве что чуть упростили интерфейс к нему.
Ну да. Но это такой довольно отдалённый аналог . Впрочем, можно же усложнять базовую модель ООП. Это в самом минимуме объекты, идентичность, поведение. Потом начинается — классы, интерфейсы, полиморфизм, прототипы, метаклассы, и всё остальное во всё более интересных сочетаниях.

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

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

S>>value-семантика гарантирует копирование при присваивании и передаче в качестве аргумента. То что она имеет одинаковое поведение со ссылками на иммутабельные объекты, не делает их неразличаемыми.
S>Нет. Объекты класса String в .Net имеют value-семантику.
Откуда это следует?
Вот здесь ничего нет о String.
S>Очевидно, никаких гарантий копирования эта семантика не даёт. Value-семантика гарантирует взаимозаменяемость объектов с одинаковым состоянием, ни больше и ни меньше.
Можно где-то об этом почитать?
S>Вы путаете математическую семантику "значение" с реализацией value-типов в конкретной платформе.
На нескольких разных платформах подразумевается одно и то же. И по ссылке выше — тоже. Где можно почитать о вашем толковании value-семантики?

S>>>Это не совсем изменяемое состояние. Объект своё состояние никак не меняет, это, фактически, SSA-форма (single static assignment).
S>>Никакого отношения к SSA, имхо. Типичный Lazy<T>.
S>Lazy<T>, по приведённой классификации, меняет своё состояние дважды. Сначала — при инициализации, второй раз — при первом обращении.
Есть примеры объектов, которые не меняют свое состояние при инициализации?

S>Вообще, в программировании сейчас наблюдается значительный разрыв между теорией и практикой. Я не знаю, почему он происходит, но выглядит всё просто ужасно. Детям сначала рассказывают про высокое, а потом они приходят работать, а там ужосчто. И про этот ужосчто никаких вменяемых книг уже нету, приходится дотумкивать своим умом. Не всегда успешно. ...
S>И вот с ООП — то же самое.
Ну вот мне кажется, что необходимость в физическом смысле идентичности для объекта дотумкана. У Буча идентичность — это свойство объекта, а не необходимое условие для его существования. А Кей вообще ничего не говорил об идентичности, упоминая лишь поведение и состояние.

Здравствуйте, samius, Вы писали:
S>>Нет. Объекты класса String в .Net имеют value-семантику.
S>Откуда это следует?
Из поведения строк. Я приводил примеры. Вот чуть менее платформенно-зависимое описание того, что такое value semantic http://c2.com/cgi/wiki?ValueSemantics
S>Можно где-то об этом почитать?
S>На нескольких разных платформах подразумевается одно и то же. И по ссылке выше — тоже. Где можно почитать о вашем толковании value-семантики?
По ссылке выше.
Очередное упражнение на логику: все struct-типы имеют value-семантику (см. вашу ссылку про C#). Но не все типы с value-семантикой обязаны быть struct-типами.

S>Есть примеры объектов, которые не меняют свое состояние при инициализации?
А, похоже, я неправильно понял ту часть статьи. Да, в таком случае это Lazy<T>.

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

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

S>>>Нет. Объекты класса String в .Net имеют value-семантику.
S>>Откуда это следует?
S>Из поведения строк. Я приводил примеры. Вот чуть менее платформенно-зависимое описание того, что такое value semantic http://c2.com/cgi/wiki?ValueSemantics

An object has ValueSemantics when it can be treated as a single value.

Сомнительное описание. Неясно, что мешает рассматривать как single value все что угодно.

In C++ this means implementing a copy constructor and an assignment operator in such a way that when a new or existing instance is set equal to some other instance the new instance will be equivalent to the old one without acting as an alias to it.

Последняя оговорка C++ трактовки как раз исключает System.String из этой формулировки.

S>>На нескольких разных платформах подразумевается одно и то же. И по ссылке выше — тоже. Где можно почитать о вашем толковании value-семантики?
S>По ссылке выше.
S>Очередное упражнение на логику: все struct-типы имеют value-семантику (см. вашу ссылку про C#). Но не все типы с value-семантикой обязаны быть struct-типами.
Приведенная выше формулировка исключает value-сематнику строки .NET как и остальные, которые я встречал. Можно привести ссылку на определение, которое бы соответствовало вашим выводам?

S>>Ну вот мне кажется, что необходимость в физическом смысле идентичности для объекта дотумкана. У Буча идентичность — это свойство объекта, а не необходимое условие для его существования.
S>Свойство любого объекта.
Угу, и наверное так же объекта, чье состояние не меняется. Никаких оговорок у Буча нет по этому поводу.
S>>А Кей вообще ничего не говорил об идентичности, упоминая лишь поведение и состояние.
S>Без идентичности невозможно реализовать посылку сообщения.
Из этого утверждения напрашивается вывод о том что иммутабельные объекты обладают идентичностью (иначе невозможно реализовать посылку сообщения, а сообщения им посылать можно), и предположение о физическом смысле идентичности для таких объектов (для возможности посылки сообщения).

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

S>Сомнительное описание. Неясно, что мешает рассматривать как single value все что угодно.
Мешает, например, наличие раздельного поведения у различных экземпляров. Все строки "Hello" в дотнете эквивалентны, точно так же, как и все целые числа 5.

S>

S>In C++ this means implementing a copy constructor and an assignment operator in such a way that when a new or existing instance is set equal to some other instance the new instance will be equivalent to the old one without acting as an alias to it.

S>Последняя оговорка C++ трактовки как раз исключает System.String из этой формулировки.
Нет. Вы неправильно понимаете термин alias.
Следите за руками:

int a = 5;
int & b = a;
b += 1;
cout << a;

Вот что такое alias.
Попробуем сделать то же самое с интом-значением:

int a = 5;
int b = a;
b += 1;
cout << a; // вот чем отличается alias от copy

Теперь попробуем со строкой:

string a = "5";
string b = a;
b += "1";
Console.WriteLine(a);

Видите? Несмотря на отсутствие копирования при присваивании, b всё равно не ведёт себя как alias для a.

S>Приведенная выше формулировка исключает value-сематнику строки .NET как и остальные, которые я встречал. Можно привести ссылку на определение, которое бы соответствовало вашим выводам?
Как я показал выше, вы ошибаетесь.

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

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

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

S>>Сомнительное описание. Неясно, что мешает рассматривать как single value все что угодно.
S>Мешает, например, наличие раздельного поведения у различных экземпляров. Все строки "Hello" в дотнете эквивалентны, точно так же, как и все целые числа 5.
Но позвольте, во-первых в том определении ничего нет про эквивалентность и раздельное поведение. std::vector<int> обладает value-семантикой по тому определению (включая уточнение о том что это значит в C++). Т.е. некто рассматривает std::vector<int> как одиночное значение. Что мешает рассматривать как одиночное значение List<int>? Именно уточнение, которого говорит что при присваивании должна создаваться копия, а не алиас.

S>>

S>>In C++ this means implementing a copy constructor and an assignment operator in such a way that when a new or existing instance is set equal to some other instance the new instance will be equivalent to the old one without acting as an alias to it.

S>>Последняя оговорка C++ трактовки как раз исключает System.String из этой формулировки.
S>Нет. Вы неправильно понимаете термин alias.
S>Следите за руками:
S>

S>int & b = a;
S>

S>Вот что такое alias.
+1
S>Попробуем сделать то же самое с интом-значением:
S>

S>int b = a;
S>cout << a; // вот чем отличается alias от copy
S>

+1
S>Теперь попробуем со строкой:
S>

S>string a = "5";
S>string b = a;
S>b += "1";
S>Console.WriteLine(a);
S>

S>Видите? Несмотря на отсутствие копирования при присваивании, b всё равно не ведёт себя как alias для a.
В этом примере вы смещаете акценты... Строкой вы здесь считаете не сам экземпляр System.String, а ссылку на него.

Я соглашусь со следующей формулировкой: Строка в дотнете формально соответствует reference-семантике, хотя и обладает чертами поведения value. Т.е. alias в смысле еще одного "имени" того же экземпляра таки создается, но изменить состояние экземпляра через этот alias не удастся, потому его "можно считать" копией.
Да, в таком аспекте я готов обобщить утвреждение до иммутабельных объектов.

S>>Приведенная выше формулировка исключает value-сематнику строки .NET как и остальные, которые я встречал. Можно привести ссылку на определение, которое бы соответствовало вашим выводам?
S>Как я показал выше, вы ошибаетесь.
Не готов с этим согласиться. Она обладает чертами value-типа в том плане что ее нельзя изменить через alias. Но формально все-же reference.

Осталось разобратся, почему value не являются объектами.

S>Или может строка это не объект? Тогда что отличает объект от необъекта? Ниужели наличие изменяемого состояния?
Конечно же не объект. Строка имеет семантику value-типа.

S>>Из этого утверждения напрашивается вывод о том что иммутабельные объекты обладают идентичностью (иначе невозможно реализовать посылку сообщения, а сообщения им посылать можно), и предположение о физическом смысле идентичности для таких объектов (для возможности посылки сообщения).
S>Главное для меня здесь — наличие смысла в посылке сообщения какому-то конкретному объекту. Вы меня почти убедили, что для эквивалентных иммутабельных объектов всё ещё может иметь смысл посылать сообщения кому-то конкретному.
Даже если смысла нет, но раз мы можем послать сообщение конкретному, значит идентичность есть. И вот еще над чем интересно подумать: можем ли мы послать сообщение не какому-то конкретному объекту? Пусть даже сообщение посылается с предикатом, через границы домена, или еще как... Но получить-то его может только конкертный объект, если не говорить об экзотике вроде ((Foo*)rnd())->Bar();

Какие есть другие причины что бы не считать value объектами?

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

V>>Да есть. На токарном станке не выточишь кубик. Про фигуру вращения уже напомнил.
S>Не стоит все ограничения принимать за модель.

У тебя то один элемент модели должен быть моделью другого элемента, то уже сами ограничения.
Ограничения, именно что диктуют выбор модели. Т.е. не являются моделью, но влияют на нее.

V>>Можно предположить, что модели нету, если шаблон не установлен, и токарь работает "ручками". В этом случае у него модель есть в спеке изделия, подробности которой он ручками переносит на соотв. положение резака.
S>Совершенно верно. В спеке (т.е. в чертеже) модель есть. В инструменте — нету.

Инструмент i]соответствует[/i] модели. Или надо брать другой инструмент.

V>>Ты изначально выразился насчет шаблона. Или же перефразируй исходную фразу, а то разговор переходит в русло слепого с глухим.
S>Я изначально выразился насчёт токарного станка.

Вот здесь сумбурно:

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

V>>Да, ООП есть способ упрощения создания таких моделей, где подразумевается поведение, зависимое от состояния. Например, складская программа моделирует поведение кладовщика, где текущие остатки склада — его инкапсулированное состояние.

S>Что характерно, для складских программ чистое ООП почему-то плохо применимо. Туда идеально подходит реляционная алгебра — поскольку инкапсулированное состояние мало кого интересует. Интересует как раз наоборот — возможность получать различные проекции одного и того же состояния.

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

S>Предлагаю поверить мне на слово — я занимался моделированием склада при помощи ООП на профессиональной основе. Ну там, объект Склад, объект Партия, объект ЕдиницаИзмерения.
S>Результат вкратце: ООП сосёт. Преимуществ никаких, недостатков и ограничений — масса.

Я тоже занимался много лет — у меня ничего не сосало. Да, некие ограничения есть из-за того, что мы храним данные в SQL серверах, и в этом месте вынуждены прописывать большую часть операций из-за соображений эффективности и целостности, обеспечиваемой самими серверами. И должны бороться с ограничениями инструмента. Но никто же не запрещает вызовы этих операций из прикладного кода инкапсулировать в методах объектов. Оперировать складами как объектами, а не напрямую их ID в программе довольно удобно. Понятное дело, что стоит подумать, какую сущность удобнее представлять "объектами", а какую "данными". Хотя критерий относительно прост: если данных мало, а связанных с ними операций много — то удобнее оформлять данные в виде объектов. Например, склады, контрагенты, торговые точки, валюты. Напротив, товар и движения удобно представлять в виде данных. Отчеты и срезы опять же удобнее делать из другого инструмента — из OLAP. Т.е. прописать отображение данных и вертеть затем твою реляционную алгебру. Т.е. это уже другая задача и под нее нужен другой инструмент. Хотя опять же, удобно представлять прикладные запросы как объекты, хранящие/валидирующие свои параметры и абстрагирующие нас от подробностей совершения самих запросов. В общем, отсосать может конкретный дизайн, но никак не парадигма.


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

По крайней мере, самая популярная складская программа с тобой не согласна. Объекты могут быть на всех уровнях.

V>>Логично, именно поэтому есть несколько парадигм программирования.
S>Ну, в общем смысле да. Но я подчеркну — то, что от складской программы требуется давать остатки по партиям/видам товара/складам/поставщикам не означает неприменимости для неё ООП. В конце концов, 99% современных складских программ написаны таки на ОО-языках, и кода за пределами классов там совсем мало. Просто ООП в них применяется не для моделирования задачи или какого-то там "реального мира", а для моделирования решения этой задачи.

Гм. Опять бардак в рассуждениях. Что есть модель? Это прототип оригинала с некоторой степенью подробности. Твое "решение" — это и есть некая выбранная модель происходящего. Ведь реальные остатки со склада не уходят сами по себе, когда ты вносишь очередную накладную. Ты лишь моделируешь выдачу товара в своём решении. И корректность отчетов будет зависеть от того, насколько точно вы программе промоделировали происходящене на самом деле.

Понятное дело, что модели могут различаться, и как степенью подробностей, так и взглядом на происходящее. Например, есть два популярных способа ведения складского учета — на основе складских карточек (учет по партиям), и на основе обобщенных остатков, объединенных через общий справочник товаров (по средневзвешенной цене). Это разные модели, т.е. разные "решения". Получаем даже разные мгновенные результаты профита по каждой сделке. Но по моменту продажи всего товара со склада результат будет одинаковый, поэтому обе модели признаны корректными. Это я к тому, что разнообразие решений/моделей — это более чем нормально. А на низком уровне, когда доходит до реализации нефункциональных требований, т.е. до борьбы с конкретными библиотеками, платформами, разрядностью, языками — то этих "решений по месту" может быть вообще бесчисленное кол-во. Попроси двух спецов написать программу по одним и тем же требованиям даже на одной и той же платформе — и в этих программах не будет практически ничего общего, хотя делать они будут одно и то же.


V>>Тонкость твоего примера в том, что для отлития фигур вращения таки используют токарный станок... для создания прототипа. А последующее литье — это суть копирование прототипа.
S>Прототип может быть получен чем угодно. В том числе и трёхмерным принтером. Тонкость моего примера в том, что сначала выбирают некоторый путь решения. А потом вот это вот абстрактное решение воплощают в некоторой конкретной парадигме. К примеру, я могу реализовать умножение матриц в виде семейства stateless функций, которые оперируют над immutable данными. А могу — в виде набора stateful объектов, которые обмениваются сообщениями. Уместность того или иного подхода зависит исключительно от того, каким должно получиться полное решение. А вовсе не от задачи.

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

S>Это не я решил — это решили те, кто убеждает в том, что основная роль ООП — в моделировании задачи.

Не перевирай. Было сказано, что ООП хорошо подходит для создания моделей, участники которых имеют поведение, зависимое от состояния.

S>Программа точно так же — всего лишь один из участников в общей модели чего-то там. Например, отслеживания отгрузок по складу. Физический склад — другой участник этой модели. И совершенно непонятно, почему один участник должен содержать в себе модель другого.

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

S>Торговля идёт относительно того, насколько часто приходится моделировать в программистской деятельности. О применимости ООП для этого торговля идёт уже во вторую очередь.

Да всегда приходится. Я еще не видел примера, относительно ПО, чтобы оно не являлось моделью чего-либо.

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

Нет, "само по себе" ничего не расположено. В ООП мы напрямую ручками размечаем поля, где будем хранить данные в памяти объекта. Даже если речь о полях ссылочного типа, то значит ссылки и храним, ссылки — тоже данные. Абстракция тут — это лишь публичный интерфейс объекта и нигде больше. Сами же объекты не из воздуха берутся, их кто-то программирует, именно в терминах ячеек памяти и операций над ними.

Хотя, некоторые языки умеют делать автосвойства, но это фактически одно и то же, и нужно лишь для обхода ограничений, наложенных платформой, например для работы биндинга и всего остального, завязанного на PropertyDescriptor/PropertyInfo.


S>Вполне возможно, что ФП-компилятор решит повторно использовать те же ячейки памяти, поскольку иммутабельность — это свойство исходной программы, а не ячейки памяти.

Теоретически сия возможность есть, фактически ФП компиляторы на сегодня не умеют оптимизировать толком. В дотнете, например, основной тормоз для числобробилок — это время доступа к элементам массивов. И, хотя теоретически лишние проверки доступа можно исключить в очень большом кол-ве сценариев, фактически реализован всего один сценарий. Поэтому дотнет до сих пор сосет и причмокивает, хотя уже 9 лет как.


S>В принципе, я могу поверить, хотя и с оговорками, в то, что для моделирования моста удобно будет применять ООП-шные объекты, которые соответствуют его деталям.
S>А вот для моделирования работы датчика скорости потока на эффекте Холла вы какие объекты собираетесь описывать? Вода, МагнитноеПоле, Датчик?

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

V>>Выключатель — это часть цепи. Осуществляет замыкание/размыкание в этой модели и имеет вполне определенные состояния. Заметь, лампочка и источник напряжения не имеют состояния, они являются чистыми ф-иями (если не учитывать нагрев спирали), но выключатель — имеет. Соотв, для модели такой цепи нужен один регистр памяти и пара ф-ий.
S>Нам не нужна модель цепи. Выключатель прекрасно работает безо всякой модели. Это была аналогия.

Это была натяжка. Я вообще плохо понимаю попытки выдать одни элементы модели за другие. Модель цепи нам нужна хотя бы на бумаге или в голове, чтобы проверить, подходит ли данный выключатель, лампочка и т.д. в эту цепь. ИМХО, электроника — это самая идеальная область для моделирования, и она фактически вся на кончике карандаша была выведена. По состоянию на сегодня, любые более-менее сложные электронные компоненты разрабатываются исключительно через программное моделирование. Т.е. опытные образцы делают только тогда, когда программная модель является уже довольно-таки "вылизанной".


S>Вот у нас стоит задача управления освещением в комнате. С этим справляется выключатель. В нём, очевидно, модели лампочки нет. Можете на досуге разобрать выключатель и поискать там модель лампочки.

Да, модели лампочки в выключателе нет... говоришь, нет бардака?
В проводах ее тоже нет, что характерно. И в розетке.

S>Далее, переходим к более сложной задаче — управление яркостью света. Появляется диммер. Он устроен сложнее, чем выключатель, но модели лампочки в нём по-прежнему нет.
S>Теперь сделаем управление яркостью света с обратной связью — чтобы ночью свет автоматически включался, а днём выключался. В цепи появятся фотоэлементы, и прочая электроника. Способов решить эту задачу существенно больше, но и в них никакой модели лампочки и окружающей среды по прежнему нет. Есть модель некоего устройства "управляющий элемент".

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

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

Модель была нужна с самого начала. Это — схема цепи. Эту же модель можно перенести в цифровую область без проблем. Одноконтурной электронной цепи с пассивными элементами будет соответствовать линейное тело программы. Само это тело можно будет запускать с некоей периодичностью. Чем выше периодичность, тем меньше будет время срабатывания схемы, управляемой контроллером.

S>Но только объекта "лампочка" там, скорее всего, не будет. Вот программный аналог объекта "выключатель" там запросто может оказаться — тот самый регистр.

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

S>А тем временем укушенные ООП люди на полном серъёзе предлагают писать программу, в которой будут объекты Лампочка и Фотодатчик.

Скорее наоборот, не понимающие, что есть ООП. Нет состояния — нет ООП. Датчик, кстати, имеет объективное состояние, которое мы с некоей периодичностью опрашиваем.

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

V>>Я вообще предмета спора не понимаю. Если нам удобно обслуживаемую компьютером целевую автоматизацию чего-либо представить в виде модели, участники которой имеют состояние, то самое удобное на сегодня — это ООП.
S>Совершенно верно. Только эта модель будет, грубо говоря, моделью идеального устройства, решающего целевую задачу.

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

S>А не моделью объектов, из которых состоит предметная область.

А это уже зависит от выбранного решения и проведенных предварительно "сокращений общих частей ураневний". Бери для примера LL(k) парсер. Никто же, право, не делает k предпросмотров вперед в реальных парсерах, хотя именно так описывается модель его поведения. Вместо этого строится k-мерная таблица, и по каждому входному терминалу осуществляется непосредственный переход под этой таблице. Т.е. да, зачастую мы программируем не исходную модель, а её оптимизированный вариант. То же самое насчет лексических анализаторов. Там же когда минимизируешь состояния, а потом минимизируешь мн-во входов, то таблица переходов получается на 2 (!!!) порядка меньше обычно. И вроде бы с исходной грамматикой никакой связи, а работает эквивалентно. И вовсе не чудеса.

S>Именно поэтому в реальных программах полно объектов типа Window, Control, Connection, и прочих, которые никакого отношения к предметной области не имеют.

И что с того? Мы же должны как-то организовать ввод/вывод данных в нашу модель? Если модель не требует взаимодействия с человеком, то ей и Window не нужен.


S>Что очень сильно отличается от того, что преподают на курсах "ООП за 21 день".

Любые курсы на 21 день — разводняк. ООП тут не при чем.

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

S>Но позвольте, во-первых в том определении ничего нет про эквивалентность и раздельное поведение. std::vector<int> обладает value-семантикой по тому определению (включая уточнение о том что это значит в C++). Т.е. некто рассматривает std::vector<int> как одиночное значение. Что мешает рассматривать как одиночное значение List<int>? Именно уточнение, которого говорит что при присваивании должна создаваться копия, а не алиас.
Уточнение, что не должен создаваться алиас. Копия создаваться не обязана — до тех пор, пока я не пытаюсь выполнить модификацию, копия и алиас ведут себя одинаково.

S>В этом примере вы смещаете акценты... Строкой вы здесь считаете не сам экземпляр System.String, а ссылку на него.
С точки зрения пользователя нет никакого "экземпляра" string. Есть исключительно ссылки. Вот вы интом считаете само число или переменную?

S>Я соглашусь со следующей формулировкой: Строка в дотнете формально соответствует reference-семантике, хотя и обладает чертами поведения value. Т.е. alias в смысле еще одного "имени" того же экземпляра таки создается, но изменить состояние экземпляра через этот alias не удастся, потому его "можно считать" копией.
S>Да, в таком аспекте я готов обобщить утвреждение до иммутабельных объектов.

S>>Как я показал выше, вы ошибаетесь.
S>Не готов с этим согласиться. Она обладает чертами value-типа в том плане что ее нельзя изменить через alias. Но формально все-же reference.
Вы слишком много внимания уделяете низкоуровневой реализации. Чисто между нами: строки в дотнете всё-таки mutable.
Но зачем на этом фокусироваться? Весь дотнет построен на предположениях об иммутабельности строки, и использование строк в этом стиле максимально облегчено.
То, что вы можете сделать ReferenceEquals для строк и отличить какие две из трёх переменных, содержащих Hello, показывают на физически один и тот же набор байт — такая же малоинтересная подробность.
Малоинтересная она потому, что ей можно пренебречь. Всё, чего вы хотите сделать со строками, работает без ReferenceEquals и затачивания под identity. Вместо неё имеется эквивалентность состояния и ссылочная прозрачность. Именно благодаря ссылочной прозрачности не нужно физически копировать строку всякий раз, как мы встречаем оператор присванивания.
Поэтому то, что строка реализована при помощи reference-типа, не мешает ей наслаждаться value-семантикой.


S>Даже если смысла нет, но раз мы можем послать сообщение конкретному, значит идентичность есть. И вот еще над чем интересно подумать: можем ли мы послать сообщение не какому-то конкретному объекту? Пусть даже сообщение посылается с предикатом, через границы домена, или еще как... Но получить-то его может только конкертный объект, если не говорить об экзотике вроде ((Foo*)rnd())->Bar();
Ну, вот к примеру в реляционной алгебре нет "встроенной" возможности "отправить сообщение" конкретной строке.
Чтобы это сделать, приходится изобретать primary key.
Некоторым аналогом этой математики является linq — можно отправлять сообщения, не упоминая конкретные объекты.
S>Какие есть другие причины что бы не считать value объектами?
Других вроде бы нет.

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

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

S>>Но позвольте, во-первых в том определении ничего нет про эквивалентность и раздельное поведение. std::vector<int> обладает value-семантикой по тому определению (включая уточнение о том что это значит в C++). Т.е. некто рассматривает std::vector<int> как одиночное значение. Что мешает рассматривать как одиночное значение List<int>? Именно уточнение, которого говорит что при присваивании должна создаваться копия, а не алиас.
S>Уточнение, что не должен создаваться алиас. Копия создаваться не обязана — до тех пор, пока я не пытаюсь выполнить модификацию, копия и алиас ведут себя одинаково.
Пусть так. Т.е. это отличие делает std::vector<int> значением, а List<int> — объектом?

S>>В этом примере вы смещаете акценты... Строкой вы здесь считаете не сам экземпляр System.String, а ссылку на него.
S>С точки зрения пользователя нет никакого "экземпляра" string. Есть исключительно ссылки. Вот вы интом считаете само число или переменную?
Преимущественно сам тип, но в зависимости от контекста и переменную и значение. В случае со строкой — под строкой я подразумеваю сам экземпляр. Переменная для меня — ссылка.
Хорошо, посмотрим с такого ракурса на std::vector<int>. Как мы вроде бы определились ранее, это значение. Но когда у нас переменная типа указатель на вектор (vector<int>*), то для пользователя нет никакого "экземпляра", есть только указатель. А он ведет себя в соответствии с reference-семантикой. Значит ли это что vector<int> стал объектом, будучи значением?

S>>>Как я показал выше, вы ошибаетесь.
S>>Не готов с этим согласиться. Она обладает чертами value-типа в том плане что ее нельзя изменить через alias. Но формально все-же reference.
S>Вы слишком много внимания уделяете низкоуровневой реализации. Чисто между нами: строки в дотнете всё-таки mutable.
Это не суть важно.
S>...
S>Поэтому то, что строка реализована при помощи reference-типа, не мешает ей наслаждаться value-семантикой.
Хорошо, оставим это. Не суть важно, ведет себя как value, или обладает чертами.

S>>Даже если смысла нет, но раз мы можем послать сообщение конкретному, значит идентичность есть. И вот еще над чем интересно подумать: можем ли мы послать сообщение не какому-то конкретному объекту? Пусть даже сообщение посылается с предикатом, через границы домена, или еще как... Но получить-то его может только конкертный объект, если не говорить об экзотике вроде ((Foo*)rnd())->Bar();
S>Ну, вот к примеру в реляционной алгебре нет "встроенной" возможности "отправить сообщение" конкретной строке.
S>Чтобы это сделать, приходится изобретать primary key.
+1
S>Некоторым аналогом этой математики является linq — можно отправлять сообщения, не упоминая конкретные объекты.
Отправлять можем. Но получить сообщение может только конкретный объект при непосредственной посылке конкретно ему (пусть где-то в реализации linq-а).

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

S>Пусть так. Т.е. это отличие делает std::vector<int> значением, а List<int> — объектом?
Я, если честно, не помню деталей контракта std::vector<int>. Он иммутабелен? При его копировании создаётся полная копия?

S>Хорошо, посмотрим с такого ракурса на std::vector<int>. Как мы вроде бы определились ранее, это значение. Но когда у нас переменная типа указатель на вектор (vector<int>*), то для пользователя нет никакого "экземпляра", есть только указатель. А он ведет себя в соответствии с reference-семантикой. Значит ли это что vector<int> стал объектом, будучи значением?
Ну, если vector<int> сам по себе не имеет идентити, то получение указателя на него эквивалентно боксингу в дотнете — когда мы искусственно порождаем объект, хранящий внутри себя значение.

S>Хорошо, оставим это. Не суть важно, ведет себя как value, или обладает чертами.
Согласен.

S>Отправлять можем. Но получить сообщение может только конкретный объект при непосредственной посылке конкретно ему (пусть где-то в реализации linq-а).
Ну, это опять начинаются проблемы выбора степени детализации. Если мы копнём слишком глубоко, то увидим ту же память, регистры, и команды процессора.
Если копнуть в "середину" linq, то там везде сплошные вызовы — т.е. посылки сообщений. Как правило — объектам.

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

И можно заставить линк работать без объектов.
Есть, скажем, статический класс, на котором вызывается статический метод, в который передаётся ссылка на value-тип, который служит исключительно маркером, и передаётся предикат. Статический метод применяет предикат к совершенно необъектным данным, и получает некоторый результат, который по-прежнему не обязан быть объектом.

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

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

S>>Пусть так. Т.е. это отличие делает std::vector<int> значением, а List<int> — объектом?
S>Я, если честно, не помню деталей контракта std::vector<int>. Он иммутабелен? При его копировании создаётся полная копия?
нет, не иммутабелен. При копировании копируется вместе с содержимым.

S>>Хорошо, посмотрим с такого ракурса на std::vector<int>. Как мы вроде бы определились ранее, это значение. Но когда у нас переменная типа указатель на вектор (vector<int>*), то для пользователя нет никакого "экземпляра", есть только указатель. А он ведет себя в соответствии с reference-семантикой. Значит ли это что vector<int> стал объектом, будучи значением?
S>Ну, если vector<int> сам по себе не имеет идентити, то получение указателя на него эквивалентно боксингу в дотнете — когда мы искусственно порождаем объект, хранящий внутри себя значение.
Мы договорились что иммутабельные объекты не имеют практического смысла identity, про мутабельные речи не было.
Во всяком случае идентичность в следующем коде смысл имеет:

std::vector<int> a = std::vector<int>();
a.push_back(0);
std::vector<int> b = a;  // копирует вместе с содержимым.
cout << (a == b); // true
a.push_back(1);
cout << (a == b); // false

Нет, боксингу это не эквивалентно, т.к. значение в боксе изменить нельзя, а значение по указателю — можно:

std::vector<int> *p = &a;
p->push_back(2);

В случае с указателем он ведет себя адекватно List<int>.
Все это я к тому, что один и тот же тип vector<int> ведет себя в соответствии с определением value-семантики при оперировании значениями, и в соответствии с reference-семантикой при оперировании через ссылки, указатели. Т.е. по вашему он в одном случае значение, а в другом — объект?

S>>Хорошо, оставим это. Не суть важно, ведет себя как value, или обладает чертами.
S>Согласен.
Важно почему value не объект

S>>Отправлять можем. Но получить сообщение может только конкретный объект при непосредственной посылке конкретно ему (пусть где-то в реализации linq-а).
S>Ну, это опять начинаются проблемы выбора степени детализации. Если мы копнём слишком глубоко, то увидим ту же память, регистры, и команды процессора.
S>Если копнуть в "середину" linq, то там везде сплошные вызовы — т.е. посылки сообщений. Как правило — объектам.

S>А если опять же глянуть в "смысл" того, что происходит, то может оказаться, что никаких объектов нет.

S>И можно заставить линк работать без объектов.
S>Есть, скажем, статический класс, на котором вызывается статический метод, в который передаётся ссылка на value-тип, который служит исключительно маркером, и передаётся предикат. Статический метод применяет предикат к совершенно необъектным данным, и получает некоторый результат, который по-прежнему не обязан быть объектом.
Замнем тему про посылки, т.к. возможность посылки сообщения в широком смысле (маркерам) не является признаком объекта.

Здравствуйте, samius, Вы писали:
S>Мы договорились что иммутабельные объекты не имеют практического смысла identity, про мутабельные речи не было.
S>Во всяком случае идентичность в следующем коде смысл имеет:
S>

S>std::vector<int> a = std::vector<int>();
S>a.push_back(0);
S>std::vector<int> b = a;  // копирует вместе с содержимым.
S>cout << (a == b); // true
S>a.push_back(1);
S>cout << (a == b); // false
S>

Как раз здесь никакой идентичности нет. То, что копия выполняется в момент присваивания — это всего лишь неэффективная реализация. Строка в дотнете ведёт себя точно таким же образом, но "копия" создаётся только в момент попытки модификации.

S>Нет, боксингу это не эквивалентно, т.к. значение в боксе изменить нельзя, а значение по указателю — можно:
S>

S>std::vector<int> *p = &a;
p->>push_back(2);
S>

S>В случае с указателем он ведет себя адекватно List<int>.
Ага. Адекватно. Да, это всё-таки нифига не боксинг.
S>Все это я к тому, что один и тот же тип vector<int> ведет себя в соответствии с определением value-семантики при оперировании значениями, и в соответствии с reference-семантикой при оперировании через ссылки, указатели. Т.е. по вашему он в одном случае значение, а в другом — объект?
Вынужден признать что да, таки ведёт себя по-разному. Значит, я что-то не так понимаю в теории. Либо мы имеем дело с особенно злостным коварством системы типов С++.

S>>>Хорошо, оставим это. Не суть важно, ведет себя как value, или обладает чертами.
S>>Согласен.
S>Важно почему value не объект

S>>>Отправлять можем. Но получить сообщение может только конкретный объект при непосредственной посылке конкретно ему (пусть где-то в реализации linq-а).
S>>Ну, это опять начинаются проблемы выбора степени детализации. Если мы копнём слишком глубоко, то увидим ту же память, регистры, и команды процессора.
S>>Если копнуть в "середину" linq, то там везде сплошные вызовы — т.е. посылки сообщений. Как правило — объектам.

S>>А если опять же глянуть в "смысл" того, что происходит, то может оказаться, что никаких объектов нет.

S>>И можно заставить линк работать без объектов.
S>>Есть, скажем, статический класс, на котором вызывается статический метод, в который передаётся ссылка на value-тип, который служит исключительно маркером, и передаётся предикат. Статический метод применяет предикат к совершенно необъектным данным, и получает некоторый результат, который по-прежнему не обязан быть объектом.
S>Замнем тему про посылки, т.к. возможность посылки сообщения в широком смысле (маркерам) не является признаком объекта.

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

S>>

S>>a.push_back(1);
S>>cout << (a == b); // false
S>>

S>Как раз здесь никакой идентичности нет. То, что копия выполняется в момент присваивания — это всего лишь неэффективная реализация. Строка в дотнете ведёт себя точно таким же образом, но "копия" создаётся только в момент попытки модификации.
Согласно некоторым источникам, идентичность, основанная на состоянии, называется value identity, или internal identity (http://c2.com/cgi/wiki?ObjectIdentity, http://today.java.net/pub/a/today/2006/07/27/defining-object-identity.html).
Но я не совсем верно классифицировал vector как value-object. Для value-object-а недостаточно value-семантики, требуется еще и иммутабельность (согласно тем же источникам).

Наткнулся еще на любопытную книгу, полагаю что она будет интересна и vdimas-у тоже. Обсуждаемые вопросы в ней затронуты (и Identity и Value).

S>>Все это я к тому, что один и тот же тип vector<int> ведет себя в соответствии с определением value-семантики при оперировании значениями, и в соответствии с reference-семантикой при оперировании через ссылки, указатели. Т.е. по вашему он в одном случае значение, а в другом — объект?
S>Вынужден признать что да, таки ведёт себя по-разному. Значит, я что-то не так понимаю в теории. Либо мы имеем дело с особенно злостным коварством системы типов С++.
Да, в C++ с любой сущностью можно обращаться как с value и как с reference (если не запрещены соответствующие конструкторы и операторы). Потому проще считать что поведение объекта неизменно, а разница в том, как именно мы с объектом работаем, подразумевая под объектом саму его тушку, а не переменную.

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

S>Вообще, в программировании сейчас наблюдается значительный разрыв между теорией и практикой. Я не знаю, почему он происходит, но выглядит всё просто ужасно. Детям сначала рассказывают про высокое, а потом они приходят работать, а там ужосчто. И про этот ужосчто никаких вменяемых книг уже нету, приходится дотумкивать своим умом. Не всегда успешно. Тем более, что существуют упорно тиражируемые заблуждения, которые только отвлекают от сути вещей. Я уже упоминал про эпический спор об уровнях изоляции в РСУБД? Мне даже ссылки на Бернстайна приводили. Вот только оппа в том, что Бернстайн ни в одном месте про уровни изоляции явно не пишет. Как будто их нет. А они — есть. И вот люди начинают изобретать такие объяснения этим уровням изоляции, что шуба заворачивается. Включая искреннюю веру в то, что не все шедулеры транзакций обязаны обеспечивать сериализуемость.
S>И вот с ООП — то же самое.

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

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

Сейчас в IT идет ровно тоже самое, только в силу того, что прогресс за 20 лет шагнул дальше, чем за последние 100 лет (!!! именно так !!!), разницу в образовании очень сложно закрыть. А вузы и школы тупо пытаются заменить нехватку практики теоретическими знаниями.

Собственно это нормально — прогресс "сейчас" всегда идет быстрее чем прогресс "чуть раньше".

Здравствуйте, Игорь САВЧУК, Вы писали:

ИС>Статья:
ИС>Почему объектно-ориентированное программирование провалилось?

Автор(ы): Игорь САВЧУК
Дата: 30.01.2011
Среди множества идей, которые звучат красиво скорее в теории, чем на практике, объектно-риентированное программирование занимает особое место. Попробуем разобраться и ответить на главный вопрос, почему всё же объектно-ориентированное программирование провалилось?

ИС>Авторы:
ИС> Игорь САВЧУК

ИС>Аннотация:
ИС>Среди множества идей, которые звучат красиво скорее в теории, чем на практике, объектно-ориентированное программирование занимает особое место. Попробуем разобраться и ответить на главный вопрос, почему всё же объектно-ориентированное программирование провалилось?

Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 век..."тихая революция"

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

Вторая проблема с этим примером более серьёзная. Что значит вводить эфир, не меняя структуру теории в целом? А не означает ли это онтологическую инфляцию? Мы вводим новый объект, в котором инкапсулируются некоторые свойства и состояния (пока ещё до конца неизвестные). Свойства эти будут уточняться, но "каркас" теории не изменится. Либо же мы "перепишем" теорию — получится другая с другим "каркасом"? Тут ещё одна философская тема проскальзывает, а именно недоопределённость теории опытом, но не будем углубляться в этом направлении. Скажем лишь, что старый "каркас" можно было бы подстроить под новые эмпирические данные. А не встречаются ли знакомые для программистов слова, в том что я сейчас написал? А не предлагает ли Гэбриел повторного использования старой теории с эфиром, заюзав ООП-фичи?
Кстати, в науке такое "повторное использование" не очень приветствуется — нужна фальсифицируемость. А вот при построении практических систем это часто нужно...

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

W>Хотя бы предложил какие-нибудь практические приложения эфира в "обыденной жизни", не достижимые с помощью ТО.

Теория Максвелла, например. Когда из под этой теории выдернули эфир, она превратилась в пустую и непонятную абстракцию, т.к. представить, к примеру, вихрь в пустоте мягко говоря непросто. Собственно все научные теории до начала 20 века базировались на концепции эфира. А на практике в основном теории 19 века и используются.

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

A>Степанов много чего критикует, но никогда не разочаровывался в ООП вцелом.

А где про это? (Про то, что не разочаровывался.)

A>Та цитата была вырвана из разговора про Generic Programming. Под ООП в данном случае он имел классическую схему наследования и отметил, что она неэффективна для алгоритмических задач, где входные данные могут быть любым.

Откуда ты знаешь, что он там имел? Буквально было в частности следующее:

I find OOP technically unsound. (Alex Stepanov)

http://www.stlport.org/resources/StepanovUSA.html

Для слова unsound Google Translate дает следующие переводы:

1.необоснованный
2.нездоровый
3.гнилой
4.несостоятельный
5.испорченный
6.болезненный
7.больной
8.неглубокий
9.дефектный
10.неплатежеспособный
11.ненормальный
12.психически больной
13.ошибочный
14.ненадежный

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


W>Кстати, в науке такое "повторное использование" не очень приветствуется — нужна фальсифицируемость. А вот при построении практических систем это часто нужно...

Ну судя по http://elementy.ru/lib/430484 физики "повторным использованием" все-таки занимаются, правда стыдливо обзывают эфир "скалярным полем"

Здравствуйте, мыщъх, Вы писали:

М>афигеть! я и не знал даже.

http://www.rsdn.ru/article/winshell/batanyca.xml

Автор(ы): Алексей Александров
Дата: 11.07.2005
Статья рассказывает о малоизвестных возможностях командного языка Windows.

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

SV.>Что делали оверхайперы? Одни засирали эту простую и понятную схему тысячами типов-терминаторов (воробьи — воробьиноклювые — воробьинообразные — ... — серокрылые — птицевидные — ... — зерноядные — ... — летающие динозавры) до полной нечитаемости. Другие засирали эту простую и понятную схему неумеренной детализацией ("воробей" состоит из костей 100 видов, примерно 1.314 костей каждого вида, тканей 100 видов, а расфазовка отдельного "маха" приведена на той же схеме) до полной нечитаемости. Третьи, совсем никчемные, выводили бескрылых воробьев, оброщенных мехом, и получали таким образом белку-летягу (хороший пример из жизни — если повар наш не врет — можно найти тут: http://burrarum.livejournal.com/32707.html).

SV.>Грамотная декомпозиция на значимые сущности должна быть переложена на ЯП без изменений, с сохранением всех отношений, в т.ч. наследования реализаций.

отличная биллетристика сложилась
автор! мне вспомнился на это всё эссе — мультик "надо-в-дорогу, надо-в дорогу нам то-ро-пится, надо узнать, надо узнать — что я за птица.. ну и так далее ко-ко-ко-ро-ко-ко"
и конкретно по классам — не все что летает — птицы, не всё что несёт яички — птицы, только что имеет пёрышки — птицы