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

ГВ>>>>Значит, надо смотреть и на эти алгоритмы. Я пока не понимаю, как минимум, почему эти числа надо именно перемножать.
AVK>>>Это долго расписывать.
ГВ>>А ты попробуй.
WH>Если в двух словах то в твоей модели на каждый десериализуемый объект нужно создавать еще пару десятков объектов.
WH>Причем цель жизни каждого из них один раз установить значение свойства.
WH>Это дорого.
WH>Да и не нужно ибо создание + однократное использование твоего объекта не проще чем однократное использование моего.

Трудно сказать. Я так понял, что есть ещё некий промежуточный объект, который, собственно, и скрывает от пользователя различия в интерфейсах Attached и не-Attached.

ГВ>>Ясно. Я пока склоняюсь к тому, что те интерфейсы, который показал WolfHound — это очень низкий уровень в иерархии абстракций. Ergo, надо копать остальные абстракции тоже.
WH>Не надо. Это абсолютно самодостаточная модель.

Если это самодостаточная модель, то откуда рассуждения о недопустимой дороговизне создания дополнительных объектов? Модель существует во вполне конкретном окружении и заточена под вполне определённые задачи и характер использования. Собственно именно это (описание использования и окружения) я и пытаюсь из тебя "вытрясти", поскольку без этого в принципе ничего нельзя сказать о проектировании и [не-]уместности принятых решений.

ГВ>>Дык в том-то и прикол, что для того, чтобы опровергнуть, например, посылки Кирилла нужно расписать всю постановку задачи от и до.
WH>Не нужно. В прочем ты себя послушай... расписать задачу от и до. Да где ты такое видел? Такого не бывает ни где и ни когда. В принципе.

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

WH>Ну разве что сюда опять зайдут программисты софта для АЭС или шатлов

WH>Что касается посылок достаточно посмотреть к чему они приводят... А приводят они к ужасной лапше в которой все завязано на все.
WH>Просто идеи типа дать всем контролам текст и картинку с моей точки зрения является абсолютно не допустимыми при создании чего бы то нибыло.
WH>И не надо тут говорить про пример, затычку, отмазку и тп. Данное решение говорит лучше 1000 слов. Я никогда не позволю себе такое даже в качестве отмашки. Я корее просто пошлю чем изрбражу такое.

WH>Причем мои интерфейсы тут абсолютно не причем.
WH>Они нацелены на совершенно иной уровень абстракции и порядка в системе.

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

WH>А тому что напректировал Кирилл ничето не поможет.
WH>Ибо он действует из совершенно не верных посылок.
WH>И наиболие фатальныя из них это: Система должна быть минимальной.
WH>БРЕД! Эта посылка работает при создании материальных систем ибо там основные затраты это воплощение в железе, камне и тп. Хотя даже тут пока еще работает... ибо чем дальше тем не матереальная составляющея становится все больше и больше.

"Бред", спору нет, это аргумент офигенной силы и сильного колдунства.

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

Ещё одна абстракця? Что такое "чистота"?

WH>Но тут и близко не тот случай.
WH>Сравнивается макаронная архитектура в которой все завязано на все и при попытке добавить то на что в начале создания не закладовались все посыпится. Скажем сплайн лейаут Кирилл не добавит никогда ибо на него не расчитана система. Он просто не влезет в его таблички. Никак.

На самом деле, тут сталкиваются более узкая и более широкая постановки. Только и всего. Вопрос о правомерности сужения задачи Кириллом или о расширении её тобой разрешается на уровне маркетингвого анализа, посему спорить об этом в текущем контексте нет смысла. Вот ответь на вопрос: с чего ты взял, что, допустим, тот же Кирилл столкнётся с необходимостью вводить splain-based layouts? Почему ему не должно хватить "обычных" layout-ов, базирующихся на строчно-колоночном представлении? С другой стороны, сплайны могут потребовать и соответствующей поддержки со стороны контролов (изгибы там всякие и т.п.), а это уже выходит за рамки возможностей стандартных Win32-контролов (comctl32.dll, я имею ввиду). Как, кстати, и за рамки "удобного интерфейса", по крайней мере — на сегодняшний день. Во всяком случае, я был бы рад посмотреть на удобное воплощение сплайн-организованного интерфейса пользователя (я не считаю это невозможным).

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

WH>Разве что ему придется поравить все.

WH>Со слабосвязанной компонентной системой которой в очень широких рамках всеравно с чем работать.
WH>Этой системе всеравно кто и что захочет в нее добавить. Она сожрет любой контрол и любой лейаут.
WH>И для этого не нужно ничего менять. Нужно только написать новый контрол.

WH>Да в первой системе сущьностей и возможно кода на первых этапах меньше.

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

WH>Но с моей точки зрения это плохой путь.
WH>Ибо если уж написал и взял за это деньги то обеспечь сопровождение на должном уровне.
WH>А если не можешь не берись.

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

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

ГВ>>В противном случае получается разговор ни о чём, где одни всё время утыкаются в неполноту информации, а другие утверждают, что её долго и муторно расписывать. Странно это как-то.
WH>Ты что тоже не понимаешь чем win от web отличается и почему за 5 минут на коленке под них общий интерфейс не подвести?

Здесь, вон, других задач хватет: те же сериалайзеры/дизайнеры. ИМХО, их как раз можно за более или менее разумное время описать.

[skip, понятно]

WH>Для тех кто не понял в чем суть повторю еще раз:
WH>1)Отделить от объектов (контролов в частности) то что им знать не нужно.
WH>2)Обеспечить работу абстрактных сериалайзеров и дизайнеров с данной объектоной моделью.

А абстрактные сериалайзеры — они как, совсем абстрактные, или имеют некий собственный интерфейс и/или требования к интерфейсу сериализуемых объектов?

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

ГВ>Трудно сказать. Я так понял, что есть ещё некий промежуточный объект, который, собственно, и скрывает от пользователя различия в интерфейсах Attached и не-Attached.
Вся работа с этими интерфейсам ведется в сериалайзерах и дизайнерах.
Те там где нельзя знать контролы в лицо.
Исключение составляет только PropertyGrid ибо он хочет дескрипторы в своем формате. Хочет. Получит. Жалко чтоли. Ибо переписать PropertyGrid гораздо дороже чем обернуть мои дескрипторы в его.

А при реализации конкретной формочки в которой к конкретным контролам биндятся конкретные данные эти интерфейсы не используются.

ГВ>Если это самодостаточная модель, то откуда рассуждения о недопустимой дороговизне создания дополнительных объектов? Модель существует во вполне конкретном окружении и заточена под вполне определённые задачи и характер использования. Собственно именно это (описание использования и окружения) я и пытаюсь из тебя "вытрясти", поскольку без этого в принципе ничего нельзя сказать о проектировании и [не-]уместности принятых решений.
От туда что это модель метаданных.
Заводить на каждый объект еще несколько десятков только ради того чтобы один раз передать на один параметер меньше...
Ты сам то оценил все прелести этого подхода?

