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

SV.>>А тут я снова ничего не понял. В вашем варианте HighPrecisionNumber — это что? Handle?
S>А как раз это — неважно.
S>Пусть это будет, скажем, ASCIIZ-строка, в которой хранится нужное нам количество цифр.
S>Или структ из тридцати интов для хранения мантиссы и ещё одного — для экспоненты.
S>Прикладному коду это совершенно безразлично.

1. Как узнать все доступные источники данных для преобразования в число высокой точности?
2. Как узнать все доступные форматы, в которые может быть преобразовано число высокой точности?
3. Как явно обозначить, что вы a) запрещаете b) разрешаете юзеру привязываться к текущему формату (чем бы он ни был)? То есть, заключить контракт.

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

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

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

SV.>Смотрите. Функция-решатель у меня изначально была отдельной функцией, не входящей ни в какой класс. Просто в силу ее функциональной природы. Про комплексные числа я не подумал, но зато (наверное) подумал Sinclair, и сделал функцию обобщенной. Шучу. Достаточно захотеть иметь обобщенное решение для простых чисел и чисел с повышенной точностью. Ну, еще при имплементации иметь в виду, что унарные операции могут для типа не поддерживаться (я имел). Так вот, с необходимостью обобщить функцию я согласился. Это отвечает на вашу претензию?
Да, вполне

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

S>>А в проблемы неудачного дизайна верите?

SV.>Если рассматривать проблемы у каких-то конкретных людей — почему нет?
Конечно же у людей. Компьютеру до фонаря на дизайн.

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

S>>>По идее, обобщенный метод — это скорее ФП решение. А для ООП нужно городить INumber и учить его складываться, умножаться и т.п. с самим собой. Либо вводить INumberArithmetic, который будет оперировать INumber-ами.

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

Нужен, и это будет проще чем городить INumber и тд. "другой вычислитель" — вычислитель может быть полиморфным, тебя это смущает ?

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

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

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

I>Нужен, и это будет проще чем городить INumber и тд. "другой вычислитель" — вычислитель может быть полиморфным, тебя это смущает ?
Тебе может нужен, а для решения уравнения в обобщенном виде — нет.

Здравствуйте, SV., Вы писали:
SV.>1. Как узнать все доступные источники данных для преобразования в число высокой точности?
Нет такого понятия, как "закрытый список источников данных для преобразования в число высокой точности".
Есть набор несвязанных между собой функций, которые преобразуют всякие разные "числа" в числа высокой точности.
Если меня что-то не устраивает в "заводской" версии библиотеки, то я просто пишу свою функцию HighPrecisionNumberFromBase64String() и не парюсь.
SV.>2. Как узнать все доступные форматы, в которые может быть преобразовано число высокой точности?
Нет такого понятия, как "закрытый список доступных форматов, в которые может быть преобразовано число высокой точности".
Есть набор несвязанных между собой функций, которые преобразуют числа высокой точности во всякие разные полезные форматы.
Если меня что-то не устраивает в "заводской" версии библиотеки, то я просто пишу свою функцию HighPrecisionNumberToRomanNumerals() и не парюсь.
SV.>3. Как явно обозначить, что вы a) запрещаете b) разрешаете юзеру привязываться к текущему формату (чем бы он ни был)? То есть, заключить контракт.
Не очень понимаю, чего вы хотите "обозначить". У меня задача — решить квадратное уравнение. Решателю уравнений совершенно наплевать на формат. Всё, что ему нужно — несколько функций с известными сигнатурами. (конкретно — унарный минус; бинарный минус; умножение; умножение на целое; деление; извлечение квадратного корня).

Здравствуйте, SV., Вы писали:
SV.>Смотрите. Функция-решатель у меня изначально была отдельной функцией, не входящей ни в какой класс. Просто в силу ее функциональной природы.
Ага. То есть здесь нестерпимого желания запихать решение уравнений внутрь класса нет. Причём ни внутрь класса-"числа", ни внутрь класса-"решателя".

SV.>Про комплексные числа я не подумал, но зато (наверное) подумал Sinclair, и сделал функцию обобщенной.
Ага. А ещё я подумал про октонионы и квадратные матрицы. И вообще про все "числа", над которыми определены те операции, которые нужны мне для решения задачи.

