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

ВВ>>>Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел. UI будет.
I>>А что ты видел в дизайне распределенных ?

ВВ>Анемики, сервисы и иже с ними.

Это все православное ООП

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

I>>Так у вас что, живые ссылки на эти пустые списки ?

V>Конечно, живые. Пока живо сообщение, жив список его полей, даже если он пуст.

Вот это и есть ошибка. Скорее всего вы создали для GC проблемы в другом месте и ему стало проблематично рабоать даже с нулевым поколением. Такое бывает в некоторых вырожденых сценариях, когда даже какой нибудь EventArgs создать не получается и GC педалит минутами.

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

V>Гы-гы два раза. Дешевле всего избегать лишних ветвлений, каждый раз дополнительно проверяя объект на null. Но это дешевле без new, ес-но, поэтому, если кол-во полей в пришедшем сообщении =0, то цепляется статический пустой список полей. Фигли там всей инфраструктуры на 3 строчки в проекте-полумиллионнике...

Количество ветвлений ты не уменьшаешь, оно полностью сохраняется. Уменьшается количество инстанцирований, смотри внимательно:

return list ?? new ArrayList<T>();

return list ?? Static<ArrayList<T>>.Instance;

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

Если от тебя примера не будет — не надо ничего писать, идёт ?

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

V>Дык, именно в этом соль.

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

V>Мало ли, что компилятор в процессе оптимизации переписывает?

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

V>Точно так же и компилятор ФП, он может переписать много, но семантика результата должна быть точно такая же, как я получаю, пробегаясь по коду глазами... Иначе, как программировать-то?

Порядок вычислений в семантику чистого Ф-кода не входит, в отличие от императивного.

V>>>Фортран, ес-но.
AVK>>Это все?
V>Если речь об истоках, должно было хватить.

Т.е. это все. ЧТД.

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

K>Я их не заменяю на языки высокого уровня.

Я, кажется, прекрасно продемонстрировал твой финт ушами.

K> Я их считаю языками наиболее высокого уровня из возможных

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

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

K>Примеры полезных абстракций, пожалуйста.

Зачем? Примеры специфичны для конкретных предметных областей. Например "Проводка бухгалтерской справки". Сильно полегчало?

K>Именно этих людей (внедренцев) я и причисляю к программистам в первую очередь.

А я — нет. Потому что они не программируют.

K> Хотите — не соглашайтесь. Просто в современной разработке им повезло сбросить наиболее нудную часть кодинга и проектирования программистам попроще (гикам), кто сидит в офисе и получает готовое разжеванное ТЗ.

Ух ты. Ты внедренец, что ли?

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

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

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

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

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

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

ВВ>Просто забавно, было наблюдать, как ты весьма охотно со мной спорил о чистоте концепций

Тебе показалось.

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

Ты бы вместо жоп посчитал количество подтасовок в своих сообщениях.

Вобщем, общайся с кем нибудь другим.

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

S>Если бы визитора генерил компилятор ФП, то он мог бы давать какие-то гарантии.

Мог бы. Но ведь не генерит.

S> Но в рукописном внутреннем визиторе тоже нет гарантий обработки всех вариантов.

Есть. Ну если специально не вредить. Абстрактный AcceptVisitor в базовом классе заставит себя реализовать во всех неабстрактных потомках.

S>>>или dynamic-ах.
AVK>>Ты это серьезно?
S>почему бы и нет, для случаев где за тактами бегать не надо

Да при чем тут такты? Это прежде всего отказ от статического контроля типов со всеми вытекающими.

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

I>>Для GC это мизер Издержки на очереди много больше издержек на выделение памяти. Я накидал тест, как ты говоришь, и в ём инстанцирований в 8 раз меньше, нежели без очередей,

V>Всё с вами ясно... Умудриться написать очередь, которая в 8 раз тяжелее GC — это весчь... )))