ГВ>Хотя бы в приблизительных набросках обычно можно. Так, что будут ясны основные ограничения, откуда они берутся и т.д, и т.п. Пока что задача вытряхивается по кусочкам.
В приблизительных я описывал не раз.

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

ГВ>"Бред", спору нет, это аргумент офигенной силы и сильного колдунства.
Все ясно.
По сути сказать нечего.

ГВ>Ещё одна абстракця? Что такое "чистота"?
Это когда в решении есть только то что нужно. Не больше и не меньше.
В решении Кирилла куча паразитных свойств и связей.
Нафига едиту картина? Ну нафига? Можешь сказать?
Зачем эта грязь на ровном месте?

ГВ>На самом деле, тут сталкиваются более узкая и более широкая постановки. Только и всего.
Нет.
Тут сталкиваются подходы:

1)Запихнем все в одну кучу и какимто чудом заставим работать.
Вполне себе подход если нужно по быстрому срубить бабла и свалить.

2)Разложем все по полочкам и все само заработает.
А при этом подходе можно долго развивать сложную систему.
Причем проблем с реализацией того о чем и не подозревали не будет.

ГВ>Вопрос о правомерности сужения задачи Кириллом или о расширении её тобой разрешается на уровне маркетингвого анализа, посему спорить об этом в текущем контексте нет смысла. Вот ответь на вопрос: с чего ты взял, что, допустим, тот же Кирилл столкнётся с необходимостью вводить splain-based layouts? Почему ему не должно хватить "обычных" layout-ов, базирующихся на строчно-колоночном представлении? С другой стороны, сплайны могут потребовать и соответствующей поддержки со стороны контролов (изгибы там всякие и т.п.), а это уже выходит за рамки возможностей стандартных Win32-контролов (comctl32.dll, я имею ввиду). Как, кстати, и за рамки "удобного интерфейса", по крайней мере — на сегодняшний день. Во всяком случае, я был бы рад посмотреть на удобное воплощение сплайн-организованного интерфейса пользователя (я не считаю это невозможным).
Это лейаут исключительно как пример того что в модель Кирилла не впишется.
В прочем в нее вобще ничего не впишется.

А вот в мою модель впишется.
Даже с учетом искривления контролов если оно конечно комуто будет нужно. (Хотя вероятность существует http://fotki.yandex.ru/users/romashka-smile88/view/5066/ )
Да стандартный рендер Win32 придется послать и использовать что-то типа http://antigrain.com/ или что-то другое. Тут нужны исследования.
Но мне будет нужно переписать только рендер и реализацию основных контролов, а их в моем случае не много. Все составные автоматически заработают.
Вся написанная логика будет рабоать как работала.

Кириллу придется переписать все.

ГВ>Повторюсь ещё раз. Кирилл не ставит задачу построения компонентной архитектуры для абстрактных контролов, вместо этого "поджимая" исходную задачу до определённого набора компонентов. Ты — наоборот, приводишь в качестве примера интерфейсы компнентно инфрастуктуры, попрождённые из другой задачи, а потом орёшь "Бред!" в адрес того, кто сужает исходную задачу.
ГВ>Хотя на самом деле обе постановки имеют примерно одинаковое право на существование.
Не имеют.
Задача построение слобосвязанной архитектуры встает автоматически когда нужно написать что-то большее чем "Привет мир!".
Просто по умолчанию.
Нет никакого поджимания/расширения.
Упорядочивание и уменьшение связанности системы это одна из основных задач иначе долгоживущею систему не сделать.
Вернее ее создание и развитие будет требовать просто огромных ресурсов.
Ибо если систему не упорядочить сразу и не пресекать все попытки этот порядок нарушить то энтропия в системе будет расти просто с чудовищьной скоростью.
А навести порядок там где изначально полный бардк не реально.

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

ГВ>Интересно сравнить два подхода на примерно одинаковых задачах в примерно одинаковой системе ограничений. Правда, боюсь, что сопоставимые задачи тут могут появиться только на самом верхнем уровне, но мало ли, а вдруг, да и получится?
А я и так знаю что будет в подходе Кирилла при поддержке и добавлении не предусмотренных изначально функций.
Ибо я видил много таких "минимальных решений" со всеми одна и таже фигня.
Пока находишься в рамках решения все работает но шаг в сторону и все посыпалось со словами "давайте все перепишем..."
Вот только после переписывания получается тоже самое.

ГВ>Здесь, вон, других задач хватет: те же сериалайзеры/дизайнеры. ИМХО, их как раз можно за более или менее разумное время описать.
Сериалайзеры при наличии полной метаинформации штука тривиальная. Тупой рекурсивный обход дерева. Можно расширить до графа но мне это не требовалось.
А у дизайнеров основные заморочки не с метаданными, а с самим дизайнером.

ГВ>А абстрактные сериалайзеры — они как, совсем абстрактные, или имеют некий собственный интерфейс и/или требования к интерфейсу сериализуемых объектов?
Им нужны только метаданные.
Те на вход поступает IDomain и корневой объект.
Дальше

IType type = domain.GetType(obj.GetType());

Теперь мы знаем про объект все что нам нужно.

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

ГВ>>>Значит, надо смотреть и на эти алгоритмы. Я пока не понимаю, как минимум, почему эти числа надо именно перемножать.
AVK>>Это долго расписывать.

ГВ>А ты попробуй.

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

ГВ>Ясно. Я пока склоняюсь к тому, что те интерфейсы, который показал WolfHound — это очень низкий уровень в иерархии абстракций. Ergo, надо копать остальные абстракции тоже.

Зачем?

ГВ>Дык в том-то и прикол, что для того, чтобы опровергнуть, например, посылки Кирилла нужно расписать всю постановку задачи от и до.

Это никто читать все равноне будет.

ГВ>, а другие утверждают, что её долго и муторно расписывать. Странно это как-то.

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

ГВ>>>А куда передаётся owner?
AVK>>В специальный объект, аналог PropertyDescriptor.

ГВ>А назначение этого объекта?

То же, что и у PropertyDescriptor.

ГВ>То есть, фактически, это такой сфероконь?

Пример.

ГВ> А мы-то здесь копья ломаем... Великолепно, брависсимо!

Я вобще не знаю что ты тут хочкшь добиться.

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

WH>На любом приличном языке это будет выглядить так (с точностью до синтаксиса):
Вы ушли от ответа на вопрос. Косвенным образом, это подтверждает мою правоту.

WH>Остальное детали реализации не имеющие никакого значения на данном уровне абстракции.
Да, но эту реализацию тоже придется писать. И тут либо нужно переводить числа в позиционную систему с фиксированным основанием, либо писать алгоритм умножения для римских цифр. Думаю, нетрудно догадаться, что будет проще.

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

WH>Только нужно понимать что сложность не устраняется, а скрывается.
WH>Ее просто выносят на уровень собственно модели.
Сложность никуда не выносят. Ее устраняют при помощи модели.

WH>А как ты думаешь почему римская система появилась раньше позиционной?
Не раньше. Например, вавилонская система счисления, которая появилась раньше римской, тоже была позиционной. Только по основанию 60. Именно по этой причине в часу 60 минут, а в минуте — 60 секунд.

WH>Да все просто.
WH>У нее абстракция нулевая.
Что такое "нулевая абстракция"?

WH>Каждая цифра обозначает конкретное число.
WH>Не больше и не меньше.
Мягко говоря, это не так. В римской системе зарезервированы знаки для чисел: 1 (I), 5 (V), 10 (X), 50 (L), 100 (C), 1000 (M — что ли?). Остальные числа получаются путем добавления цифр слева или справа. В некотором роде, римскую систему счисления тоже можно назвать позиционной.

WH>Модель проста как палка.
Снова неправда. Она гораздо удобнее греческой, в которой для обозначения чисел использовались буквы всего греческого алфавита.

WH>А в случае с позиционной нужно понимать что цифры не сами по себе, а зависят от позиции.
WH>Те сложность умножения ни куда не делась.
Вы бы все-таки перемножили приведенные числа и в римской системе счисления, и в десятичной системе счисления, а потом бы сравнили.

WH>А если посмотреть на тот код что я привел выше то абстракция поднята еще выше.
Это не абстракция, а прикол.

WH>Там просто введено обозначение умножения чисел и все.
WH>Ни какого конкретного алгоритма там нет.
WH>Он спрятан внутри класса RomanNumber.
Его все равно придется реализовывать либо одним (через позиционную систему с фиксированным основанием), либо другим (через написание алгоритмов для умножения римских чисел) способом.

WH>А как уж он реализован это другой вопрос.
Тем не менее, он возникает.

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

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

WH>Конвеер хорошо решает только массовое штампование совершенно одинаковых чайников по один раз нарисованному чертежу.
WH>Однако в случае с программой нет никакого массового штампования. (Вернее оно есть но оно давно и полность автоматизировано. Компилятор + утилита copy == сколько угодно копий какой угодно программы. Чайникам такое и не снилось.)
Конвеер позволяет унифицировать создание разных изделий за счет выявления одинаковых операций, которые стандартизируются.

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

WH>Нарпмер есть модели: колесо, винт + гайка, блок,...
WH>Создание таких моделей автоматизировать невозможно.
Тем не менее, на предприятиях задача автоматизации создания таких объектов решена.

WH>Проблема в том что в случае с программами пространство на котором приходится работать неизмеримо больше и хуже того вариантов которые хоть както раблтают также не измеримо больше.
WH>Те если в случае с техникой машина на квадратных колесах никуда не поедет то в случае с программой еще не такое ездит... взять к примеру С++... урод уродом, а ездит.
Это Вы к чему?

WH>Те по твоему каждую кнопку должны делать такое колличество народу?
Необязательно. Разделение между операциями можно произвести не только в пространстве, но и во времени. В предельном случае, контрол делает один человек, но с соблюдением определенной технологии. Операции следуют друг за другом в определенной последовательности. А лучше — когда они группируются в блоки (батчи), т.е. в определенный момент времени выполняются одинаковые операции сразу для группы контролов.

Хотя, зачем я все это объясняю. Вы же тут писали, что для Вас это все очевидно и Вы делаете все на автопилоте.

WH>А вот задействовать на разроботке кнопки больше одного человека просто не имеет смысла ибо объем работ там практически никакой. Они дольше объяснять друго другу будут что нужно сделать.
WH>Да обсудить и утвердить общею концепцию системы нужно. Но проектировать толпой народа кнопку... это мягко говоря перебор.
Тут Вы лукавите — как-то вдруг забыли про сложные контролы.

КЛ>>Клиенту нужна работающая программа за минимальные деньги, а не особый контрол.
WH>1)Чистые абстракции позволяют поднимать качество конечного решения, уменьшать время и себистоимость разработки.
"Чистые" абстракции еще надо реализовать. Если Вы так любите "чистые" абстракции, то почему бы Вам не написать интерфейс Программа и не сделать его несколько реализаций:
Программа 1 — первая версия программы (пишем все с нуля)
Программа 2 — вторая версия программы (опять пишем все с нуля)
Программа 3 — третья версия программы (и еще раз пишем все с нуля)
и т.д.?

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