SV.>Шучу. Достаточно захотеть иметь обобщенное решение для простых чисел и чисел с повышенной точностью. Ну, еще при имплементации иметь в виду, что унарные операции могут для типа не поддерживаться (я имел).
Ну, вот тут, кстати, уже начинаются интересные моменты. Я сходу не скажу, нужны ли здесь унарные операции, или их можно выразить через умножение на -1? Нужно ли эту -1 приводить к типу данных и использовать умножение (моёчисло, моёчисло), или нужно требовать умножения (целое, моёчисло)? Нужно ли требовать оператора вычитания, или достаточно опять-таки умножения на -1 и сложения?

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

SV.>Что интересно, для меня обобщение ничего не меняет. Мой класс — способ упаковать различные конвертации и хранение, не дать им расползтись по всему проекту.
О, а вот здесь вы уже хотите упаковывать методы в класс.
Я подозреваю, что вы этого хотите исключительно с целью "снижения порога вхождения". Хотя с точки зрения изучения ваш класс фактически играет роль пространства имён. С точки зрения мейнстримных синтаксисов, совершенно неважно, во что именно резолвится HighPrecisionMath в цепочке Com::SV::Math::HighPrecisionMath — в класс или в namespace.

А я бы хотел этого (если бы хотел) с точки зрения контрактности. То есть мы можем понимать, что бывают "числа", подразумевающие только сложение, а бывают — ещё и умножение. Что у векторов умножения ажно два, и оба — коммутативные.

И вот тут у нас есть искушение ввести некую иерархию "умножателей и складывателей".
Впрочем, отложим пока арифметику. Сосредоточимся на том, как "упаковать различные конвертации и хранение".
Вот смотрите, допустим, у нас есть тип HighPrecisionNumber. Для него мы определелили набор методов-конвертеров. Скажем, для простоты, между HighPrecisionNumber и double.
Теперь встаёт вопрос: где разместить эти методы? В "экземпляре" HighPrecisionNumber, или во внешнем утилитном классе?
Размещение во внешнем классе позволяет нам делать интересные трюки с наследованием.
Например, мы хотим расширить чужую библиотеку по работе с этими числами, чтобы конвертер умел конвертировать число ещё и в Ieee666.
Если у нас методы расположены во внешнем классе HighPrecisionConversions, то мы можем от него отнаследоваться и добавить пару новых методов. Это позволит нам инстанцировать наш класс конверсий и передавать его везде, где требовался предок.
А если методы были расположены "внутри" HighPrecisionNumber, то мы огребём. Наследоваться от него нельзя — все функции по работе с HighPrecisionNumber возвращают HighPrecisionNumber, а вовсе не нашего потомка.
Так что даже если LSP соблюдён, то попытка скормить пару HighPrecisionNumberDerived в существующий operator + приведёт лишь к возврату HighPrecisionNumber — значения.
Именно поэтому в C# нам придётся перереализовать все операторы и методы для нового типа. Это многословно и неудобно.

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

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

I>>Нужен, и это будет проще чем городить INumber и тд. "другой вычислитель" — вычислитель может быть полиморфным, тебя это смущает ?
S>Тебе может нужен, а для решения уравнения в обобщенном виде — нет.

Этот "вычислитель" требует ООП, а не уравнения.

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

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

I>>>Нужен, и это будет проще чем городить INumber и тд. "другой вычислитель" — вычислитель может быть полиморфным, тебя это смущает ?
S>>Тебе может нужен, а для решения уравнения в обобщенном виде — нет.

I>Этот "вычислитель" требует ООП, а не уравнения.
И в каком же месте ООП требует единый вычислитель для работы с числами самой разной природы, особенно если задача его не требует?

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

I>>Этот "вычислитель" требует ООП, а не уравнения.
S>И в каком же месте ООП требует единый вычислитель для работы с числами самой разной природы, особенно если задача его не требует?

В реальном мире числа не умеют складываться, они вообще ничего не умеют
Хочешь проверить — напиши на бумажке числа и пусть они суммируются, только ты никак им не помогай.
Когда надоест ждать, сделай всё сам и запиши все свои действия которые тебе надо сделать что бы рядом с числами появилась сумма.
Модель построена. Теперь надо перегнать её в код.
Все эти действия на бумажке офрмляем в виде класса Сумматор, задаёшь интерфейс, контракт и дело в шляпе — модель переведена в код согласно ООП.

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

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

I>>>Этот "вычислитель" требует ООП, а не уравнения.
S>>И в каком же месте ООП требует единый вычислитель для работы с числами самой разной природы, особенно если задача его не требует?