Как ты мерял тяжесть GC ?
Разница в количестве инстанцирований с очередями и без очередей. Как это можно понять как "в 8 раз тяжелее GC " мне очень интересно. Ты вероятно думаешь, что инстанцирование это такая дорогая операция, отсюда твои "хи хи"

V>У нас она намного легче, чем GC. Не пробовал такую штуку, как "интрузивный список"?

Что значит "легче, чем GC" ? Ты в курсе, что издержки на интрузивные списки намного выше твоей экономии на пустом списке ?

I>>А то что вы храните ссылки на пустые списки — это ваша проблема.

V>Этот пустой список в моем варианте — один на всех.

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

V>>>Интересно глянуть нагрузку процессора в таком выхолощенном примере, учитывая, что в реальном примере пакеты приходят по сети и уходят в сеть и на каждый пакет есть кое-какая небесплатная логика.
I>>Так тест будет а то опять окажется что у тебя условие снова изменилось ?

V>Дык, ты не привел своих данных. Сколько сообщений в секунду ты выжал на выхолощенном примере?

Ты не смог поделить 20млн на 8 ? Бывает. Коллекции стандартные, без изысков. Полученное число на порядок больше твоих данных.

V>А мне сюда исходники ложить, чтобы ты их тестировал или как?

Ты описал модель, правильно ? ты не в состоянии повторить её или же она неадекватна ?

V>>>Я привел конкретные цифры, на которых GC ложился навзничь (техника 5-тилетней давности, как и задача). Проблемы были именно в GC, потому что переиспользование объектов это дело лечит.
I>>Проблемы оттого что вы хранили ссылки на пустые коллекции.

V>Не только. Проблемы от того, что мы храним сами сообщения.

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

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

И это еще больше усиливает уверенность, что экономия на пустом списке как мертвому припарка, дальше я скипнул. Для GC нужно создавать как можно чаще, а не бороться с этим. Вы пошли по другому пути и отсюда ваши оптимизации.

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

I>>Указатель на функцию это уже ФП, опаньки ! Процедурная парадигма не умеет никаких таких вещей.

V>Дудки, ФП — это где есть механизм ФВП. А если речь об адресе статической ф-ии, видимой в compile-time, то это не ФП, а банальный AddressOf из махровых императивных 70-х.

В структурном программировании нет никаких указателей на функции.

Ну ладно, хрен с ним , вот еще пример

Mod modifier = GetSalt();
Ctx ctx = GetContext();

Order(x => modifier[ctx].Apply(x))

Покажи такой же фокус, что бы все было так же прозрачно.

I>>Кроме того, в твоем примере все точно так же упирается в имена функций при том что один из методов, там где ExtractABC хуже некуда.

V>Ниче не понял, перефразируй, плиз.

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

I>>В моем случае все это по месту вызова.
V>Тю блин, в твоем случае была одна полезная строчка. В случае же тысяч полезных строчек, удачно подобранные имена идентификаторов становятся всё более востребованными, не находишь? ))

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

V>Так видел или не видел? http://cplus.about.com/od/learningc/ss/pointers2_8.htm
V> Там же такое же точно IoC в полный рост. И это императив из махровых 70-х. А при вызове мы совершаем над qsort то самое DI, подавая адрес ф-ии-компаратора.

Там нет никакого IoC. не веришь — покажи аналог для моего кода выше.

V>Да, я привел основную концепцию ФП на не ФП. Именно это я и хотел тебе показать, см своё исходное утверждение:

То есть, все атки ФП ? Опаньки ! А надо было показать разницу между функционально и процедурной.

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

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

Это вы, батенька, уже малость забегали.

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

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

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

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

В твоей реальной жизни еще играют рояль твои органы чувств, как минимум зрение и/или осязание. И цикл обработки сигналов от органов чувств тоже не такой уж чтобы сложный для моделирования в ООП.


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

Дык, надо было учить физику в школе, тогда ничего в унитаз бы не слилось. ))