WH>3)Если клиент за небольшую дополнительную плату получит еще и фенечку которая ему нравится то он будет счеслив.
Да, но если он впоследствии узнает, что из-за этой фенечки код полиморфен, и что тултипы к форме добавляются кнопочкой "Cancel", а обработчик кнопки "OK" зависит от узорного бордюра, который выставляется при вводе "Программер акбар!" в третьем снизу редакторе, который в основном имеет флаг hidden, который сбрасывается при пятом нажатии на "Cancel", но еще перед этим должна быть трижды нажата клавиша Esc с интервалом между нажатиями не меньше 1-ой секунды, то он, мягко говоря, пошлет эту фенечку ко всем чертям.

КЛ>>Заметьте, что Вы опять пытаетесь перевести конструктивный разговор в русло разборок торговцев на базаре. Я же не называю Ваш код "мутантским" или что-то типа этого.
WH>Я просто называю вещи своими именами. Может быть временами это не политкорректно но за то никакого лицемерия.
Вы просто грубо разговариваете.

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

WH>Каждый контрол делает то что от него требуется. Не больше и не меньше.
И в жестком виде дублирует код большинства других контролов.

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

КЛ>>Предлагаю заменить этот термин на "контрол, который проявляет свойства дерева и грида".
WH>Хоть горшком назови.
Вы опять грубите. К тому же демонстрируете свое неумение абстрагироваться от конкретных названий и выделять главное.

WH>>>Virtual означает то что он не требует чтобы были подняты все данные. Ибо данных может быть очень много.
КЛ>>"...способный подгружать данные определенными порциями по мере необходимости".
WH>Нет. Данные могут быть в массиве, в базе, генериться на лету,...
У меня где-то сказано про базу?

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

КЛ>Сложность никуда не выносят. Ее устраняют при помощи модели.
Нет. Сложность устранить нельзя.
Ее можно перенести на другой уровень но не устранить.
Модель римских чисел примитивна.
Там есть только конкретные числа.
В случае с позиционной системой появилось понятие позиции цифры в числе.
Те добавили в модель новую концепцию.
Тем самым усложнили модель.

КЛ>Мягко говоря, это не так. В римской системе зарезервированы знаки для чисел: 1 (I), 5 (V), 10 (X), 50 (L), 100 (C), 1000 (M — что ли?). Остальные числа получаются путем добавления цифр слева или справа. В некотором роде, римскую систему счисления тоже можно назвать позиционной.
Это не существенные детали.
Совершенно не важно записано число одной закорючкой или несколькими.
Сущьность системы от это не меняется вобще.

Не путай модель и то как выглядят конкретные числа.

КЛ>Его все равно придется реализовывать либо одним (через позиционную систему с фиксированным основанием), либо другим (через написание алгоритмов для умножения римских чисел) способом.
Это не важно.
Относительная стоимость реализации тем ниже чем чаще она используется.

WH>>А как уж он реализован это другой вопрос.
КЛ>Тем не менее, он возникает.
Если оно написано один раз, имеет простой, четкий, понятный интерфейс и работает то нет.

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

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

