Re[38]: Макрос заместо TypeAccessorBuilder
От: IT Россия linq2db.com
Дата: 02.03.06 01:04
Оценка:
Здравствуйте, VladD2, Вы писали:

IT>>В случае необходимости, для какого-либо типа BLToolkit генерирует и создаёт экземпляр наследника от TypeAccessor. Этот объект предназначен для создания экземпляров изсходного типа и доступа к его членам в обход Reflection. Т.е. в TypeAccessor'е генерируется пара методов CreateInstance, а для каждого члена исходного типа наследник MemberAccessor, который содержит сгенерированные методы GetValue, SetValue и ещё некоторые служебные методы. Далее это используется для маппинга, валидации, баиндинга и прочих вещей, которые требуют динамическое создание и доспут к членам какого-либо объекта.


VD>Это плохой подход.


Чем он плох?

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


Так так и делается. TypeAccessor строится для каждого объекта свой.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[39]: Макрос заместо TypeAccessorBuilder
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.06 22:24
Оценка:
Здравствуйте, IT, Вы писали:

VD>>Это плохой подход.


IT>Чем он плох?


Ниже же сказано:

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


IT>Так так и делается. TypeAccessor строится для каждого объекта свой.


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

Какова задача вашего кода? Записать его в БД? Так сделайте переходник:
ОбъектОпределенногоТипа -> ЗаписьВБД

Еще что-то? Вот для этого и сделайте переходник.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Макрос заместо TypeAccessorBuilder
От: IT Россия linq2db.com
Дата: 03.03.06 02:33
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>То что я видел лезет через object. А этого совершенно не нужно.

VD>Это использование метапрограммирование с менталитетом рефлекшона. Вы пытаетесь создать чуть более быстрый рефлекшон.

Чуть более быстрый — это процентов на 7-8 медленне самого быстрого способа с DataReader и на 25% быстрее датасетов. Реальный рефлекшин сливает датасетам в разы, раза в три минимуми.

VD> А надо делать специализированные конверторы которым уже не нужен рефрекшон.


Mapping в BLToolkit — вещь достаточно универсальная. В принципе, можно мапить что угодно во что угодно. Как частный случай для ридера такой вариант сделать можно, хотя и довольно сложно (очень много работы).

VD>Какова задача вашего кода? Записать его в БД? Так сделайте переходник:

VD>
VD>ОбъектОпределенногоТипа -> ЗаписьВБД
VD>

VD>Еще что-то? Вот для этого и сделайте переходник.

К сожалению, на все случаи не напасёшься. Ты фактически предлагаешь разработчику библиотеки делать расширение библиотеки под каждый чих каждого пользователя. Можно сделать частные решения для наиболее частых случаев, но всё покрыть не удастся.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Макрос заместо TypeAccessorBuilder
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.06 02:50
Оценка:
Здравствуйте, IT, Вы писали:

IT>Чуть более быстрый — это процентов на 7-8 медленне самого быстрого способа с DataReader и на 25% быстрее датасетов. Реальный рефлекшин сливает датасетам в разы, раза в три минимуми.


И тем не менее решение половинчатое. Все же можно иметь решение близкое по скорости к датаридеру.

IT>Mapping в BLToolkit — вещь достаточно универсальная. В принципе, можно мапить что угодно во что угодно. Как частный случай для ридера такой вариант сделать можно, хотя и довольно сложно (очень много работы).


Ееще бы если единственный способ генерировать код — это эмит.

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


Я предлагаю написать универсальный код который сам напишет все за разработчика. А разработчик только покажет что ему нужно. Причем сделает это незаметно для себя. Я тебе уже присылал вариант локализуемых строк в котором программист может писать %%"Что хочу $s тварю" как буддто хардкодит всю работу со строками, а на выходе получать автоматически локализуемое приложение. Вот примерно так же можно и с БД, толко, естесвенно сложнее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: Макрос заместо TypeAccessorBuilder
От: IT Россия linq2db.com
Дата: 03.03.06 02:57
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я предлагаю написать универсальный код который сам напишет все за разработчика.


Усилия могут оказаться неадекватными полученному результату
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[43]: Макрос заместо TypeAccessorBuilder
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.06 03:23
Оценка:
Здравствуйте, IT, Вы писали:

IT>Усилия могут оказаться неадекватными полученному результату


Зависит от средства.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Снова о Nemerle или профанация не пройдет :)
От: Воронков Василий Россия  
Дата: 03.03.06 22:20
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, что "слив" засчитан?