Ты даешь двери воздействие. Затем "что-то происходит": силы складываются по-ньютоновски, кинетические энергии переходят в потенциальные, импульс поглощается притолокой или твоей руйкой и т.д. и т.п., ты той же рукой осязаешь положение двери и/или контроллируешь ее положение взглядом, сигналы органов чувств попадает тебе в мозг, накладываются на твой опыт и понимание, как выглядит/озязается открытая и закрытая дверь, и после сопоставления своего опыта и сигналов рецепторов ты делаешь вывод о том, открыта ли она... Но сорри, мы же программисты — ленивый народ и не делаем лишнюю работу! Коль тебя интересует лишь конечный результат, то мы абстрагируемся от подробностей и просто хотим получить результат — дверь открыта в итоге или нет? Итого всё взаимодействие с дверью сводится к посылке двух сообщений: от тебя к двери и от двери к тебе. Если эти события не единомоментны в твоей модели, то это будут два разнесенных во времени события, связанных причино-следственной связью. И ты применишь какой-нить паттерн асинхронного вызова с калбэком, где экземпляр калбэка и отвечает в упрощенной модели за причинно-следственную связь. Если же мы абстрагируемся и от фактора времени, то вернуть результат можно сразу же, как результат вызова ф-ии, итого:

enum State { Open, Closed }

class Door {
  public State Open() {}
  public State Close() {}
}

Учитывая целеустремленность человеческой психики, кому-то нейтральное описание событий покажется пресным и он предложит другой вариант:

enum Achievement { Success, Fail }

class DoorAsTarget {
  public Achievement Open() {}
  public Achievement Close() {}
}

Но т.к. оба варианта могут быть выражены один из другого взимно однозначно, то лично мне фиолетофо. ))



S>То как будет сформулировано ТЗ не повлияет на возможность реальной двери рассылать сообщения. Это свидетельствует в пользу того что ООП-изация двери далека от рж.

Пока что это свидетельствует о, скажем, недоформулированном ТЗ и больше ни о чем.

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


V>>Такой у него точно не было ))
S>Значит ты его точно не читал

А что, он писал про сквозняк и всё что ты там предполагал ты, оказывается, его цитировал? )))
Не обижай старика-то...

V>>Позволь мне разобраться самостоятельно, что как называть. "функциональный объект" — это известный устоявшийся термин. Это именно то, как выглядит ФВП с точки зрения ООП, то бишь его внутренняя конструкция. И да, замыкания могут быть мутабельными... Хотя бы в Лиспе.
S>Я написал о чистом языке. Мутабельные замыкания в чистом языке — это определенно прорыв.

Увы, если замыкание реализовано by-name, или мутирующие ф-ии для переменных не создают нового одноименного значения в контексте, а изменяют старое — то так и есть. Просто есть много реализаций и проблема совместимости Лиспового кода как раз и состоит в разной семантике замыканий и операций над т.н. "контекстом". Но популярный CL — самый "грязный" из всех реализаций...


S>>>>>На самом деле от Лисп-атома до кортежа функций не так далеко.
V>>>>Бесконечно далеко.
S>>>ну-ну
V>>По-я-сни.
S>Я на самом деле не в теме, но речь явно не о бесконечности.

5 баллов! )))
Я бы под пиво или что покрепче такой ход беседы понял бы... Но вот так здесь и сейчас...


V>>Дык, если наследования нету, то компилятор С++ вообще виртуальные вызовы на обычные заменяет аж бегом. В обход vtable. В этом плане у кого больше статики?
S>А если наследование есть, то не заменяет.

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

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

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

V>Даже есть условные переходы, но нет циклов.

Инструкцию loop уже отменили?

V> Есть вызов подпрограмм по неизвестному в compile-time адресу, но нет ФВП.