КЛ>Это не так. Большинство программ в определенной области (и даже в разных предметных областях) похожи.
Похожи но не идентичны.
Это значит что можно взять чертеж одого чайника и подрехтовать под другой.

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

WH>>Нарпмер есть модели: колесо, винт + гайка, блок,...
WH>>Создание таких моделей автоматизировать невозможно.
КЛ>Тем не менее, на предприятиях задача автоматизации создания таких объектов решена.
Ты не понял.
Я говорил о принципе.
Те принцип колеса это фундамент, а создание конкретного колеса это уже детали.

WH>>Те если в случае с техникой машина на квадратных колесах никуда не поедет то в случае с программой еще не такое ездит... взять к примеру С++... урод уродом, а ездит.
КЛ>Это Вы к чему?
К тому что при создании программы нет столь очевидной разници как при создании предметов материального мира.

WH>>Да обсудить и утвердить общею концепцию системы нужно. Но проектировать толпой народа кнопку... это мягко говоря перебор.
КЛ>Тут Вы лукавите — как-то вдруг забыли про сложные контролы.
А именно? Самый сложный контрол это VirtualTreeGrid ничего сложеней нет.
Все остальное очень просто.
Если ты конечно не собрался MSWord написать.

Составные контролы совсем тривиальны ибо их создание полностью декларативно.

КЛ>"Чистые" абстракции еще надо реализовать. Если Вы так любите "чистые" абстракции, то почему бы Вам не написать интерфейс Программа и не сделать его несколько реализаций:
КЛ>Программа 1 — первая версия программы (пишем все с нуля)
КЛ>Программа 2 — вторая версия программы (опять пишем все с нуля)
КЛ>Программа 3 — третья версия программы (и еще раз пишем все с нуля)
КЛ>и т.д.?
Именно так я и делаю.
Вот интерфейс:

int main(int argc, char** argv)

Только саму программу дроблю на болие мелкие абстракции.
Ну и некоторые решения по ходу дела превращаются в библиотеки.
И отваливаются от основной программы.
А библиотеки уже используются в других программах.

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

Короче получилось две базовых абстракции:

1)Поток. Причем поток чего угодно. В том числе поток потоков.
2)Фильтр. Преобразует один поток в другой. В том числе поток в поток потоков и обратно.

Решение получилось таким:

1)Превращаем файлик в поток байт.
2)Превращаем (тот поток что получился на предыдущем шаге) в поток строк.

3)При помощи регулярного выражения превращаем в поток кортежей. (time, ip)
4)Группируем соседние кортежи у которых поле time одинаковое в потоки. Получаем поток потоков.
5..)Превращаем поток потоков в поток потоков. (вобще этой ФВП пофигу что во что превращать)
5.1)Считаем колличество одинаковых элементов в потоке. Получаем поток кортежей (count, (time, ip))
5.2)Оставляем кортежи у которых count > 100
5.3)Сортируем по полю count
5.4)Превращаем кортежи в строки (time count ip)
6)Превращаем поток потоков в поток. Просто переливаем содержимое вложенных потоков в выходной поток.

7)Превращаем в поток байт.
8)Записываем поток байт в файлик.

Этот алгоритм был переведен в код строка в строку.
Вернее он прямо там и был написан. Но не на русском, а на немерле

Фильтры ессно параметризуются анонимными функциями.

Причем стадии 1, 2, 7 и 8 спрятаны внутри функций высшего порядка. (1 и 8 в одной. 2 и 7 в другой) Болие того стадии 1 и 8 происходят в отдельных потоках таким образом мы распаралеливаем винт и обработку.

Болие того модель такова что каждый фильтр может жить в отдельном потоке.
Таким образом можно получить преимущества от многоядерности. (На этом примере не интересно. Но если добавить компрессию/декомпрессию и/или шифровку/расшифровку то...)
Но я этого пока не делал.

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

А ты можешь также просто написать алгоритм который также хорошо паралелится?
Причем паралелится совершенно прозрачно для клиентского кода.

Вот сила абстракций.

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

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

Скажем я формализовал метаданные.
Тем самым упростил и их и то что их использует.

Ибо при всем жилании через абстрактные интерфейсы детали реализации не пробъются.
А значит не будет паразитных связий.

КЛ>Да, но если он впоследствии узнает, что из-за этой фенечки код полиморфен, и что тултипы к форме добавляются кнопочкой "Cancel", а обработчик кнопки "OK" зависит от узорного бордюра, который выставляется при вводе "Программер акбар!" в третьем снизу редакторе, который в основном имеет флаг hidden, который сбрасывается при пятом нажатии на "Cancel", но еще перед этим должна быть трижды нажата клавиша Esc с интервалом между нажатиями не меньше 1-ой секунды, то он, мягко говоря, пошлет эту фенечку ко всем чертям.
Если ты не понимаешь как работают полиморфные программы и каким образом делать так чтобы не получалось того что ты написал то это твоя проблема, а не проблема полиморфных программ.

КЛ>А возможность написания контрола, который добавляет тултипы ко всем другим контролам на форме — это не лишняя связь?
Нет. Лишняя связь это добавление тултипов непосредственно в контролы.

КЛ>Которая, кстати, нигде явно не задекларирована.
Как нигде?
1)В описании объектной модели.
2)В описании конкретных контролов.

КЛ>И в жестком виде дублирует код большинства других контролов.
Нет дублирования.
Ни буквы.
Те вобще.
На то код и полиморфный.

КЛ>Если контролам не нужно знать, кто их размещает, то почему Вы эти свойства приаттачиваете к ним? Уж либо они не знают (и тогда свойства не прикрепляются), либо знают (и тогда свойства прикрепляются).
Эти свойства сами по себе смысла не имеют.

Они имеют смысл только когда они привязаны к конктретному контролу.
Те в случае с GridLayout свойства Col и Row без привязки к конкретному контролу не имеют смысла.
Но контролу о них знать не нужно ибо в разных ситуациях к нему могут быть привязыны разные свойства.
Ибо если мы этот контрол перетащим скажем на PositionLayout то свойства Col и Row потеряют смысл но понадобятся свойства Top, Left, Bottom, Right.

Тоже самое касается любых других присоедененных свойств и событий.

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

ГВ>>>>Значит, надо смотреть и на эти алгоритмы. Я пока не понимаю, как минимум, почему эти числа надо именно перемножать.
AVK>>>Это долго расписывать.

ГВ>>А ты попробуй.
AVK>Не буду. Во-первых лень, во-вторых это коммерческая тайна.

Складно. Просто. Легко запомнить. (c)

ГВ>>Ясно. Я пока склоняюсь к тому, что те интерфейсы, который показал WolfHound — это очень низкий уровень в иерархии абстракций. Ergo, надо копать остальные абстракции тоже.
AVK>Зачем?

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

ГВ>>Дык в том-то и прикол, что для того, чтобы опровергнуть, например, посылки Кирилла нужно расписать всю постановку задачи от и до.
AVK>Это никто читать все равноне будет.