I>В реальном мире числа не умеют складываться, они вообще ничего не умеют
I>Хочешь проверить — напиши на бумажке числа и пусть они суммируются, только ты никак им не помогай.
I>Когда надоест ждать, сделай всё сам и запиши все свои действия которые тебе надо сделать что бы рядом с числами появилась сумма.
I>Модель построена. Теперь надо перегнать её в код.
I>Все эти действия на бумажке офрмляем в виде класса Сумматор, задаёшь интерфейс, контракт и дело в шляпе — модель переведена в код согласно ООП.

А теперь ближе к сути вопроса. Каким местом ООП требует вычислитель для работы с числами самой разной природы, и почему недостаточно вычислителя для работы с числами совершенно конкретной приорды?

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

I>>В реальном мире числа не умеют складываться, они вообще ничего не умеют
I>>Хочешь проверить — напиши на бумажке числа и пусть они суммируются, только ты никак им не помогай.
I>>Когда надоест ждать, сделай всё сам и запиши все свои действия которые тебе надо сделать что бы рядом с числами появилась сумма.
I>>Модель построена. Теперь надо перегнать её в код.
I>>Все эти действия на бумажке офрмляем в виде класса Сумматор, задаёшь интерфейс, контракт и дело в шляпе — модель переведена в код согласно ООП.

S>А теперь ближе к сути вопроса. Каким местом ООП требует вычислитель для работы с числами самой разной природы, и почему недостаточно вычислителя для работы с числами совершенно конкретной приорды?

Потому что ООП годится для перевода в код моделей объектов из реального мира, с поведением, блекджеком и шлюхами. Кроме как для поведения ООП наверное ни на что не годится. Потому моделируем поведение. У кого оно есть ? У человека, устройства, механизма и тд. Когда модель готова, дальше дело за ООП — преобразовать модель в код.

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

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

S>>А теперь ближе к сути вопроса. Каким местом ООП требует вычислитель для работы с числами самой разной природы, и почему недостаточно вычислителя для работы с числами совершенно конкретной приорды?

I>Потому что ООП годится для перевода в код моделей объектов из реального мира, с поведением, блекджеком и шлюхами. Кроме как для поведения ООП наверное ни на что не годится. Потому моделируем поведение. У кого оно есть ? У человека, устройства, механизма и тд. Когда модель готова, дальше дело за ООП — преобразовать модель в код.

Так откуда вытекает требование?

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

S>Ну, вот тут, кстати, уже начинаются интересные моменты. Я сходу не скажу, нужны ли здесь унарные операции, или их можно выразить через умножение на -1? Нужно ли эту -1 приводить к типу данных и использовать умножение (моёчисло, моёчисло), или нужно требовать умножения (целое, моёчисло)? Нужно ли требовать оператора вычитания, или достаточно опять-таки умножения на -1 и сложения?
Смотря для чего вводить реализацию. Для полей — можно и умножать на -1, существование которой гарантировано. Если мы захотим ввести операции над кольцом, то там не факт что -1 является элементом этого кольца (например кольцо четных чисел), но обратный элемент относительно операции сложения обязан быть. Для вычитания достаточно будет сложения и взятия обратного относительно сложения.

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

M>Подумалось мне что-то... А ведь классическое «висит окно, принимает события» — это классический Erlang Насколько это ФП — это уже ХЗ

Ну так Эрланг — это самое ООП и есть. Процессы — объекты, обменивающиеся сообщениями. Applications — компоненты. Releases — приложения/системы. Behaviours — (недо)интерфейсы. OTP-модули — (недо)классы. Но все эти -недо- с лихвой компенсируются рантаймом — он прекрасен В итоге получаем ФП язык с приемлимыми средствами струкрурирования на макро-уровне и отличной VM.

I>"Не мешает" это не значит, что помогает. Просто порог входа в ООП гораздо ниже в силу того, что ООП можно хорошо изучать на легкодоступных примерах. Даже без книг этот порог берется на раз, если прилагать хоть какие то усилия.

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

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


V>>Если бы ты понимал, где свободные переменные, а где связанные, ты бы понимал, где когда и сколько вызовов надо произвести. Реально на каждое замыкание со свободными переменными по одному вызову. То бишь замыкание легко заменяется процедурой. Собсно, именно это от меня и требовалось.

I>Ты утверждаешь выше, что тебе на все случаи не нужно писать разные версии этой процедуры. А я утрвеждаю, что надо.