Если учесть отсутвие контроля сигнатуры функции, то все признаки ФВП имеются. Признаки у ФВП такие:
Functions can consume functions as arguments
Functions can produce functions as return values

Очевидно, что и то и другое в ассемблере х86 делается без каких либо проблем.

DG>>Как минимум стоит тогда вернуться к основам.
DG>>Я утверждаю, что объект — это ментальная модель служающая для удобства описания происходящего, обладающая рядом характеристик (а дальше по любому классическому учебнику ООП).
S>Вы путаете две вещи. Начинаете вы с философского понятия "объект", который всего лишь противопоставляется субьекту. Такой объект вполне может быть нечётким, и недоопределённым, и т.п.

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

DG>>Соответственно, по этому определению, например, и linux-овый file и winapi-шный файл — являются объектами. И тред на форуме rsdn.ru тоже является объектом.
S>А потом вы внезапно перепрыгиваете в ООП-шное определение объекта, которое значительно более строгое. Но при этом почему-то пользуетесь двумя разными определениями взаимозаменяемо.
S>Файл в винде и линуксе как раз похож на ООП-шный объект, и ОО-дизайн в WinAPI торчит довольно сильно.
S>Но ООП требует от объекта некоторых минимальных вещей, в частности — идентичности. Философский объект "верёвка" запросто может состоять из двуз философских объектов "конец верёвки" и одного "середина верёвки". ООП-шный объект так построить не удастся — потому, что нет возможности провести чёткую границу между "серединой" и "несерединой". См. "где начало того конца, которым заканчивается начало".

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

> ООП-шный объект так построить не удастся — потому, что нет возможности провести чёткую границу между "серединой" и "несерединой".

во-первых, какое отношение определенность(или неопределенность) границы объекта имеет к идентичности?
во-вторых, при необходимости всегда можно построить две последовательности определений, которые будут задавать границу с заданной точностью.

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

AVK>Висит, принимает ... Куда интереснее что происходит, когда я в дизайнере надпись на кнопочке меняю. Или в рантаме жамкаю по чекбоксу.

Отослали сообщение куда надо Только вот что именно является этим «куда надо» — хз В случае с Эрлангом это таки будет процесс, держащий в себе состояние

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

S>>>Да я знал об этом до тебя. Речь о том, что никакого побочного эффекта это не дает, и повода для сношения со Структурным Программированием нет.

V>>Ты отрицал ветвление в заданном порядке исполнения. Уже не отрицаешь? Можно двигаться дальше?
S>В СП ветвление — оно об выполнении стейтментов. В хаскеле их нет.

А ветвление в логических рассуждениях человека оно о чем? ИМХО, рассуждения более чем чисты, а ветвление — налицо.
Кароч, отрицать ветвление в ФП не выйдет. Довод, что "ветвление другой системы" вообще ни о чем, в обсуждаемом вопросе система не интересует ни разу.

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

AVK>Есть. Ну если специально не вредить. Абстрактный AcceptVisitor в базовом классе заставит себя реализовать во всех неабстрактных потомках.

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

Здравствуйте, DarkGray, Вы писали:
DG>лучше на пальцах покажи.
DG>вот, например, счет Xxx при доступе через инет-банк, банкомат и операциониста — это один и тот же счет или разный?
DG>идентичность при этом у него строго определенная, а вот набор операций меняется, доступное состояние тоже.
В зависимости от реализации
И идентичность у него может быть тоже совершенно разной. То, что тебе кажется одним и тем же объектом, окажется принципиально разными пятью, когда ты придёшь в банк.

DG>во-первых, какое отношение определенность(или неопределенность) границы объекта имеет к идентичности?
Очень простое — идентичность должна всегда давать однозначный результат. Для неё должны сохраняться требования транзитивности и симметричности.
А "нечёткая" идентичность этому не будет соответствовать.
DG>во-вторых, при необходимости всегда можно построить две последовательности определений, которые будут задавать границу с заданной точностью.
Тогда мы получим какую-то другую математику, не ООП.

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