Я буду. Ибо я этот вопрос и задал.

ГВ>>, а другие утверждают, что её долго и муторно расписывать. Странно это как-то.
AVK>А не надо воспринимать это как реальный код, надо воспринимать как пример.



AVK>Пример размером в мегабайт исходников это нонсенс.

Весь мегабайт не нужен. Достаточно нескольких простых описаний.

AVK>Если тебе все же хочется увидеть реальный код — WPF с рефлектором в руки и вперед, там попроще модель конечно, но довольно похоже на описываемую.

Ясно. Одна беда: о действительной постановке задачи для WPF мы можем только догадываться. И как ты понимаешь, доказательства по аналогии... Далее по тексту.

ГВ>>>>А куда передаётся owner?
AVK>>>В специальный объект, аналог PropertyDescriptor.
ГВ>>А назначение этого объекта?
AVK>То же, что и у PropertyDescriptor.

Понятно.

ГВ>>То есть, фактически, это такой сфероконь?
AVK>Пример.

Это сфероконический пример, пока не выяснится контекст, к которому он реально относится.

ГВ>> А мы-то здесь копья ломаем... Великолепно, брависсимо!
AVK>Я вобще не знаю что ты тут хочкшь добиться.

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

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

ГВ>>>Ясно. Я пока склоняюсь к тому, что те интерфейсы, который показал WolfHound — это очень низкий уровень в иерархии абстракций. Ergo, надо копать остальные абстракции тоже.
AVK>>Зачем?

ГВ>Объясню ещё раз, другими словами. Потому что без указаний на конкретные решаемые задачи и конкретные API контрпример WolfHound-а выглядит не лучше, чем высосанный из пальца. Ничем не лучше.

Это голословное заявление.

ГВ> А в сумме с ворохом ругательств — вообще как чёрт-те что. Я это буду повторять ровно столько, сколько потребуется.

А толку то.

AVK>>Пример размером в мегабайт исходников это нонсенс.

ГВ>Весь мегабайт не нужен. Достаточно нескольких простых описаний.

Описаний чего? Ты сам точно не знаешь, чего ты хочешь, но чего то требуешь.

AVK>>Если тебе все же хочется увидеть реальный код — WPF с рефлектором в руки и вперед, там попроще модель конечно, но довольно похоже на описываемую.

ГВ>Ясно. Одна беда: о действительной постановке задачи для WPF мы можем только догадываться.

Ха, так оно в любом проекте так — постановка задачи расплывчата, да еще, пакость такая, норовит со временем измениться. Архитектор, который настаивает на детальном и окончательном наборе требований до проектирования в обязательном порядке, столь же ценен, как, скажем, юзабилист, который проектирует интерфейсы, практически нереализуемые на выбранной UI платформе.

ГВ> И как ты понимаешь, доказательства по аналогии... Далее по тексту.

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

ГВ>>>То есть, фактически, это такой сфероконь?
AVK>>Пример.

ГВ>Это сфероконический пример, пока не выяснится контекст, к которому он реально относится.

Контекст? Что такое в твоем понимании контекст в данном случае?

ГВ>Для начала — внятных и полных ответов на поставленные вопросы

Для этого тебе придется задать внятные и понятные конкретные вопросы.

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

Увы, с коммерческой тайной я ничего поделать не могу.

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

ГВ>>Трудно сказать. Я так понял, что есть ещё некий промежуточный объект, который, собственно, и скрывает от пользователя различия в интерфейсах Attached и не-Attached.
WH>Вся работа с этими интерфейсам ведется в сериалайзерах и дизайнерах.

Как я понимаю — иначе эти интерфейсы не используются. Правильно?

WH>Те там где нельзя знать контролы в лицо.
WH>Исключение составляет только PropertyGrid ибо он хочет дескрипторы в своем формате. Хочет. Получит. Жалко чтоли. Ибо переписать PropertyGrid гораздо дороже чем обернуть мои дескрипторы в его.

Понятно. То есть в одном, как минимум, случае эти интерфейсы адаптируются неким PropertyDescriptorAnalog.

WH>А при реализации конкретной формочки в которой к конкретным контролам биндятся конкретные данные эти интерфейсы не используются.

Иными словами, назначение этих интерфейсов ограничивается задачами дизайнеров и сериализаторов формочек? Правильно?

ГВ>>Если это самодостаточная модель, то откуда рассуждения о недопустимой дороговизне создания дополнительных объектов? Модель существует во вполне конкретном окружении и заточена под вполне определённые задачи и характер использования. Собственно именно это (описание использования и окружения) я и пытаюсь из тебя "вытрясти", поскольку без этого в принципе ничего нельзя сказать о проектировании и [не-]уместности принятых решений.
WH>От туда что это модель метаданных.

Может, хватит уже метаться от одной абстракции к другой? "Недопустимая дороговизна" может появиться только тогда, когда у нас есть некий оценочный критерий. Сам по себе оценочный критерий это не имманентная сущность вселенной, а следствие вполне конкретных use case. Я понятно выражаюсь? Ergo, если говоришь о [не]допустимости оценки, то проясни критерии, по которым эта оценка накладывается, а прояснив критерии — объясни и то, откуда они взялись.

WH>Заводить на каждый объект еще несколько десятков только ради того чтобы один раз передать на один параметер меньше...
WH>Ты сам то оценил все прелести этого подхода?

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

ГВ>>Хотя бы в приблизительных набросках обычно можно. Так, что будут ясны основные ограничения, откуда они берутся и т.д, и т.п. Пока что задача вытряхивается по кусочкам.
WH>В приблизительных я описывал не раз.

Они оказались недостаточными, чтобы объяснить те самые основные основные ограничения. Пока ещё не выяснены вопросы относительно сущностей "экземпляр свойства" и "описание свойства". Собственно, вопросы такие: где они хранятся и как извлекаются. Чуть раньше этот вопрос был поднят, но там мы отвлеклись.

ГВ>>Решение Кирилла иллюстрирует прежде всего подход. Соответственно, коль скоро дело доходит до сравнения результатов применения подходов, то нужно брать и сопоставимые задачи.
WH>Знаем мы этот подход... Навоять на коленке абы как и свалить...
WH>А потом пусть другие разбираеются нафига едиту картинка или картинке текст.
WH>Кстати я на этот простейший вопрос так и не получил ответа.
WH>А там еще масса подобных этому вопросов.

Я что-то не понятно написал? Ну, повторюсь. Задачи должны быть сопоставимыми. Иначе обусждение выльется в обмен колкостями (что и имеем).

ГВ>>"Бред", спору нет, это аргумент офигенной силы и сильного колдунства.
WH>Все ясно.
WH>По сути сказать нечего.

Отвечаю по сути: это НЕ бред.

ГВ>>Ещё одна абстракця? Что такое "чистота"?
WH>Это когда в решении есть только то что нужно. Не больше и не меньше.
WH>В решении Кирилла куча паразитных свойств и связей.
WH>Нафига едиту картина? Ну нафига? Можешь сказать?
WH>Зачем эта грязь на ровном месте?

