Чем больше я думаю о возможностях linq и чем больше нахожу в нём всяко-разных плюсов, тем больше вижу его неприменимость для нашего случая. Т.е. сама идея безусловно здрава и очень хороша. Но реализация
Например, мне очень нравится идея анонимных типов, т.к. она позволяет решить проблему ad-hoc запросов. Это с одной стороны. С другой, для нормальной работы с навороченными web-контролами типа GridView, объект должен реализовывать интерфейс ICustomTypeDescriptor. В противном случае, из-за кривой реализации этих самых контролов, мы легко нарываемся на Reflection при баиндинге со всеми вытекающими последствиями. Проблему можно было бы решить безусловной генерацией ICustomTypeDescriptor, но это противоречит спецификации C# 3.0, да и сколько ещё таких специальных случаев у нас будет?
В свою очередь Linq2Sql (по слухам) предоставляет весьма качественную реализацию генерации SQL для MSSQL 2000/2005 из полученного expression tree и прочих радостей. У нас на сегодняшний день вырисовывается неслабая система резделения прав доступа, которая эффективно реализуется только с помощью БД. Грубо говоря, банальным поджоиванием к запросам таблиц, фильтрующих контент. Т.е. при "нормальном" девелопменте, реализация этой задачи лежала бы целиком на плечах программистов, что является абсолютно не нашим случаем. Нам желательно упрятать эту логику внутрь фреймворка. Впринципе, теоретически можно сделать Linq2OurModel и уже в нём реализовать всё необходимое и далее вызывать стандартную генерацию SQL из Linq2Sql. Но тут у меня возникает следующий вопрос.
Зачем? Имеет ли смысл для нашей задачи пытаться на 100% повторить функциональность Linq? Может быть лучше сделать что-то, что лучше всего подходит для нас, а linq заняться позже на основании полученного опыта?
Это позволит нам взять лучшие идеи из linq и при этом обойтись без его ограничений. При этом нам не надо будет делать универсальное решение, а значит оно может получится гораздо проще и эффективней.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Например, мне очень нравится идея анонимных типов, т.к. она позволяет решить проблему ad-hoc запросов. Это с одной стороны. С другой, для нормальной работы с навороченными web-контролами типа GridView, объект должен реализовывать интерфейс ICustomTypeDescriptor. В противном случае, из-за кривой реализации этих самых контролов, мы легко нарываемся на Reflection при баиндинге со всеми вытекающими последствиями. Проблему можно было бы решить безусловной генерацией ICustomTypeDescriptor, но это противоречит спецификации C# 3.0,
А если сделать эту генерацию условной?
IT>да и сколько ещё таких специальных случаев у нас будет?
А мы их макросами
IT>В свою очередь Linq2Sql (по слухам) предоставляет весьма качественную реализацию генерации SQL для MSSQL 2000/2005 из полученного expression tree и прочих радостей. У нас на сегодняшний день вырисовывается неслабая система резделения прав доступа, которая эффективно реализуется только с помощью БД. Грубо говоря, банальным поджоиванием к запросам таблиц, фильтрующих контент. Т.е. при "нормальном" девелопменте, реализация этой задачи лежала бы целиком на плечах программистов, что является абсолютно не нашим случаем. Нам желательно упрятать эту логику внутрь фреймворка. Впринципе, теоретически можно сделать Linq2OurModel и уже в нём реализовать всё необходимое и далее вызывать стандартную генерацию SQL из Linq2Sql. Но тут у меня возникает следующий вопрос.
IT>Зачем? Имеет ли смысл для нашей задачи пытаться на 100% повторить функциональность Linq? Может быть лучше сделать что-то, что лучше всего подходит для нас, а linq заняться позже на основании полученного опыта?
Возможно, так оно и будет лучше. Я вот только не могу понять, а почему мы не можем сделать фрэймворк на базе linq2sql? Например, в ситуации с правами доступа, нам же никто не мешает написать макрос, который эти права будет джоинить.
Здравствуйте, ie, Вы писали:
IT>>Например, мне очень нравится идея анонимных типов, т.к. она позволяет решить проблему ad-hoc запросов. Это с одной стороны. С другой, для нормальной работы с навороченными web-контролами типа GridView, объект должен реализовывать интерфейс ICustomTypeDescriptor. В противном случае, из-за кривой реализации этих самых контролов, мы легко нарываемся на Reflection при баиндинге со всеми вытекающими последствиями. Проблему можно было бы решить безусловной генерацией ICustomTypeDescriptor, но это противоречит спецификации C# 3.0,
ie>А если сделать эту генерацию условной?
И где ты будешь задавать это условие? А другие подобные?
IT>>Зачем? Имеет ли смысл для нашей задачи пытаться на 100% повторить функциональность Linq? Может быть лучше сделать что-то, что лучше всего подходит для нас, а linq заняться позже на основании полученного опыта?
ie>Возможно, так оно и будет лучше. Я вот только не могу понять, а почему мы не можем сделать фрэймворк на базе linq2sql? Например, в ситуации с правами доступа, нам же никто не мешает написать макрос, который эти права будет джоинить.
Какие-то запчасти от linq2sql можно попробовать использовать для генерации SQL. Я же говорю о той части linq2sql, которая linq. У меня сомнения в целесообразности её использования. Например, кроме секьюрити нам ещё нужно будет решить такие задачи как кеширование и статистика/логироване. Если последнее вроде тоже решается без проблем, то для кеширования возможно понадобится своё уникальное расширение синтаксиса.
В общем, если с позиции козы смотреть на баян, то не понятно нафига он ей вообще нужен.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Если нет, то все же стоит попробовать сначала подстроить под наши нужды LINQ, и если это не удатстя, то тогда взяться за велосипед. Это за одно позволит получить опыт который можнро будет применить в собственном велосипеде.
ЗЫ
Я понимаю зелание любого русского программиста обязательно переписать весь код, но все же объем работы огромен, и хорошо бы все же использовать имеющиеся наработки.
ЗЗЫ
Про ICustomTypeDescriptor не понял. Если можно по подробнее.
С System.Linq.IQueryable<T> ты разобрался? Неужели через него нельзя вмешаться в процесс обработки запроса и сделать все что нам надо?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
ie>>А если сделать эту генерацию условной?
IT>И где ты будешь задавать это условие? А другие подобные?
Например, макро-атрибут уровня сборки.
ie>>Возможно, так оно и будет лучше. Я вот только не могу понять, а почему мы не можем сделать фрэймворк на базе linq2sql? Например, в ситуации с правами доступа, нам же никто не мешает написать макрос, который эти права будет джоинить.
IT>Какие-то запчасти от linq2sql можно попробовать использовать для генерации SQL. Я же говорю о той части linq2sql, которая linq. У меня сомнения в целесообразности её использования.
Ну дык всему свое место, где можно будет использовать — используем, где нельзя будем ExpressionTree сами создавать.
IT>Например, кроме секьюрити нам ещё нужно будет решить такие задачи как кеширование и статистика/логироване. Если последнее вроде тоже решается без проблем, то для кеширования возможно понадобится своё уникальное расширение синтаксиса.
А разве в Linq2Sql не будет своего кеширования? Или нужно спецефическое?
Здравствуйте, VladD2, Вы писали:
VD>Если нет, то все же стоит попробовать сначала подстроить под наши нужды LINQ,
В том то и дело, что получится совсем наоборот — подстраивание наших нужд под linq. Пока все вопросы крутятся вокруг того надо ли или не надо допиливать компилятор, чтобы он понимал expression tree. А так никаких вопросов возникать не будет.
VD>и если это не удатстя, то тогда взяться за велосипед. Это за одно позволит получить опыт который можнро будет применить в собственном велосипеде.
От этого велосипеда можно потом будет взять колёса, раму и как минимум руль для того, чтобы на этой базе и с полученным опытом реализовать linq в полном объёме и со всеми его ограничениями.
VD>Я понимаю зелание любого русского программиста обязательно переписать весь код, но все же объем работы огромен, и хорошо бы все же использовать имеющиеся наработки.
Единственные полезные наработки, которые можно будет взять от linq2sql — это генерация SQL. Но тут есть один момент. Генерация SQL для конкретного частного случая — это задача для старшей группы детского сада. Но сложность этой задачи сильно повышается с универсализацией такого генератора и включением в него множества оптимизаций различных паттернов. Перед нами такая задача не стоит. У нас вполне конкретный случай и любое отклонение можно будет вполне нормально решать постепенным расширением возможностей генератора.
VD>Про ICustomTypeDescriptor не понял. Если можно по подробнее.
Для того чтобы баиндить данные на всевозможные контролы в .NET используется баиндинг, который в свою очередь использует возможности нескольких интерфейсов, таких как IBindingList и ITypedList. Реализация коллекций и баиндеров, поддерживающих такие интерфейсы позволяет автоматически добавить к контролу такие функции как фильтрация и сортировка, если он их поддерживает. Кроме этого нормальные контролы (в WinForms) запрашивают у этих коллекций списки TypeProperty, которые в дальнейшем используются для доступа к полям объектов. При таком подходе можно спокойно обойти Reflection. Но, контролы, которые писали индусы из команды WebForms пошли своим путём, и, например, GridView запрашивает коллекцию TypeProperty у TypeDescriptor, который строит её по информации из типа. По-умолчанию, доступ к свойствам объекта осуществляется через ревлекшин. Но есть способ обойти это безобразие. Если объект самостоятельно реализует ICustomTypeDescriptor, то хозяин — барин.
Я совсем не уверен, что генерируемые анонимные типы C# реализуют ICustomTypeDescriptor. Следовательно, это означает рефлекшин и тормоза.
Кроме этого, учитывая тот факт, что нам во время компиляции известна абсолютно вся информация, мы спокойно могли бы генерировать супер эффективные маперы. Помнишь ты ругался на счёт боксинга в BLToolkit? А я помню. Нам с Пашей пришлось так напрягаться, что чуть не родили слонёнка. При этом абсолютной эффективности всё равно не удалось добиться. А здесь это сделать будет просто как в школу не ходить.
VD>С System.Linq.IQueryable<T> ты разобрался? Неужели через него нельзя вмешаться в процесс обработки запроса и сделать все что нам надо?
Expression tree — это тоже тормоза. Мы же можем генерировать всё что нужно во время компиляции, у нас для этого всё есть.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, ie, Вы писали:
IT>>И где ты будешь задавать это условие? А другие подобные?
ie>Например, макро-атрибут уровня сборки.
К сожалению в ASP.NET нет единой сборки.
IT>>Какие-то запчасти от linq2sql можно попробовать использовать для генерации SQL. Я же говорю о той части linq2sql, которая linq. У меня сомнения в целесообразности её использования.
ie>Ну дык всему свое место, где можно будет использовать — используем, где нельзя будем ExpressionTree сами создавать.
Да это понятно. Только прикидывая оба варианта реализации меньше проблем будет, если сразу отказаться от ограничений linq.
IT>>Например, кроме секьюрити нам ещё нужно будет решить такие задачи как кеширование и статистика/логироване. Если последнее вроде тоже решается без проблем, то для кеширования возможно понадобится своё уникальное расширение синтаксиса.
ie>А разве в Linq2Sql не будет своего кеширования? Или нужно спецефическое?
Без понятия. Но я не думаю, что он что-то там поддерживает. Кроме того, хорошо бы ещё иметь статистику и прозрачное кеширование.
Для того, чтобы всё это сделать нам по-любому придётся делать что-то типа linq2MyDataModel, а уже перехватив вызовы можно будет применять запчасти от linq2sql. Так вот я и спрашиваю. Нафига козе баян, если мы уже на этапе linq2MyDataModel может сделать абсолютно всю нужную работу. Без всяких ограничений и наиболее эффективно с точки зрения производительности.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>В том то и дело, что получится совсем наоборот — подстраивание наших нужд под linq. Пока все вопросы крутятся вокруг того надо ли или не надо допиливать компилятор, чтобы он понимал expression tree. А так никаких вопросов возникать не будет.
А это вопрос мало связанный с реализацией. Это вопро внедрения синтаксиса. Мы всегда можем просто создать макрос вроде SQL(select ... from...) и забить на все остальное.
VD>>и если это не удатстя, то тогда взяться за велосипед. Это за одно позволит получить опыт который можнро будет применить в собственном велосипеде.
IT>От этого велосипеда можно потом будет взять колёса, раму и как минимум руль для того, чтобы на этой базе и с полученным опытом реализовать linq в полном объёме и со всеми его ограничениями.
Я бы начал с изучения linq-а и попытался бы его по возможности использовать. А то в использование рамы от самопала для конвейрного продукта мне верится не то что бы с трудом, а вообще никак.
IT>Единственные полезные наработки, которые можно будет взять от linq2sql — это генерация SQL. Но тут есть один момент. Генерация SQL для конкретного частного случая — это задача для старшей группы детского сада. Но сложность этой задачи сильно повышается с универсализацией такого генератора и включением в него множества оптимизаций различных паттернов. Перед нами такая задача не стоит. У нас вполне конкретный случай и любое отклонение можно будет вполне нормально решать постепенным расширением возможностей генератора.
IT, linq — это довольно объемный продукт. Мы на создание его аналога потратим не один месяц и в итоге не факт, что поулчим сильно лучшее решение. Все же разумно было бы заюзать наработки Майкрософта. Не зря же "они жгут ночное масло"? Им бедным в сто раз сложнее все это выписывать. Надо попытаться уважить их труд. А вот если мы при этом получим убедительные аргументы этого не далеть, то и вопрос отпадет сам собой.
VD>>Про ICustomTypeDescriptor не понял. Если можно по подробнее.
IT>Для того чтобы баиндить данные на всевозможные контролы в .NET используется баиндинг, который в свою очередь использует возможности нескольких интерфейсов, таких как IBindingList и ITypedList. Реализация коллекций и баиндеров, поддерживающих такие интерфейсы позволяет автоматически добавить к контролу такие функции как фильтрация и сортировка, если он их поддерживает. Кроме этого нормальные контролы (в WinForms) запрашивают у этих коллекций списки TypeProperty, которые в дальнейшем используются для доступа к полям объектов. При таком подходе можно спокойно обойти Reflection. Но, контролы, которые писали индусы из команды WebForms пошли своим путём, и, например, GridView запрашивает коллекцию TypeProperty у TypeDescriptor, который строит её по информации из типа. По-умолчанию, доступ к свойствам объекта осуществляется через ревлекшин. Но есть способ обойти это безобразие. Если объект самостоятельно реализует ICustomTypeDescriptor, то хозяин — барин.
А какие проблемы реализовать все это без полномаштабного перелапачивания всего linq-а?
IT>Я совсем не уверен, что генерируемые анонимные типы C# реализуют ICustomTypeDescriptor. Следовательно, это означает рефлекшин и тормоза.
Ну, типы нам по любому самим генерировать, так что тут даже вопроса не возникает. Сделаем все что потребуется. В linq-е главное — это не поддержка компилятора и какие-то там анонимные типы, а работа с деревьями выражений и преобразование их в SQL. Ну, и вся инфрастуктура по выполнению запросов, конечно.
IT>Кроме этого, учитывая тот факт, что нам во время компиляции известна абсолютно вся информация, мы спокойно могли бы генерировать супер эффективные маперы. Помнишь ты ругался на счёт боксинга в BLToolkit? А я помню. Нам с Пашей пришлось так напрягаться, что чуть не родили слонёнка.
Не трож святое!
IT> При этом абсолютной эффективности всё равно не удалось добиться. А здесь это сделать будет просто как в школу не ходить.
Думаю, тут у нас таких проблем не возникнет. В любом случае нужно досконально изучить linq, чтобы не повторить их ошибок и не изобретать то что уже изобретено. Боюсь, что твой почин приведет как раз к последнему.
IT>Expression tree — это тоже тормоза. Мы же можем генерировать всё что нужно во время компиляции, у нас для этого всё есть.
Expression мы и будем генерировать в компайлтайме. А преобразование Expression в рантайме в SQL вряд ли будет заметно на фоне обращения к другому процессу и исполнения все логики запроса SQL-сервером. За-то как раз IQuerible может позволить динамически менять запросы в зависимости от разных услвоий. Понятно, что варинты мы будет генерировать автоматом, но все же некоторая динамика нам не повредит.
ЗЫ
Еще раз повторю основную свою мысль. Бросившись делать свой "чистый" linq не попытавшись воспользоваться имеющейся реализацией мы рискуем потерять море времени за зря и при этом собрать все грабли которые в МС нащупывали собственным лбом на протяжении 3-х последних лет. Так что я бы для начала попытался сделать версию на базе linq. А там уже можно будет попробовать ее в тестовых условиях и решить, что делать дальше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Да это понятно. Только прикидывая оба варианта реализации меньше проблем будет, если сразу отказаться от ограничений linq.
Чтобы чего-то ненужное продать, надо сначала, что-то ненужное купить (с) кот Матроскин.
Пререфразируя классического котяру скажу, что чтобы избежать каких-то проблем сначала нужно их выявить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>В том то и дело, что получится совсем наоборот — подстраивание наших нужд под linq. Пока все вопросы крутятся вокруг того надо ли или не надо допиливать компилятор, чтобы он понимал expression tree. А так никаких вопросов возникать не будет.
VD>А это вопрос мало связанный с реализацией. Это вопро внедрения синтаксиса. Мы всегда можем просто создать макрос вроде SQL(select ... from...) и забить на все остальное.
Какой в этом тогда смысл? Я понимаю задачу так. Либо мы делаем полноценную поддержку linq в Nemerle, либо делаем то, что прежде всего устраивает нас.
IT>>От этого велосипеда можно потом будет взять колёса, раму и как минимум руль для того, чтобы на этой базе и с полученным опытом реализовать linq в полном объёме и со всеми его ограничениями.
VD>Я бы начал с изучения linq-а и попытался бы его по возможности использовать. А то в использование рамы от самопала для конвейрного продукта мне верится не то что бы с трудом, а вообще никак.
А в конвейерный продукт из ничего тебе верится без проблем?
VD>IT, linq — это довольно объемный продукт. Мы на создание его аналога потратим не один месяц и в итоге не факт, что поулчим сильно лучшее решение.
Мы и так потратим минимум полгода-год пока дождёмся его выхода.
VD>Все же разумно было бы заюзать наработки Майкрософта. Не зря же "они жгут ночное масло"? Им бедным в сто раз сложнее все это выписывать. Надо попытаться уважить их труд. А вот если мы при этом получим убедительные аргументы этого не далеть, то и вопрос отпадет сам собой.
Я не против заюзать что угодно. Только вот пока не видно что именно
VD>А какие проблемы реализовать все это без полномаштабного перелапачивания всего linq-а?
Проблем никаких, только это будет уже не linq.
VD>Ну, типы нам по любому самим генерировать, так что тут даже вопроса не возникает. Сделаем все что потребуется. В linq-е главное — это не поддержка компилятора и какие-то там анонимные типы, а работа с деревьями выражений и преобразование их в SQL. Ну, и вся инфрастуктура по выполнению запросов, конечно.
В линке может и не главное, а вот для нас будет главное. То, что тебе кажется большой проблемой лично мне не кажется невыполнимой задачей. Работать с деревьями нам придётся по-любому, а генерация SQL, как я уже говори, зависит от задачи. Делать её исходя из требований проекта linq2sql я бы в нерабочее время не решился, а для нашего случая не вижу проблем.
IT>> При этом абсолютной эффективности всё равно не удалось добиться. А здесь это сделать будет просто как в школу не ходить.
VD>Думаю, тут у нас таких проблем не возникнет. В любом случае нужно досконально изучить linq, чтобы не повторить их ошибок и не изобретать то что уже изобретено. Боюсь, что твой почин приведет как раз к последнему.
Я не против изучения. Я лишь против того, чтобы изо всех сил пытаться сделать linq, жертвуя при этом нашими интересами.
VD>Expression мы и будем генерировать в компайлтайме. А преобразование Expression в рантайме в SQL вряд ли будет заметно на фоне обращения к другому процессу и исполнения все логики запроса SQL-сервером.
Судя по тестам того же Gollum, тормоза есть и в рантайме. Остаётся только надеятся, что MS не оставит их без внимания до релиза.
VD>За-то как раз IQuerible может позволить динамически менять запросы в зависимости от разных услвоий. Понятно, что варинты мы будет генерировать автоматом, но все же некоторая динамика нам не повредит.
Если есть возможность всё сгенерировать в компайл-тайм и получить максимальную производительность, то зачем ей жертвовать ради "некоторой" динамики?
VD>Еще раз повторю основную свою мысль. Бросившись делать свой "чистый" linq не попытавшись воспользоваться имеющейся реализацией мы рискуем потерять море времени за зря и при этом собрать все грабли которые в МС нащупывали собственным лбом на протяжении 3-х последних лет. Так что я бы для начала попытался сделать версию на базе linq. А там уже можно будет попробовать ее в тестовых условиях и решить, что делать дальше.
Ни о каком "чистом" linq как раз речи не идёт. Предлагается смотреть на linq как на пример реализации хорошей идеи. Делать же то, что нужно нам.
ЗЫ. Впрочем, я не настаиваю, т.к. примерно представляю себе проблемы, с которыми нам придётся столкнуться.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Кстати, зачем ты вообще тогда занимался рекурсивными строками, если они при использовании linq2sql понадобяться меньше всего?
Они нужны для генерации SQL DML-я. И вообще, это универсальное решение. Ждакий ХСЛТ с человеческим лицом и на базе объектов, а не ХМЛ-я. Любой текст им можно генерировать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Какой в этом тогда смысл? Я понимаю задачу так. Либо мы делаем полноценную поддержку linq в Nemerle, либо делаем то, что прежде всего устраивает нас.
А что ут не полноценного? Не думаю, что 3 буквы и скобка сильно повредят. Просто это позволит не трахаться с компилятором, и сделать все очень просто.
IT>А в конвейерный продукт из ничего тебе верится без проблем?
Про "из ничего" не понял. МС несолько лет работал вроде.
IT>Мы и так потратим минимум полгода-год пока дождёмся его выхода.
Ну, поддерживать то можно то что есть в бете 1.
IT>Я не против заюзать что угодно. Только вот пока не видно что именно
Дык разбираться надо. Я толко мельком поглядел пока.
VD>>А какие проблемы реализовать все это без полномаштабного перелапачивания всего linq-а?
IT>Проблем никаких, только это будет уже не linq.
Мне кажется ты все же не дооцениваешь объем работ сделанный в linq. В прочем, называй как угодно. Не linq, так не linq. Главное не попытаться не писать код второй раз.
IT>В линке может и не главное, а вот для нас будет главное. То, что тебе кажется большой проблемой лично мне не кажется невыполнимой задачей. Работать с деревьями нам придётся по-любому, а генерация SQL, как я уже говори, зависит от задачи. Делать её исходя из требований проекта linq2sql я бы в нерабочее время не решился, а для нашего случая не вижу проблем.
IT не понимаю почему не попытаться воспользоваться тем что сделано в МС? Хотя бы посмотреть то уж точно надо. А ты как-то сразу хочешь не глядя свой велосипед лабать. По-русски конечно, но...
IT>Я не против изучения. Я лишь против того, чтобы изо всех сил пытаться сделать linq, жертвуя при этом нашими интересами.
А кто говорит о жертавах? Но уж если мы отказываемся от кучи написанного, отлаженного и поддерживаемого кода, то нужно иметь четки и веские основания для этого. А не просто так побазарили в форуме и пошли велосипед клепать.
IT>Судя по тестам того же Gollum, тормоза есть и в рантайме. Остаётся только надеятся, что MS не оставит их без внимания до релиза.
Я бы все же провел свои тесты. Нам нужны детали.
IT>Если есть возможность всё сгенерировать в компайл-тайм и получить максимальную производительность, то зачем ей жертвовать ради "некоторой" динамики?
Тут есть два вопроса:
1. Точно ли получится все сгенерировать?
2. Какой объем работ будет если мы окажемся от linq полностью?
Я, как бы, только за статику. Но какой ценой?
IT>Ни о каком "чистом" linq как раз речи не идёт. Предлагается смотреть на linq как на пример реализации хорошей идеи. Делать же то, что нужно нам.
Тогда сформулируй, плиз, что мы получим отказавшись от linq-а? И прикинь объем работ. Так же хорошо бы сравить его с объемом работ который будет если мы не откажемся от использования linq-а.
IT>ЗЫ. Впрочем, я не настаиваю, т.к. примерно представляю себе проблемы, с которыми нам придётся столкнуться.
Ну, так опиши. А то пока что у нас получается, что мы отказываемся от использования кучи готового кода только ради чистоты идеи и свободы мысли. При этом вообще не думая о том, во что это выльется.
ЗЫ
Мне кажется создать поототип на linq можно относительно малой кровью. Сразу будут видны проблемы (реально, а на на словах). Если проблем будет много, то не вопрос перепишем полностью. Но хотя бы будем знать где грабли. А если проблем будет не много и их можно будет обойти, то и переделывать ничего не надо будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