K>>Я их не заменяю на языки высокого уровня.

AVK>Я, кажется, прекрасно продемонстрировал твой финт ушами.

Какой финт ушами ? Вы подразумевали не то, что подразумевал я, и все.

K>> Я их считаю языками наиболее высокого уровня из возможных

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

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

K>>Примеры полезных абстракций, пожалуйста.

AVK>Зачем? Примеры специфичны для конкретных предметных областей. Например "Проводка бухгалтерской справки". Сильно полегчало?

Это не абстракция над предметной областью. Это в предметной области есть само по себе.

K>>Именно этих людей (внедренцев) я и причисляю к программистам в первую очередь.

AVK>А я — нет. Потому что они не программируют.

Сыграю в капитана. У вас вполне определенное понятие, что есть программирование, а что — нет. Но это лишь ваше определение слова, не более того. Как и мое. Есть и другие. Существенна может быть лишь разница в отношении того, что они определяют.

K>> Хотите — не соглашайтесь. Просто в современной разработке им повезло сбросить наиболее нудную часть кодинга и проектирования программистам попроще (гикам), кто сидит в офисе и получает готовое разжеванное ТЗ.

AVK>Ух ты. Ты внедренец, что ли?

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

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

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

Вообще, если человек никогда не участвовал во всем цикле, начиная со сбора требований, продолжая реализацией и саппортом, и заканчивая переводом на новую систему после end of life старой, я бы ему не доверял.

Но это мы уже совсем ушли в сторону.

Здравствуйте, Ikemefula, Вы писали:
S>>Сумматора в реальном мире нет. И вычислителя съеденной травы в реальном мире нет. В реальном мире есть корова и трава.

I>19й век
I>

I>В двадцатом уже были универсальные вычислители. А про логарифмическую линейку, счеты ты тоже забыл ?
Линейка и счёты не ведут себя как объекты.
I>Соответсвено идея вычислителя, как некоего устройства, есть заимствование из реального мира.
Омг, омг. У нас была предметная область (вы называете её реальным миром), состоящая из коровы и травы.
Внезапно (ВНЕЗАПНО!) в этот реальный мир внедряется некое устройство, как идея вычислителя. У пастуха, который пас корову, ни разу в жизни не возникло идеи про этот вычислитель.
А вот ООП-программа почему-то совершенно не обращает внимания на корову и траву, а вместо этого моделирует вычислитель, которого вовсе нет и никогда не было.
И это совершенно правильно и корректно. Вот только учебники ООП почему-то как правило при рассмотрении коровы и травы не предлагают моделировать машину Бэббиджа, зато предлагают моделировать корову и траву. Вы посмотрите на классические примеры — что мы там видим? Компьютеры? Передачу пакетов? Нет блин, мы видим "жирафа", как потомка "млекопитающего", и "грузовой автомобиль", как потомка "транспортного средства".

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

V>Дык, если потомки сложатся в иерархию, то система ломается, когда реализация только в ее корне.

Это можно сделать только сознательно.

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

Невозможно забыть реализовать абстрактный метод. А реализация AcceptVisitor в нетерминальном классе лишена какого либо смысла и может быть сделана только с целью вредительства.

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

AVK>>Я, кажется, прекрасно продемонстрировал твой финт ушами.
K>Какой финт ушами ?



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

K>У меня другой

Это и называется подтасовкой.

AVK>>Зачем? Примеры специфичны для конкретных предметных областей. Например "Проводка бухгалтерской справки". Сильно полегчало?
K>Это не абстракция над предметной областью. Это в предметной области есть само по себе.

Мдя. Это даже не смешно.

AVK>>Ух ты. Ты внедренец, что ли?

K>Сейчас нет.

То есть был. Ясно, больше вопросов не имею.

K>Но это мы уже совсем ушли в сторону.

Это вы ушли.