Я вот, могу у тебя спросить с аналогичной пиитикой: "нафига объекту не его свойства"? Пока что не буду. Так что, давай без риторических восклицаний.

ГВ>>На самом деле, тут сталкиваются более узкая и более широкая постановки. Только и всего.
WH>Нет.
WH>Тут сталкиваются подходы:

WH>1)Запихнем все в одну кучу и какимто чудом заставим работать.
WH>Вполне себе подход если нужно по быстрому срубить бабла и свалить.

WH>2)Разложем все по полочкам и все само заработает.
WH>А при этом подходе можно долго развивать сложную систему.
WH>Причем проблем с реализацией того о чем и не подозревали не будет.

С тем, о чём не подозревали обычно возникают те проблемы, о которых и не подозревали.

ГВ>>Вопрос о правомерности сужения задачи Кириллом [...] Во всяком случае, я был бы рад посмотреть на удобное воплощение сплайн-организованного интерфейса пользователя (я не считаю это невозможным).
WH>Это лейаут исключительно как пример того что в модель Кирилла не впишется.
WH>В прочем в нее вобще ничего не впишется.

Ты уж уточни: это очередной сфероконоь или имеется хоть один реальный случай использования splain-based layout? Пока что я склоняюсь к тому, что это некий гипотетический случай.

WH>А вот в мою модель впишется.
WH>Даже с учетом искривления контролов если оно конечно комуто будет нужно. (Хотя вероятность существует http://fotki.yandex.ru/users/romashka-smile88/view/5066/ )

Кстати, а номер дома-то написан в обычном плоском виде. Да и дверь — прямоугольная. Оба артефакта — слева внизу под дорожным знаком. А остальное — битмап бэкграундный. Так что, не катит пример.

WH>Да стандартный рендер Win32 придется послать и использовать что-то типа http://antigrain.com/ или что-то другое. Тут нужны исследования.

Так, ясно. Опять слышу тяжёлые перекаты копыт сфероконя.

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

Если упомянутая логика не использует специфику реализации контролов, то это очевидно.

WH>Кириллу придется переписать все.

Пока что это спорный вопрос. Как ты понимаешь, от многократного повторения этого тезиса истинность его не растёт.

ГВ>>Повторюсь ещё раз. Кирилл не ставит задачу построения компонентной архитектуры для абстрактных контролов, вместо этого "поджимая" исходную задачу до определённого набора компонентов. Ты — наоборот, приводишь в качестве примера интерфейсы компнентно инфрастуктуры, попрождённые из другой задачи, а потом орёшь "Бред!" в адрес того, кто сужает исходную задачу.
ГВ>>Хотя на самом деле обе постановки имеют примерно одинаковое право на существование.
WH>Не имеют.
WH>Задача построение слобосвязанной архитектуры встает автоматически когда нужно написать что-то большее чем "Привет мир!".

Автоматически только машины работают.

WH>Просто по умолчанию.
WH>Нет никакого поджимания/расширения.

На самом деле, мощности множеств контролов, покрываемых задачей в постановке Кирилла и в твоей примерно одинаковы. И там, и там придётся что-то притягивать за уши. В твоём случае — реализацию API свойств, в случае Кирилла — картинку к edit. Но фактически подвязать можно будет почти любой контрол и туда, и туда. Имеют место просто разные API подключения.

Но! Имеется разница в самом наборе свойств. Если Кирилл явно его ограничивает, то ты такое ограничение не вводишь. Правда, при этом Кирилл сразу же определяет и конкретные способы использования этих свойств, а ты — нет. Вернее, у тебя ограничения другого характера, например, Event отличается от Property. Отсюда и мои рассуждения о "поджимании/расширении" задачи.

WH>Упорядочивание и уменьшение связанности системы это одна из основных задач иначе долгоживущею систему не сделать.
WH>Вернее ее создание и развитие будет требовать просто огромных ресурсов.
WH>Ибо если систему не упорядочить сразу и не пресекать все попытки этот порядок нарушить то энтропия в системе будет расти просто с чудовищьной скоростью.
WH>А навести порядок там где изначально полный бардк не реально.

Очень хорошо. Я это слышал ещё до того, как компонентные архитектуры стали общим местом. Бардака с тех пор меньше не стало. Вот же, зараза!

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

Знаешь, в чём парадокс? В том, что для того, чтобы сериалайзеры и дизйнеры заработали с тем, что они и "в глаза не знают", нужно только, чтобы это самое незнакомое чудище содержало соответствующий API, с которым прекрасно знакомы сериалайзеры и дизайнеры.

ГВ>>Интересно сравнить два подхода на примерно одинаковых задачах в примерно одинаковой системе ограничений. Правда, боюсь, что сопоставимые задачи тут могут появиться только на самом верхнем уровне, но мало ли, а вдруг, да и получится?
WH>А я и так знаю что будет в подходе Кирилла при поддержке и добавлении не предусмотренных изначально функций.
WH>Ибо я видил много таких "минимальных решений" со всеми одна и таже фигня.
WH>Пока находишься в рамках решения все работает но шаг в сторону и все посыпалось со словами "давайте все перепишем..."
WH>Вот только после переписывания получается тоже самое.

Такое происходит с любым дизайном. Абсолютно. Исключений нет. Если изменились требования, предъявляемые к конкретной программе, эта программа модифицируется. Если изменятся требоваия к самой компонентной инфраструктуре, ты тоже будешь её [до|пере]писывать, никуда не денешься.

ГВ>>Здесь, вон, других задач хватет: те же сериалайзеры/дизайнеры. ИМХО, их как раз можно за более или менее разумное время описать.
WH>Сериалайзеры при наличии полной метаинформации штука тривиальная. Тупой рекурсивный обход дерева. Можно расширить до графа но мне это не требовалось.
WH>А у дизайнеров основные заморочки не с метаданными, а с самим дизайнером.

О! Уже теплее.

ГВ>>А абстрактные сериалайзеры — они как, совсем абстрактные, или имеют некий собственный интерфейс и/или требования к интерфейсу сериализуемых объектов?
WH>Им нужны только метаданные.
WH>Те на вход поступает IDomain и корневой объект.
WH>Дальше
WH>

WH>IType type = domain.GetType(obj.GetType());
WH>

WH>Теперь мы знаем про объект все что нам нужно.

О! Ещё теплее. А дальше что происходит?

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

ГВ>>Для начала — внятных и полных ответов на поставленные вопросы
AVK>Для этого тебе придется задать внятные и понятные конкретные вопросы.

Я хочу увидеть sequence diagram а) сериализации, б) загрузки контрола редактором.

Подойдут и словесные аналоги.

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

AVK>>>Пример размером в мегабайт исходников это нонсенс.
ГВ>>Весь мегабайт не нужен. Достаточно нескольких простых описаний.
AVK>Описаний чего? Ты сам точно не знаешь, чего ты хочешь, но чего то требуешь.

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

ГВ>> И как ты понимаешь, доказательства по аналогии... Далее по тексту.
AVK>Это не доказательства. Это пример такой архитектуры в железе.

WPF — это Windows Presentation Foundation?

