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

GZ>>Ваще-то я на твой вопрос уже ответил. И IMHO достаточно логично ответил, так что опровергнуть можно только реальными цифрами профайлинга.
IT>Ыгыгыгы!
Понял.

GZ>>>>Получение(изменение) данных, и трансформация из модели источника к логической модели и наоборот.
IT>>>Ответ неверный. DAL нужен для изоляции кода, работающего с БД от остальных частей приложения. Ключевое слово здесь изоляция.
GZ>>Ответ как раз верный. Изоляция — это уже средство.
IT>Следствие из чего? Из получения или трансформации? Впрочем это не важно. Ни то ни другое не даёт столько проблем, чтобы это выносить в отдельный слой.

GZ>>Уже лучше. Только полностью синхронизировать не удастся. Реляционные метаданные недостаточны.
IT>Почему?
Потому что есть разница. Например, есть readonly агрегационные поля формируемые только триггерами. FK — это всего лишь констреинт который зачастую отсутсвует поскольку логика более сложна и проверяется либо триггерами либо процедурами. Потому что должны ли две таблицы инстанцироваться всегда в один неделимый объект или нет. Потому что например в Oracle нет понятие guid а это можно сохранять в строку или в raw. Потому что объект может быть получен через набор вьюх и функций а закачен через таблицы. И т.д. и т.п.

GZ>>Можно только проверить соответсвие. И это можно сделать вполне внешними средствами.
IT>Можно, но почему-то никто не делает и я даже знаю почему.
Так почему?

IT>Как твой кешь повлияет на запрос вида "SELECT * FROM Customer", если он будет в DAL?
Подобный почти никак. А вот "select * from customer where id=?" до DAL — запрос может и не дойти и вообще не сгенерен. Хотя в случае транзакционности кэша все несколько усложняется.

IT>>>И как тебе в этом случае поможет наличие pass-through методов?
GZ>>>>OK. Кое что, ты уже описал. Нужно вставлять кэширование, секьюрити, логгирование и e.t.c. И желательно, чтобы вызовы были в одном слое,
IT>>>Зачем? Какую проблему мы решаем располагая все вызовы в одном слое?
GZ>>В одном раздельном слое? Этот слой называется бизнес-логикой, и он не зависит от UI.

IT>Бизнес логика диктуемая UI зависит от UI на 150%. Причём завист в худшем смысле этого слова.
Я не очень понимаю что такое бизнес-логика диктуемая UI. Я знаю что логика зависит от вариантов использования. А UI, БД и BL — средства.

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

GZ>>Не очень много. Измени поле в entity и где и какие изменения проверяются компилятором. Чаще всего, они инкапсулированы в отдельном компоненте(ежели разработчик дружит с головой). А вот лазить по UI (который чаще сложнее чем все остальное) не очень хочется.
IT>Никуда лазить не надо. В случае линка этим будет заниматься компилятор. Собственно говоря, о чём весь сыр-бор.
В случае типизированных бизнес объектов — то же самое.

IT>Ещё раз. Действия и возможности которые предоставлены клиентам бизнес-логики в случае бизнес логики диктуемой UI нужны только тому UI, который диктует эту логику. В результате у тебя будет бизнес-слой, состоящий из pass-through методов, которые вызываются только одним методом UI. Повторное использование в таких приложениях стремительно стремится к нулю.
Ну вот я и говорю. Пример достойный экзампла или простого проекта.

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

C>> В документации к RealProxy я не вижу возможности динамически добавлять реализуемые типы.
AVK>Курить ObjRef.TypeInfo.CanCastTo(). Этот метод вызывается при каждом кастинге TP.
А... А я думал, что что-то действительно серьезное. Берем и переписываем байт-код в Java так, чтобы касты объекта типа Proxy превращались в вызовы специального метода. Спокойно делается в рантайме.

AVK>>>Если это функциональный аналог, зачем тогда Tango Project?
C>>Для интероперабельности, у них же написано.
AVK>А что там интероперировать, если WCF поддерживает все стандарты WS?
Так Tango и есть просто реализация всех стандартов WS.

AVK>Jini нельзя добавить поддержку веб-сервисов в полном объеме?
В Jini можно добавить все что угодно, там архитектура гибкая. Я точно помню, что там еще в 2001 году были распределенные транзакции по типу WS-AtomicTransaction.

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

AVK>Периодически приходится. Тормозит-с.

Выбросте вы этот дотНет

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

ANS>>btw, вопрос к тебе как к знатоку. Где то в этом форуме, я видел утверждения, что типы генерируемые Linq-ом не доступны в других сборках. Означает ли это, что Linq-запросы можно использовать только in-place? И что, вообще, то утверждение означает ?

AVK>Ты все перепутал.

Я ниче не мог перепутать, потому как я спрашивал как именно оно работает.

AVK>Анонимные типы недоступны компилятору за пределами метода.