Тогда ты не читал или не понял моих примеров. Не желаешь их верифицировать на предмет семантики происходящего?
Я тебе специально оставляю своё цитирование — в нем ключ для понимания.


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

Проблема может быть только от непонимания собственного кода. Ты привел некий код и даже не понимаешь как он работает. Вернее так — ты настаиваешь, что имеешь право не понимать, как работает твой код, потому что "пусть всё будет само". Стремный подход, как по мне.



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

Гы-гы 2 раза. Вот это жжешь...
Понимаешь... Вернее наоборот — если ты этих вещей не понимаешь (ну не приучен твой мозжечек читать код на автомате), то твои творения — претендент №1 на мильон фейерических нежданчиков, сопровождающих автоматический захват контекста по мутабельным переменным.


I>Я дал три примера, ты их скипнул. Попробуй предложить хотя бы похожий аналог...

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

Там, кстате, кое-какая семантика изменена в моих примерах. Ты и этого не увидел. Но она не относится к ФП/ПП, а сугубо по прикладной части, т.к. интерфейс для сортировок в дотнете безбожно кривой... За верту несет индусятиной.

V>>Гы, у меня-то как раз даже ф-ию сортировки протянуть не проблема через Fn, а у тебя надо всё раздезайнить заново.
I>Мне как раз все что надо это лямбду поправить. Правка лямбды это уже смена дизайна ? А ты не простой.

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

I>Внимательнее читай.
I>>>

I>>>Order(x => operation.Apply(Mask(x)))
I>>>

Внимательней пиши. Тут не видно, что это экземплярный мембер.


I>>>Вот оно, бедствие — Mask это метод того же класса что и Order, а значит тебе надо еще накидать N-структур, то есть пары {SaltedModifier, SomeClass}.

Нет, мне надо связать всего одну доп. переменную — this. Все связаные переменные уйдут в контекст. Кол-во контекстов никак не зависит от кол-ва переменных.


V>>Беда только в голове. Поскольку кол-во замыканий сосвободными переменными у нас не изменилось, то кол-во элементов программы в моем примере не изменится. Изменится тело локальной ф-ии CompareUsingModifier точно так же, как изменился твой локальный код. Вместо sm->Apply(a) будет sm->Apply(Mask(a)).

I>Локальные функции есть во всех языках ? Это новость

Лакальные есть во всех процедурных языках, а что? Это ф-ии, видимые лишь из одной единицы компиляции. То бишь нигде более не объявляемые и никуда не экспортируемые.


I>Замыкания контекстов вдруг перекочевали в процедурное программирование. А ты, не простой.

Нет никаких замыканий в процедурном программировании. Я ручками расписываю то, что у тебя происходит "само". А "само" у тебя происходит исключительно раскладка граблей, бо ты смелО замыкаешь мутабельные данные/объекты, включая this.


I>Локальные функции я так поянял есть во всех процедурных языках ? Это новость

Дык, даже в отце всех процедурных языков — в Фортране.
И если это твой "последний аргумент", то я признаю себя заведомо победителем этого спора.


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

Решил приписать мне лишнее? Все посты на месте, можешь освежить.


V>>

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

I>Нет этого аналога, ты демонстрируешь ООП и ФП особенности.

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

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

I>Ты демонстрируешь ООП и ФП а не процедурное программирование.

Мне виднее, я успел на ПП пописать несколько лет до полноценного переползания на ООП. Реально ООП и ФП используют практические наработки процедурного/структурного программирования, а вовсе не наоборот.

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


I>Нет в процедурном тех вещей которые ты использовал в своем коде.

Есть. Просто ты придумал себе несуществующее на свете процедурное программирование, вместо имеющегося в реальности.


V>>Гы-гы-гы... Мож хоть раз с тобой на что-то конкретное поспорить? Ты же даже функциональной декомпозицией не владеешь, пишешь и не понимаешь свой собственный код... Ты даже не понимаешь, что показал мне в скипнутых примерах сценарии использование всего двух (ДВУХ!) базовых комбинаторов.

I>А мы договаривались что я покажу тебе все комбинаторы ? Или ты просто решил намекнуть непойми на что ?

Ты можешь показать что угодно, но 3 базовых комбинатора существуют независимо от тебя. Остальные комбинаторы — производные. И уж мне хватит соображалки выразить любой из них через базовые. Это задача примерно 8-го класса.