ГВ>>Это сфероконический пример, пока не выяснится контекст, к которому он реально относится.
AVK>Контекст? Что такое в твоем понимании контекст в данном случае?

Это всё, что непосредственно взаимодействует с показанными интерфейсами. Плюс требования, плюс... Не знаю, что ещё может потребоваться, а выдумывать не буду.

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

ГВ>Как я понимаю — иначе эти интерфейсы не используются. Правильно?
Эти интерфейсы нужны там где нужны метаданные.
Если метаданные не нужны не нужны и эти интерфейсы.

ГВ>Понятно. То есть в одном, как минимум, случае эти интерфейсы адаптируются неким PropertyDescriptorAnalog.
Нет. Просто создаются наследники PropertyDescriptor ибо PropertyGrid'у нужны именно они.

ГВ>Иными словами, назначение этих интерфейсов ограничивается задачами дизайнеров и сериализаторов формочек? Правильно?
В общем случае нет.

ГВ>Может, хватит уже метаться от одной абстракции к другой? "Недопустимая дороговизна" может появиться только тогда, когда у нас есть некий оценочный критерий. Сам по себе оценочный критерий это не имманентная сущность вселенной, а следствие вполне конкретных use case. Я понятно выражаюсь? Ergo, если говоришь о [не]допустимости оценки, то проясни критерии, по которым эта оценка накладывается, а прояснив критерии — объясни и то, откуда они взялись.
А может хватит дурочку включать?
Что и так не ясно что создание тысячь объектов на пустом месте в операциях скорость которых критична глупо?

ГВ>Они оказались недостаточными, чтобы объяснить те самые основные основные ограничения. Пока ещё не выяснены вопросы относительно сущностей "экземпляр свойства" и "описание свойства". Собственно, вопросы такие: где они хранятся и как извлекаются. Чуть раньше этот вопрос был поднят, но там мы отвлеклись.
Ты про что именно?
Если про экземпляры классов реализующие IProperty и IAttachedProperty то создаются они при старте приложения и хранятся внутри экземпляра класса реализующего IType

ГВ>Я что-то не понятно написал? Ну, повторюсь. Задачи должны быть сопоставимыми. Иначе обусждение выльется в обмен колкостями (что и имеем).
Кикие бы задачи не были то что изобрел Кирилл годится только на конкурс по обфускации программ.

ГВ> Отвечаю по сути: это НЕ бред.
Те минимизация кода ценой введения массы паразитных связей не бред?

ГВ>Я вот, могу у тебя спросить с аналогичной пиитикой: "нафига объекту не его свойства"? Пока что не буду. Так что, давай без риторических восклицаний.
Я в отличии от тебя могу ответить на этот вопрос.

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

ГВ>Ты уж уточни: это очередной сфероконоь или имеется хоть один реальный случай использования splain-based layout? Пока что я склоняюсь к тому, что это некий гипотетический случай.
А оно имеет значение?
На его месте может оказаться любой другой лейаут.
Которому нужны данные отличные от того на что заложился Кирилл.

WH>>Да стандартный рендер Win32 придется послать и использовать что-то типа http://antigrain.com/ или что-то другое. Тут нужны исследования.
ГВ>Так, ясно. Опять слышу тяжёлые перекаты копыт сфероконя.
Чего простите?
Просили искривление контролов. Получите новый рендер ибо тот что в винде так не умеет.

ГВ>Автоматически только машины работают.
Какое мудрое обобщение о великий гуру.

ГВ>На самом деле, мощности множеств контролов, покрываемых задачей в постановке Кирилла и в твоей примерно одинаковы. И там, и там придётся что-то притягивать за уши. В твоём случае — реализацию API свойств, в случае Кирилла — картинку к edit. Но фактически подвязать можно будет почти любой контрол и туда, и туда. Имеют место просто разные API подключения.
На самом деле любую программу написанную на полном по Тьюригу языке можно переписать на любом другом полном по Тьюренгу языке.
Намек ясен?

ГВ>Очень хорошо. Я это слышал ещё до того, как компонентные архитектуры стали общим местом. Бардака с тех пор меньше не стало. Вот же, зараза!
Бардак он в голове...

ГВ>Знаешь, в чём парадокс? В том, что для того, чтобы сериалайзеры и дизйнеры заработали с тем, что они и "в глаза не знают", нужно только, чтобы это самое незнакомое чудище содержало соответствующий API, с которым прекрасно знакомы сериалайзеры и дизайнеры.
Прикол в том что это API можно приклеить сбоку.
Ибо IDomain.GetType
А IDomain можно реализовать как угодно.

ГВ>Такое происходит с любым дизайном. Абсолютно. Исключений нет. Если изменились требования, предъявляемые к конкретной программе, эта программа модифицируется. Если изменятся требоваия к самой компонентной инфраструктуре, ты тоже будешь её [до|пере]писывать, никуда не денешься.

Если решение достаточно полиморфно то нужно только дописать новую функциональность.
Но переписывать не нужно.

Хотя если из программы складского учета захотят сделать фотошоп... то тут ничего не поможет...

ГВ>О! Ещё теплее. А дальше что происходит?

Тупой рекурсивный обход дерева.

(С)Я

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

WH>Например нужно мне было распарсить логи не тривиальным образом.
WH>Тк время было вечером и делать было нечего...

Можешь рассказать какие из фич Nemerle помогли решить задачу эффективнее (если это имело место быть), чем если бы это был C#?
По описанию задачи не могу пока представить где могла пригодиться вся его мощь.

И навскидку во сколько компактнее получилось решение?

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

EC>Можешь рассказать какие из фич Nemerle помогли решить задачу эффективнее (если это имело место быть), чем если бы это был C#?
EC>По описанию задачи не могу пока представить где могла пригодиться вся его мощь.
А вся и близко не пригодилась. Пока... я хочу сделать болие простой синтаксис чем получился сейчас, а тут уже нужна тяжелая артилерия... макросы!
[миниакальный смех] Му-ха-ха-ха!... [/миниакальный смех]

EC>И навскидку во сколько компактнее получилось решение?
По сравнению с C#1 раз в натцать. По сравнению с C#3 чуть меньше.
Тут главное ФВП которые по совместительству функции расширения чтобы можно было их через точку писать, замыкания и итераторы (yield). Все это есть в C#3. Хотя в C#3 сильно хуже с выводом типов. Этот факт может все опошлить.
Но проверять мне лень.

Основное чего точно нет это макроса regexp match.

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

        public MapReduceLazy[T, Acc, R]
            ( this seq : SCG.IEnumerable.[T]
            , eq : T * T -> bool
            , startSeq : T -> Acc
            , fn : T * Acc -> Acc
            , endSeq : Acc -> R
            ) : SCG.IEnumerable.[R]
        {
            using (seq = seq.GetEnumerator())
            {
                def processSubSeq(cur)
                {
                    def process(cur, acc)
                    {
                        def acc = fn(cur, acc);
                        if (seq.MoveNext())
                        {
                            def cur2 = seq.Current;
                            if (eq(cur, cur2))
                            {
                                process(cur2, acc);
                            }
                            else
                            {
                                (cur2, acc, true)
                            }
                        }
                        else
                        {
                            (cur, acc, false)
                        }
                    }
                    def (cur, acc, next) = process(cur, startSeq(cur));
                    yield endSeq(acc);
                    when (next)
                        processSubSeq(cur);
                }
                when (seq.MoveNext())
                {
                    processSubSeq(seq.Current)
                }
            }
        }