То есть возвращаемое Linq-ом значение нельзя вернуть из метода (кроме как Object)?

AVK>С точки зрения рантайма (а биндинг работает только в рантайме) никаких анонимных типов нет, есть обычные классы.

Дык тем фактом, что Linq всё во время компиляции проверяет, а не в ран-тайм. Или ты о чем?

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

G> Форт (есть такой жутко гибкий макроязык для встраиваемых систем — по гибкости не уступает LISP, по близости к железу — ассемблеру и С).

"Твои слова да богу в уши"

Есть реализация (многоплатформенная и многопроцессорная), оптимально использующая при "шитье" все регистры используемых процессоров и/или умеющая оптимизировать свой "шитый" код?

Гибкость — да, скорость — нет.

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

A>Неужели в контексте использования в линке нельзя построить first-class составной предикат из списка полей ???

Декларативная часть linq (query extensions) — это гвоздями прибитое расширение к компилятору. Само это расширение расширять нельзя. Но можно расширять то, во что это расширение трансформируется, как это тут уже неоднократно демонстрировал AVK. Проблема лишь в том, что после трансформации у нас заканчивается декларативность и начинается чистый императив c элементами функциональщины.

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

C>Ты вообще IDEA когда-нибудь видел? Вот так выглядит диалог Analyze->Inspect code...:
C>http://files.rsdn.ru/37054/Inspections.PNG

Что я тебе могу сказать? Мрачное зрелище. Ты пробовал этот whole project запускать на больших проектах? Нормально, не торомзит?

IT wrote:

>> > binder.List = myMapper.select("from c in " +
> ReadCustomerTableNameFromXml() + " select c").list();
> .>А зачем?
> Затем, что никто не сможет удержать разработчика сделать не только
> такое, но такое от чего потом волосы будут стоять дыбом не только на голове.
Никто не сможет удержать разработчика приводить всё к void*. И что?

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

G>> Форт (есть такой жутко гибкий макроязык для встраиваемых систем — по гибкости не уступает LISP, по близости к железу — ассемблеру и С).

CU>"Твои слова да богу в уши"

CU>Есть реализация (многоплатформенная и многопроцессорная), оптимально использующая при "шитье" все регистры используемых процессоров и/или умеющая оптимизировать свой "шитый" код?

CU>Гибкость — да, скорость — нет.

Скорость и близость к железу не всегда совпадают

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

C>Зачем файл открывать? IDEA замечательно умеет ловить изменения на лету и проверять все файлы. А еще есть TeamCity, который вообще позволяет запускать инспекции на билд-сервере.

Мне не понятно только одно, зачем тогда вообще нужен компилятор?

C>Это НЕ имена таблиц и полей.

Не важно. Главное, что это строки.

C>Это имена entity, для которых поддерживается рефакторинг и проверка. Тебе screencast что ли снять?

Решарпер тоже пытается научится рефакторить в строках. Но у меня банально может не стоять решарпера или IDEA, либо оно может глюкнуть, либо кто-то в тиме поменяет что-то и зальёт врепозиторий, а я уже это заиспользовал и т.п. Случиться может что угодно. Поэтому я доверяю только компилятору. Если он сказал OK, то всё в прорядке. Но на строковые идентификаторы он всегда скажет OK.

Кстати, в этом топике я уже называл решение. Оно очень простое и решит не все, но большинство проблем. Это языковая конструкция nameof.

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

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

Чтобы не быть голословным
http://files.rsdn.ru/620/images4gaperton.zip
src — исходное изображение
остальные это увеличеное до 100х100 исходное изображение
good — то как должно быть
bad — без домножения на альфу и нелинейной коррекции цветов (специально для тебя ломал ресайз... с первого раза не получилось... компилятор по рукам надовал )

Из-за альфы мы имеем синий оттенок.
Из-за отсутствия нелинейной коррекции темные переходы между цветами.

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

G>Что именно ты пробовал. На сколько именно процентов это "просадило" библиотеку по скорости.
На некоторых фильтрах в разы.

G>На сколько увеличился объем кода.
Величелось не особо мильно но завелось куча мусора.

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

Жду варианта от твоих спецов.

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

ANS>btw, вопрос к тебе как к знатоку. Где то в этом форуме, я видел утверждения, что типы генерируемые Linq-ом не доступны в других сборках. Означает ли это, что Linq-запросы можно использовать только in-place? И что, вообще, то утверждение означает ?

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

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

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

IT>Означает, что за пределы метода такой тип можно вернуть только как object. Косяк, конечно. Обещали поправить, когда будут править CLR, т.е. ещё года через три.

хм. начал думать причем тут clr. Так и не понял. Но зато додумался до того, то не понимаю, что они с компилятором будут делать

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

M>Заменить текст деревом.

Деревом-деревом!.. В виде списка... в текстовом файле

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