I>Ты обещал что покажешь лямбды в процедурном программировании и пока что у тебя примеры ФП и ООП. то есть, тебе просто хочется сменить тему.

ОК, это уже какая-то жалость, а не чтиво. Хреновый из тебя боец. ))
Адью.

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


I>Чисто для интереса, это в С++0x или ты имеешь ввиду локальные классы вроде

I>

I>void f()
I>{
I>   int x;
I>   class XXX {
I>      int& x_;
I>   public:
I>      XXX(int& x) : x_(x) {}
I>      void operator()() { ... }
I>   } _xxx(x);

I>   ...
I>}
I>

Так тоже можно и не только в новом С++. Но под локальностью подразумевалось не это, а видимость процедуры/ф-ии из всего проекта.
В пред. посте ответил.

==========
Показанный вариант имеет кое-какие ограничения при использовании его как параметров шаблонов, поэтому в таком виде его не используют. Он подойдет только если объявить в нем статические методы — они и будут те самые локальные ф-ии, которые придется связывать с аргументами посредством заранее объявленного шаблонного ф-ого типа, например, через boost::bind.

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

V>>Оп-па! Отраженный от двери свет послан не дверью. Я бы на месте твоего школьного учителя физики съел свою шляпу.
S>да, ну если так сложно со светом, давай представим мяч, который попал в тебя рикошетом от двери. Ты будешь думать что это дверь послала в тебя мяч? Не, я догадывался что у тебя проблемы с дверьми, но что настолько... Пожалуй мой учитель тут не виноват.

Конечно виноват, он не проверил у тебя раздел оптики и взаимодействия элементарных частиц.
1. Не существует способа узнать, был ли фотон отражен, или сгенерирован.
2. Более того, отраженный фотон не факт, что это тот же самый фотон, который падал на поверхность. Отражение фотона от электрона (а ты видишь 99.9999% отраженных фотонов именно от электронов) описывается как поглощение одного фотона и испускание другого.

V>>Как это вне зависимости, если ты свои органы чувств должен настроить таким образом, чтобы достоверно различить положение двери. То бишь, получить информацию о ней? Как минимум ты должен открыть глаза, посомтреть в ее сторону и сфокусировать кристаллики глаза. Ничего себе "не спрашивал"... Или ты буквально выразился в том плане, что решил с дверью поговорить? )))
S>Слушай, а ты машину водишь? И вообще, когда смотришь, фокусируешься на всем подряд и спрашиваешь каждую вещь, видишь ли ты ее?

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


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

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

V>>Вообще-то ты писал о Лиспе.
S>Я писал о чистом языке.

Совсем чистый язык совсем бесполезен как прикладной. Например, совсем чистые языки док-ва теорем нужны для того, чтобы компилятор сказал — компиллируется или нет программа. Это всё. Но для меня этого бесконечно мало.


V>>Вилять можно только если влез, а потом понял, что не туда. Так что виляние уже де-факто происходит. Ты дважды оспорил, а потом так и не пояснил, ПОЧЕМУ ты спорил-то. Если не воспринимаешь оппонента всерьез, зачем столько пишешь ему в ответ?
S>Я уже задолбался писать, почему я спорю и за что. А про зачем столько пишешь — ну мне ведь интересно, куда ты дальше вильнешь.

Нет, ты таки не пояснил:

Кэй писал что вдохновлялся атомами Лиспа. На самом деле от Лисп-атома до кортежа функций не так далеко.

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


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

Вооот. "Мешок". Т.е. "нечто", собраное воедино и относящееся к одному и тому же... )))
Понимаешь... Если обмен сообщениями рассматривать как обмен информацией (а оно именно так), то ничуть не далеко.

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

I>>Потому что ООП годится для перевода в код моделей объектов из реального мира, с поведением, блекджеком и шлюхами. Кроме как для поведения ООП наверное ни на что не годится. Потому моделируем поведение. У кого оно есть ? У человека, устройства, механизма и тд. Когда модель готова, дальше дело за ООП — преобразовать модель в код.

S>Так откуда вытекает требование?

Это никакое не требование. ООП всего лишь инструмент для перевода модели в код. Эффективность меряешь сам. ООП здесь ничем не помогает. То есть неэффективная модель может быть переведена в неэффективный код и ООП здесь ни при чем.
Наилучший эффект получается только для моделей из реального мира, с поведением и тд.

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

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