С другой стороны:

        public FlattenLazy[T](this seq : SCG.IEnumerable.[SCG.IEnumerable.[T]]) : SCG.IEnumerable.[T]
        {
            foreach (seq in seq)
                foreach (val in seq)
                    yield val;
        }

Так что фичи разные нужны. Фичи разные важны.

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

WH>А вся и близко не пригодилась. Пока... я хочу сделать болие простой синтаксис чем получился сейчас, а тут уже нужна тяжелая артилерия... макросы!
WH>[миниакальный смех] Му-ха-ха-ха!... [/миниакальный смех]
Пример того, что хочется упростить можно?

WH>Тут главное ФВП которые по совместительству функции расширения чтобы можно было их через точку писать, замыкания и итераторы (yield).
Естественно.
WH>Все это есть в C#3.
Ага.

WH>Основное чего точно нет это макроса regexp match.
Что за зверь?

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

WH>>[миниакальный смех] Му-ха-ха-ха!... [/миниакальный смех]
EC>Пример того, что хочется упростить можно?
Сейчас так

    FileProcessor().ProcessLines(inFileName, outFileName, lines => lines.
        MapLazy(line => regexp match (line) {
        | @"[^:]+:(?<time>\d+:\d+:\d).*\]\s*(?<ip>\S+).*" => Some((time, ip))
        | _ => None()
        }).
        FilterOptionalLazy().
        GroupLazy((x, y) => x[0] == y[0]).
        MapLazy(seq => seq.
            CountAllToArray().
            SortInplace((x, y) => y[0] - x[0]).
            MapLazyFiltered
                ( (count, _) => count > 100
                , fun(count, (time, ip)) { $"$time $count $ip" }
                )
        ).
        FlattenLazy()
    );

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

хочется так

    FileProcessor().ProcessLines(inFileName, outFileName, seq => seq
        .RegexpMapFiltered(@"[^:]+:(?<time>\d+:\d+:\d).*\]\s*(?<ip>\S+).*") //{time : string, ip : string}
        .Group(time)
        .Map(seq => seq
            .Count(count) //{count : int, time : string, ip : string}
            .Filter(count > 100)
            .Sort(-count)
            .Map($"$time $count $ip")
        )
        .Flatten()
    );

Плюс фильтры по потокам растащить.

Основеное что нужно сдеать это генерить структурки по контексту. См комментарии.
И как дополнительная хотелка генерить замыкания по конексту.

Но тк приоритет у этой задачи около нуля врядли я этим в ближайшее время займусь.

В любом случае даже первый вариант гораздо проще любого императивного решения.

EC>Что за зверь?
http://nemerle.org/Quick_Guide#Regular_Expressions_match

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

ГВ>Это сфероконический пример, пока не выяснится контекст, к которому он реально относится.
Красивый термин "сфероконический". Вызывает ассоциации то ли с древнерускими шлемами, то ли с кониками в сферическом пространстве.

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

ГВ>>> И как ты понимаешь, доказательства по аналогии... Далее по тексту.
AVK>>Это не доказательства. Это пример такой архитектуры в железе.

ГВ>WPF — это Windows Presentation Foundation?

Да.

ГВ>>>Это сфероконический пример, пока не выяснится контекст, к которому он реально относится.
AVK>>Контекст? Что такое в твоем понимании контекст в данном случае?

ГВ>Это всё, что непосредственно взаимодействует с показанными интерфейсами.

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

ГВ> Плюс требования, плюс... Не знаю, что ещё может потребоваться, а выдумывать не буду.

Круто. Сам не знаешь что ты хочешь.

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

ГВ>Я хочу увидеть sequence diagram а) сериализации, б) загрузки контрола редактором.

Редактор использует тот же самый сериализатор, так что это одно и тоже. UML я тебе рисовать не буду, потому что это нехилое количество работы, а на словах попробую описать (опустив подробности реализации).
1) Создается экземпляр сервиса для работы с метаданными
2) Создается экземпляр класса, описывающий модель сериализованного представления (далее МСП), абстрагированную от конкретного формата сериализации.
3) Вызывается сериализация корневого компонента.
4) Создается отображение компонента на МСП
5) Создается контекст сериализации
6) Вызывается сериализация элементов компонента (свойств, событий)
7) Получаем у сервиса метаданных список элементов метаданных компонента.
8) Для каждого из элементов получаем список возможных владельцев (для собственных свойств в качестве владельца возвращается указатель на сам элемент)
9) Для каждой комбинации владельца и элемента вызываем метод добавления его в МСП
10) Если элемент — событие, то проверяем, нужно ли его сериализовать (вызов метода элемента метаданных)
11) Если сериализация требуется, то обращаемся к методу, возвращающему значение события. В базовой реализации сериализатора этот метод абстрактный, потому что универсального способа сериализации события нет.
12) Полученное значение записываем в МСП
13) Если в п.10 имеем не событие, а свойство, то проверяем наличие интерцептора и его желание перехватить конкретное свойство.
14) Если интерцептор есть и подтвердил то, что он хочет перехватить, то перекладываем задачу получения значения свойства на него.
15) Если нет, то обращаемся к метаданным для проверки необходимости сериализации.
16) Если сериализация требуется, то формируем контекст сериализации свойства.
17) Если для свойства есть кастомный сериализатор, то получаем экземпляр сериализатора и предлагаем ему записать свойство из контекста в МСП
18) Если значение свойства является компонентом, то проверяем, несет ли ответственность владелец свойства за создание этого компонента.
19) Если нет — добавляем в МСП ссылку на компонент
20) Если да — рекурсивно вызываем п.3 и добавляем результат в МСП
21) Если свойство является коллекцией (реализует IEnumerable), то пробегаемся по всем элементам
22) Для каждого элемента проверяем, является ли он компонентом
23) Если да, см. п.18
24) Если нет, преобразуем объект в строку
25) Добавляем коллекцию в МСП
26) Если ни одна из проверок свойства не вернула true, преобразовываем значение свойства в строку и записываем в МСП.
27) Рекурсивно вызываем сериализацию вложенных компонентов (п.3)
28) Создаем экземпляр writer, умеющего записывать МСП в требуемый формат
29) writer рекурсивно обходит МСП (в текущей реализации это визитор) и пишет результат в поток (сейчас это XML).

Ну что, сильно полегчало?

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

Т>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Это сфероконический пример, пока не выяснится контекст, к которому он реально относится.
Т>Красивый термин "сфероконический". Вызывает ассоциации то ли с древнерускими шлемами, то ли с кониками в сферическом пространстве.

Еще неплохо звучит: "сфероканонический"

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

AVK>[...] а на словах попробую описать (опустив подробности реализации).

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