Здравствуйте, VladD2, Вы писали:
IT>>В случае необходимости, для какого-либо типа BLToolkit генерирует и создаёт экземпляр наследника от TypeAccessor. Этот объект предназначен для создания экземпляров изсходного типа и доступа к его членам в обход Reflection. Т.е. в TypeAccessor'е генерируется пара методов CreateInstance, а для каждого члена исходного типа наследник MemberAccessor, который содержит сгенерированные методы GetValue, SetValue и ещё некоторые служебные методы. Далее это используется для маппинга, валидации, баиндинга и прочих вещей, которые требуют динамическое создание и доспут к членам какого-либо объекта.
VD>Это плохой подход.
Чем он плох?
VD>Если в руках есть такой мощьный инструмент как метапрограммирование, лучше не использовать доступ через object-ы, а создавать специальные объекты владеющие информацией о структуре тех объектов с которыми нужно работать. Я не соображу как называется этот паттерн, но он здесь очень кстати.
Так так и делается. TypeAccessor строится для каждого объекта свой.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
VD>>Это плохой подход.
IT>Чем он плох?
Ниже же сказано:
VD>>Если в руках есть такой мощьный инструмент как метапрограммирование, лучше не использовать доступ через object-ы, а создавать специальные объекты владеющие информацией о структуре тех объектов с которыми нужно работать. Я не соображу как называется этот паттерн, но он здесь очень кстати.
IT>Так так и делается. TypeAccessor строится для каждого объекта свой.
То что я видел лезет через object. А этого совершенно не нужно.
Это использование метапрограммирование с менталитетом рефлекшона. Вы пытаетесь создать чуть более быстрый рефлекшон. А надо делать специализированные конверторы которым уже не нужен рефрекшон.
Какова задача вашего кода? Записать его в БД? Так сделайте переходник:
ОбъектОпределенногоТипа -> ЗаписьВБД
Еще что-то? Вот для этого и сделайте переходник.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>То что я видел лезет через object. А этого совершенно не нужно. VD>Это использование метапрограммирование с менталитетом рефлекшона. Вы пытаетесь создать чуть более быстрый рефлекшон.
Чуть более быстрый — это процентов на 7-8 медленне самого быстрого способа с DataReader и на 25% быстрее датасетов. Реальный рефлекшин сливает датасетам в разы, раза в три минимуми.
VD> А надо делать специализированные конверторы которым уже не нужен рефрекшон.
Mapping в BLToolkit — вещь достаточно универсальная. В принципе, можно мапить что угодно во что угодно. Как частный случай для ридера такой вариант сделать можно, хотя и довольно сложно (очень много работы).
VD>Какова задача вашего кода? Записать его в БД? Так сделайте переходник: VD>
VD>ОбъектОпределенногоТипа -> ЗаписьВБД
VD>
VD>Еще что-то? Вот для этого и сделайте переходник.
К сожалению, на все случаи не напасёшься. Ты фактически предлагаешь разработчику библиотеки делать расширение библиотеки под каждый чих каждого пользователя. Можно сделать частные решения для наиболее частых случаев, но всё покрыть не удастся.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Чуть более быстрый — это процентов на 7-8 медленне самого быстрого способа с DataReader и на 25% быстрее датасетов. Реальный рефлекшин сливает датасетам в разы, раза в три минимуми.
И тем не менее решение половинчатое. Все же можно иметь решение близкое по скорости к датаридеру.
IT>Mapping в BLToolkit — вещь достаточно универсальная. В принципе, можно мапить что угодно во что угодно. Как частный случай для ридера такой вариант сделать можно, хотя и довольно сложно (очень много работы).
Ееще бы если единственный способ генерировать код — это эмит.
IT>К сожалению, на все случаи не напасёшься. Ты фактически предлагаешь разработчику библиотеки делать расширение библиотеки под каждый чих каждого пользователя. Можно сделать частные решения для наиболее частых случаев, но всё покрыть не удастся.
Я предлагаю написать универсальный код который сам напишет все за разработчика. А разработчик только покажет что ему нужно. Причем сделает это незаметно для себя. Я тебе уже присылал вариант локализуемых строк в котором программист может писать %%"Что хочу $s тварю" как буддто хардкодит всю работу со строками, а на выходе получать автоматически локализуемое приложение. Вот примерно так же можно и с БД, толко, естесвенно сложнее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, что "слив" засчитан?
Хэш-таблица — это в принципе хранилище данных + арифметика. Если хранилище данных предоставляет через экстеншины для XSLT то там это тоже сделать можно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Дарней, Вы писали:
Д>Правда, предварительно нужно будет добить до мало-мальски пригодного состояния плагин для VS. Д>Про всякие автокомплиты и рефакторинги мечтать пока рано, но хотя бы Д>обеспечить возможность редактировать/компилировать/запускать/отлаживать Д>в студии — это обязательно.
Программа минимум (в перечисленной тобой функциональности) доступна хоть сейчас,
причём без плагинов.
В пакете с Nemerle идут .targets для MSBuild.
Делается ручной хак .csproj-файла путём замены targets от C# на Nemerle'вские.
Для файлов .n не забываем ставить Build Action — Compile.
В качестве редактора — настраиваем на .n-файлы встроенный "Script Editor".
Подсветка не ахти, но лучше чем ничего.
Отладка получается полноценная — с бреакпойнтаими, просмотром/модификацией переменных и т.п. Ну, разве что, Edit&Continue нету.
P.S. Кому не лень и свободное время есть — можно сделайть простенький темплейт проекта.
Хотя более практичнее было бы помочь основной команде с разработкой плагина.
Здравствуйте, xhalt, Вы писали:
X>Отладка получается полноценная — с бреакпойнтаими, просмотром/модификацией переменных и т.п. Ну, разве что, Edit&Continue нету.
Отладка-то полноценная, но вот сообщения об ошибке у меня получаются какие-то корявые — какая бы ошибка ни была в исходниках, сообщение об ошибке неизменно:
C:\Program Files\Nemerle\Nemerle.MSBuild.targets(167,9): error MSB6003: The specified task executable could not be run. Could not load file or assembly 'Nemerle, Version=0.9.2.0, Culture=neutral, PublicKeyToken=e080a9c724e2bfcd' or one of its dependencies. The system cannot find the file specified.
Получается совсем неудобно — попробуй эту ошибку найди потом.
PS: Как только исправляю ошибку, всё, естественно, билдится на "ура".
Re[7]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
O>Отладка-то полноценная, но вот сообщения об ошибке у меня получаются какие-то корявые — какая бы ошибка ни была в исходниках, сообщение об ошибке неизменно: O>
O>C:\Program Files\Nemerle\Nemerle.MSBuild.targets(167,9): error MSB6003: The specified task executable could not be run. Could not load file or assembly 'Nemerle, Version=0.9.2.0, Culture=neutral, PublicKeyToken=e080a9c724e2bfcd' or one of its dependencies. The system cannot find the file specified.
Странно. У меня все ошибки и варнинги показываются. Как обычно по клику переход на нужное место в исходниках.
Как я делаю: <Import> с сишарповыми таргетами заменяю на:
<Import Project="C:\Program Files\Nemerle\Nemerle.MSBuild.targets" />
C:\Program Files\Nemerle -- путь куда поставился Nemerle из msi-ки.
Кстати — стоит проверить на наличие в GAC-е Nemerle.dll Может в этом дело?
Выскакивает каждый раз правда один лишний глупый вариниг
Здравствуйте, xhalt, Вы писали:
X>Странно. У меня все ошибки и варнинги показываются. Как обычно по клику переход на нужное место в исходниках. X>Как я делаю: <Import> с сишарповыми таргетами заменяю на: X><Import Project="C:\Program Files\Nemerle\Nemerle.MSBuild.targets" /> X>C:\Program Files\Nemerle -- путь куда поставился Nemerle из msi-ки.
Да, я так и делал. Оказалось, что у меня не та версия сборки была: Nemerle.MSBuild.Tasks референсила Nemerle версии 0.9.2.0, которой у меня не было (я там сам собирал). Вернул нужную версию — всё вроде заработало.
X>Выскакивает каждый раз правда один лишний глупый вариниг X>
Здравствуйте, xhalt, Вы писали:
X>P.S. Кому не лень и свободное время есть — можно сделайть простенький темплейт проекта. X>Хотя более практичнее было бы помочь основной команде с разработкой плагина.
Полноценный интеллисенс и реафкторинг нам конечно не светит в ближайшее время, ибо здесь нужен фоновый парсинг, а стандартный парсер немерле слишком медленный.
Для начала довести бы до ума просто возможность работать в студии без необходимости поминутно потрясать бубном.
я вот сейчас думаю, как лучше сделать
отдельный тип проекта для Nemerle — или возможность добавлять файлы Nemerle к существующим проектам C#?
правда, пока не совсем ясно, как реализовать второй пункт. Надо будет еще поковыряться в SDK.
Или наоборот — возможность добавлять к проектам немерле файлы C# и C++/CLI?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[7]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Дарней, Вы писали:
Д>Полноценный интеллисенс и реафкторинг нам конечно не светит в ближайшее время, ибо здесь нужен фоновый парсинг, а стандартный парсер немерле слишком медленный.
. Тут у тебя будут отдельные типы проектов для Nemerle (правда, с расширением .csproj, но это не сильно большая беда имхо, тем более что и это можно исправить).
А для взаимодействия с C# или C++/CLI или чем угодно ещё — добавляешь проект другого типа в солюшен (как всегда, в общем).
Re[8]: Снова о Nemerle или профанация не пройдет :)
надо будет проверить, насколько быстро. Интересно, а можно его научить компилировать не весь файл, а только изменившуюся часть?
O>Посмотри сюда: Re: Микро-аддин для VS 2005
. Тут у тебя будут отдельные типы проектов для Nemerle (правда, с расширением .csproj, но это не сильно большая беда имхо, тем более что и это можно исправить).
O>А для взаимодействия с C# или C++/CLI или чем угодно ещё — добавляешь проект другого типа в солюшен (как всегда, в общем).
сделать отдельный тип проекта — не проблема. Надо будет только обработать напильником то, что уже сделал NoiseEHC.
Но мне всё-таки хочется иметь возможность помещать исходники для разных языков в пределах одного проекта. Или я хочу слишком странного?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[9]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Дарней, Вы писали:
Д>сделать отдельный тип проекта — не проблема. Надо будет только обработать напильником то, что уже сделал NoiseEHC.
Дык зачем обрабатывать? Я уже всё сделал вроде...
Кстати, а что сделал NoiseEHC?
Д>Но мне всё-таки хочется иметь возможность помещать исходники для разных языков в пределах одного проекта. Или я хочу слишком странного?
Именно что странного ибо студия такого не поддерживает. А чем тебя не устраивают несколько проектов на разных языках в одном solution (в 2003-й и того не было)?
Re[10]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
O>Дык зачем обрабатывать? Я уже всё сделал вроде...
прямо-таки всё?
O>Кстати, а что сделал NoiseEHC?
слямзил пример из VS SDK и переделал его под немерле
O>Именно что странного ибо студия такого не поддерживает. А чем тебя не устраивают несколько проектов на разных языках в одном solution (в 2003-й и того не было)?
тем, что это принуждает группировать файлы не по их логическим связям, а по языку реализации
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[10]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
O>А чем тебя не устраивают несколько проектов на разных языках в одном solution (в 2003-й и того не было)?
В 2003 таки выло. В одном солюшне смешивал проекты на native C++, уродском mC++, и C# с депендсами между ними.
А так, несколько языков для одного модуля — это конечно лишнее
А вот поддержка в VS многомодульных сборок не помешала бы.
Здравствуйте, Дарней, Вы писали:
O>>Дык зачем обрабатывать? Я уже всё сделал вроде...
Д>прямо-таки всё?
Да, со словами надо быть поосторожней...
O>>Кстати, а что сделал NoiseEHC?
Д>слямзил пример из VS SDK и переделал его под немерле
Ух ты, а где это лежит? Я-то просто шаблонов проектов/айтемов понаделал...
O>>Именно что странного ибо студия такого не поддерживает. А чем тебя не устраивают несколько проектов на разных языках в одном solution (в 2003-й и того не было)?
Д>тем, что это принуждает группировать файлы не по их логическим связям, а по языку реализации
Да, это есть. Просто у студии в таком случае встаёт вопрос — как компилировать? У неё один проект соответствует одному MSBuild-проекту, соответственно один проект == один build target, насколько я понял.
Вот поддержка нескольких модулей в сборке — совсем другое дело, как писал xhalt