Хэш-таблица — это в принципе хранилище данных + арифметика. Если хранилище данных предоставляет через экстеншины для XSLT то там это тоже сделать можно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Снова о Nemerle или профанация не пройдет :)
От: xhalt Украина  
Дата: 06.03.06 13:08
Оценка: 1 (1)
Здравствуйте, Дарней, Вы писали:

Д>Правда, предварительно нужно будет добить до мало-мальски пригодного состояния плагин для VS.

Д>Про всякие автокомплиты и рефакторинги мечтать пока рано, но хотя бы
Д>обеспечить возможность редактировать/компилировать/запускать/отлаживать
Д>в студии — это обязательно.
Программа минимум (в перечисленной тобой функциональности) доступна хоть сейчас,
причём без плагинов.
В пакете с Nemerle идут .targets для MSBuild.
Делается ручной хак .csproj-файла путём замены targets от C# на Nemerle'вские.
Для файлов .n не забываем ставить Build Action — Compile.
В качестве редактора — настраиваем на .n-файлы встроенный "Script Editor".
Подсветка не ахти, но лучше чем ничего.

Отладка получается полноценная — с бреакпойнтаими, просмотром/модификацией переменных и т.п. Ну, разве что, Edit&Continue нету.

P.S. Кому не лень и свободное время есть — можно сделайть простенький темплейт проекта.
Хотя более практичнее было бы помочь основной команде с разработкой плагина.
... << RSDN@Home 1.2.0 alpha rev. 0>>


Предлагаю работу в Киеве
Автор:
Дата: 04.05.06
Re[6]: Снова о Nemerle или профанация не пройдет :)
От: Oyster Украина https://github.com/devoyster
Дата: 06.03.06 17:43
Оценка:
Здравствуйте, 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 или профанация не пройдет :)
От: xhalt Украина  
Дата: 06.03.06 17:54
Оценка:
Здравствуйте, 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 Может в этом дело?

Выскакивает каждый раз правда один лишний глупый вариниг

Warning 1 assembly `C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll' already loaded NemerlieApp

но уже успел привыкнуть...
... << RSDN@Home 1.2.0 alpha rev. 0>>


Предлагаю работу в Киеве
Автор:
Дата: 04.05.06
Re[8]: Снова о Nemerle или профанация не пройдет :)
От: Oyster Украина https://github.com/devoyster
Дата: 06.03.06 18:11
Оценка:
Здравствуйте, 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>

X>Warning 1 assembly `C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll' already loaded NemerlieApp

X>но уже успел привыкнуть...

Ну мне помогло убирание сборки System из References. Она, похоже, референсится по умолчанию.
Re[6]: Снова о Nemerle или профанация не пройдет :)
От: Oyster Украина https://github.com/devoyster
Дата: 06.03.06 18:33
Оценка:
Здравствуйте, xhalt, Вы писали:

X>P.S. Кому не лень и свободное время есть — можно сделайть простенький темплейт проекта.


Я попытался нечто такое набросать: Re: Микро-аддин для VS 2005
Автор: Oyster
Дата: 06.03.06
.
Re[6]: Снова о Nemerle или профанация не пройдет :)
От: Дарней Россия  
Дата: 07.03.06 07:03
Оценка:
Здравствуйте, 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 или профанация не пройдет :)
От: Oyster Украина https://github.com/devoyster
Дата: 07.03.06 07:24
Оценка: +1
Здравствуйте, Дарней, Вы писали:

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


Кстати, если его ngen-ом обработать, то он компилит довольно быстро: Re[9]: Снова о Nemerle или профанация не пройдет :)
Автор: Vermicious Knid
Дата: 17.02.06
.

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


Посмотри сюда: Re: Микро-аддин для VS 2005
Автор: Oyster
Дата: 06.03.06
. Тут у тебя будут отдельные типы проектов для Nemerle (правда, с расширением .csproj, но это не сильно большая беда имхо, тем более что и это можно исправить).

А для взаимодействия с C# или C++/CLI или чем угодно ещё — добавляешь проект другого типа в солюшен (как всегда, в общем).
Re[8]: Снова о Nemerle или профанация не пройдет :)
От: Дарней Россия  
Дата: 07.03.06 07:37
Оценка:
Здравствуйте, Oyster, Вы писали:

O>Кстати, если его ngen-ом обработать, то он компилит довольно быстро: Re[9]: Снова о Nemerle или профанация не пройдет :)
Автор: Vermicious Knid
Дата: 17.02.06
.


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