V>>>Если бы ты понимал, где свободные переменные, а где связанные, ты бы понимал, где когда и сколько вызовов надо произвести. Реально на каждое замыкание со свободными переменными по одному вызову. То бишь замыкание легко заменяется процедурой. Собсно, именно это от меня и требовалось.

I>>Ты утверждаешь выше, что тебе на все случаи не нужно писать разные версии этой процедуры. А я утрвеждаю, что надо.

V>Тогда ты не читал или не понял моих примеров. Не желаешь их верифицировать на предмет семантики происходящего?
V>Я тебе специально оставляю своё цитирование — в нем ключ для понимания.

Нет там никаких ключей, посмотри свой код, разуй глаза.

V>Проблема может быть только от непонимания собственного кода. Ты привел некий код и даже не понимаешь как он работает. Вернее так — ты настаиваешь, что имеешь право не понимать, как работает твой код, потому что "пусть всё будет само". Стремный подход, как по мне.

Вообще речь о том, что ты обещался показать процедурное программирование к контексте лямбд, а показал ФП и ООП. Это залет


I>>Ну да и разбираться где в каком случае надо создавать новые экземляры, а где реюзать контекст.

V>Гы-гы 2 раза. Вот это жжешь...
V>Понимаешь... Вернее наоборот — если ты этих вещей не понимаешь (ну не приучен твой мозжечек читать код на автомате), то твои творения — претендент №1 на мильон фейерических нежданчиков, сопровождающих автоматический захват контекста по мутабельным переменным.

Если ты не понял, то это вопрос про GC.


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

Ты не расписал ни одного. Ты обещал показать процедурное программирование, а показал ФП и ООП.

V>Там, кстате, кое-какая семантика изменена в моих примерах. Ты и этого не увидел. Но она не относится к ФП/ПП, а сугубо по прикладной части, т.к. интерфейс для сортировок в дотнете безбожно кривой... За верту несет индусятиной.

Это не важно, ты не раскрыл свой основной поинт.

V>>>Гы, у меня-то как раз даже ф-ию сортировки протянуть не проблема через Fn, а у тебя надо всё раздезайнить заново.
I>>Мне как раз все что надо это лямбду поправить. Правка лямбды это уже смена дизайна ? А ты не простой.

V>Поправка лямбды тебе поможет не всегда из-за ограничений сигнатуры показанного метода для сортировки.

А в твоем случае как максимум не лучше.

I>>Внимательнее читай.
I>>>>

I>>>>Order(x => operation.Apply(Mask(x)))
I>>>>

V>Внимательней пиши. Тут не видно, что это экземплярный мембер.

Это очевидно.

I>>Локальные функции есть во всех языках ? Это новость

V>Лакальные есть во всех процедурных языках, а что? Это ф-ии, видимые лишь из одной единицы компиляции. То бишь нигде более не объявляемые и никуда не экспортируемые.

Нет. Покажи мне локальные функции для языка Си. Спасибо.

I>>Замыкания контекстов вдруг перекочевали в процедурное программирование. А ты, не простой.

V>Нет никаких замыканий в процедурном программировании. Я ручками расписываю то, что у тебя происходит "само". А "само" у тебя происходит исключительно раскладка граблей, бо ты смелО замыкаешь мутабельные данные/объекты, включая this.

Правильно, нет. А ты использовал именно их.

I>>Локальные функции я так поянял есть во всех процедурных языках ? Это новость

V>Дык, даже в отце всех процедурных языков — в Фортране.
V>И если это твой "последний аргумент", то я признаю себя заведомо победителем этого спора.

Покажи локальные функции в языке Си.

I>>Нет этого аналога, ты демонстрируешь ООП и ФП особенности.

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

Ты показал что функциональщина это функциональщина, а обещал показать что функциональщина это процедурное.

I>>Ты демонстрируешь ООП и ФП а не процедурное программирование.

V>Мне виднее, я успел на ПП пописать несколько лет до полноценного переползания на ООП. Реально ООП и ФП используют практические наработки процедурного/структурного программирования, а вовсе не наоборот.

Из твоих примеров это не следует.


I>>А мы договаривались что я покажу тебе все комбинаторы ? Или ты просто решил намекнуть непойми на что ?

V>Ты можешь показать что угодно, но 3 базовых комбинатора существуют независимо от тебя. Остальные комбинаторы — производные. И уж мне хватит соображалки выразить любой из них через базовые. Это задача примерно 8-го класса.

Не важно. Мы говорим совсем на другую тему и количетсво комбинаторов в моих примерах не имеет значения