IT>Радует лишь то, что для ad-hoc запросов всё же не нужно создавать типы, используемые между лэйерами и замусоривающие публичный интерфейс. Такие типы можно локализовать в пределах использующего их класса.

Как обычно, всё свелось к пользовательскому интерфейсу

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

C>>Ты вообще IDEA когда-нибудь видел? Вот так выглядит диалог Analyze->Inspect code...:
C>>http://files.rsdn.ru/37054/Inspections.PNG
IT>Что я тебе могу сказать? Мрачное зрелище. Ты пробовал этот whole project запускать на больших проектах? Нормально, не торомзит?
Со ВСЕМИ инспекциями — тормозит. Для определенных наборов инспекций (типа косяков с сериализацией) запускаю регулярно — работает быстро.

Ну и про билд-сервер я не зря сказал. Ему пофиг сколько там оно будет инспектироваться.

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

C>>Зачем файл открывать? IDEA замечательно умеет ловить изменения на лету и проверять все файлы. А еще есть TeamCity, который вообще позволяет запускать инспекции на билд-сервере.
IT>Мне не понятно только одно, зачем тогда вообще нужен компилятор?
Компилировать.

C>>Это НЕ имена таблиц и полей.
IT>Не важно. Главное, что это строки.
И что?

C>>Это имена entity, для которых поддерживается рефакторинг и проверка. Тебе screencast что ли снять?
IT>Решарпер тоже пытается научится рефакторить в строках. Но у меня банально может не стоять решарпера или IDEA, либо оно может глюкнуть, либо кто-то в тиме поменяет что-то и зальёт врепозиторий, а я уже это заиспользовал и т.п. Случиться может что угодно. Поэтому я доверяю только компилятору. Если он сказал OK, то всё в прорядке. Но на строковые идентификаторы он всегда скажет OK.
Добавь к "компилятору" еще и "инспектор" (который можно запускать отдельно от IDE, кстати).

IT>Кстати, в этом топике я уже называл решение. Оно очень простое и решит не все, но большинство проблем. Это языковая конструкция nameof.
Так никто не мешает и ее использовать в Hibernate.

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

GZ>>>Уже лучше. Только полностью синхронизировать не удастся. Реляционные метаданные недостаточны.
IT>>Почему?
GZ>Потому что есть разница. Например, есть readonly агрегационные поля формируемые только триггерами. FK — это всего лишь констреинт который зачастую отсутсвует поскольку логика более сложна и проверяется либо триггерами либо процедурами. Потому что должны ли две таблицы инстанцироваться всегда в один неделимый объект или нет. Потому что например в Oracle нет понятие guid а это можно сохранять в строку или в raw. Потому что объект может быть получен через набор вьюх и функций а закачен через таблицы. И т.д. и т.п.

Все эти проблемы решаемы. Было бы желание. Технических препятствий нет никаких.

GZ>Так почему?



IT>>Как твой кешь повлияет на запрос вида "SELECT * FROM Customer", если он будет в DAL?
GZ>Подобный почти никак. А вот "select * from customer where id=?" до DAL — запрос может и не дойти и вообще не сгенерен. Хотя в случае транзакционности кэша все несколько усложняется.

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

IT>>Бизнес логика диктуемая UI зависит от UI на 150%. Причём завист в худшем смысле этого слова.
GZ>Я не очень понимаю что такое бизнес-логика диктуемая UI. Я знаю что логика зависит от вариантов использования. А UI, БД и BL — средства.

Я бы сказал, что UI ближе к результату и напрямую связан с функциональными требованиями. Так я никогда в жизни не видел в ФТ требования к БД, а для UI видел уже даже готовые мокапы.

IT>>Если ты один в команде, то не сложно. Если не один и этот метод писал не ты, то, думаю, ты его даже пальцем не тронешь.
GZ>В случае нормальной тестируемости — трону.

Откуда ты узнаешь, что этот метод нужно трогать?

IT>>Никуда лазить не надо. В случае линка этим будет заниматься компилятор. Собственно говоря, о чём весь сыр-бор.
GZ>В случае типизированных бизнес объектов — то же самое.

Про DAL мы уже успели забыть.

IT>>Ещё раз. Действия и возможности которые предоставлены клиентам бизнес-логики в случае бизнес логики диктуемой UI нужны только тому UI, который диктует эту логику. В результате у тебя будет бизнес-слой, состоящий из pass-through методов, которые вызываются только одним методом UI. Повторное использование в таких приложениях стремительно стремится к нулю.
GZ>Ну вот я и говорю. Пример достойный экзампла или простого проекта.

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

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

>> Затем, что никто не сможет удержать разработчика сделать не только
>> такое, но такое от чего потом волосы будут стоять дыбом не только на голове.
.>Никто не сможет удержать разработчика приводить всё к void*. И что?

И глюки.

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

C>Добавь к "компилятору" еще и "инспектор" (который можно запускать отдельно от IDE, кстати).

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