O>Посмотри сюда: Re: Микро-аддин для VS 2005
Автор: Oyster
Дата: 06.03.06
. Тут у тебя будут отдельные типы проектов для Nemerle (правда, с расширением .csproj, но это не сильно большая беда имхо, тем более что и это можно исправить).


O>А для взаимодействия с C# или C++/CLI или чем угодно ещё — добавляешь проект другого типа в солюшен (как всегда, в общем).


сделать отдельный тип проекта — не проблема. Надо будет только обработать напильником то, что уже сделал NoiseEHC.
Но мне всё-таки хочется иметь возможность помещать исходники для разных языков в пределах одного проекта. Или я хочу слишком странного?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[9]: Снова о Nemerle или профанация не пройдет :)
От: Oyster Украина https://github.com/devoyster
Дата: 07.03.06 07:42
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>сделать отдельный тип проекта — не проблема. Надо будет только обработать напильником то, что уже сделал NoiseEHC.


Дык зачем обрабатывать? Я уже всё сделал вроде...

Кстати, а что сделал NoiseEHC?

Д>Но мне всё-таки хочется иметь возможность помещать исходники для разных языков в пределах одного проекта. Или я хочу слишком странного?


Именно что странного ибо студия такого не поддерживает. А чем тебя не устраивают несколько проектов на разных языках в одном solution (в 2003-й и того не было)?
Re[10]: Снова о Nemerle или профанация не пройдет :)
От: Дарней Россия  
Дата: 07.03.06 08:26
Оценка:
Здравствуйте, Oyster, Вы писали:

O>Дык зачем обрабатывать? Я уже всё сделал вроде...


прямо-таки всё?

O>Кстати, а что сделал NoiseEHC?


слямзил пример из VS SDK и переделал его под немерле

O>Именно что странного ибо студия такого не поддерживает. А чем тебя не устраивают несколько проектов на разных языках в одном solution (в 2003-й и того не было)?


тем, что это принуждает группировать файлы не по их логическим связям, а по языку реализации
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[10]: Снова о Nemerle или профанация не пройдет :)
От: xhalt Украина  
Дата: 07.03.06 08:29
Оценка: +1
Здравствуйте, Oyster, Вы писали:

O>А чем тебя не устраивают несколько проектов на разных языках в одном solution (в 2003-й и того не было)?

В 2003 таки выло. В одном солюшне смешивал проекты на native C++, уродском mC++, и C# с депендсами между ними.

А так, несколько языков для одного модуля — это конечно лишнее
А вот поддержка в VS многомодульных сборок не помешала бы.
... << RSDN@Home 1.2.0 alpha rev. 0>>


Предлагаю работу в Киеве
Автор:
Дата: 04.05.06
Re[11]: Снова о Nemerle или профанация не пройдет :)
От: Oyster Украина https://github.com/devoyster
Дата: 07.03.06 08:39
Оценка:
Здравствуйте, xhalt, Вы писали:

X>В 2003 таки выло. В одном солюшне смешивал проекты на native C++, уродском mC++, и C# с депендсами между ними.


Уппс... Я чего-то думал всегда, что нельзя.

X>А так, несколько языков для одного модуля — это конечно лишнее


+1

X>А вот поддержка в VS многомодульных сборок не помешала бы.


Полностью согласен. Жаль, что её так и нет...
Re[11]: Снова о Nemerle или профанация не пройдет :)
От: Oyster Украина https://github.com/devoyster
Дата: 07.03.06 08:39
Оценка:
Здравствуйте, Дарней, Вы писали:

O>>Дык зачем обрабатывать? Я уже всё сделал вроде...


Д>прямо-таки всё?


Да, со словами надо быть поосторожней...

O>>Кстати, а что сделал NoiseEHC?


Д>слямзил пример из VS SDK и переделал его под немерле


Ух ты, а где это лежит? Я-то просто шаблонов проектов/айтемов понаделал...

O>>Именно что странного ибо студия такого не поддерживает. А чем тебя не устраивают несколько проектов на разных языках в одном solution (в 2003-й и того не было)?


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


Да, это есть. Просто у студии в таком случае встаёт вопрос — как компилировать? У неё один проект соответствует одному MSBuild-проекту, соответственно один проект == один build target, насколько я понял.

Вот поддержка нескольких модулей в сборке — совсем другое дело, как писал xhalt
Автор: xhalt
Дата: 07.03.06
.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.