Парсер C# на Nemerle - .NET

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

A>Это у вас кривой design значит, если написав идентификатор в другом регистре получаешь другое поведение. Вы пишете сперва под .Net и уже потом на Nemerle. Любые другие приоритеты делают вас закрытым клубом.

Вообще-то гайдлайны — это ело каждого. Сто раз видел как константы, например, называют в С-стиле "MY_CONST". Как-то это не делало языки на которых так писали закрытым клубом.

Что касается кейсов, то для переменных в паттернах и для имен вариантных типов они строго определены. Это традиции ML-я. Точнее даже не традиции, а часть дизайна паттерн-матчинга.

Вариантных типов нет в мэйнстрим-языках. По этому, если кто-то хочет использовать их в своих проектах, то придется привыкнуть к чужим традициям. Поверь, это с лихвой окупается.

Кстати, в F# используются похожие соглашения.

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

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

H>>Т.е. то, что в AST используются поля и называются они в нижнемРегистре делает невозможным работу с ним?

A>Заметно затрудняет. Плохое начало, если ты хочешь чтобы библиотеку использовали где-то ещё.

Эмм я не понимаю как это может затрудить. Правда — не понимаю.

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

VD>Вообще-то гайдлайны — это ело каждого. Сто раз видел как константы, например, называют в С-стиле "MY_CONST". Как-то это не делало языки на которых так писали закрытым клубом.

Для меня указ — FxCop в данном случае.

VD>Что касается кейсов, то для переменных в паттернах и для имен вариантных типов они строго определены. Это традиции ML-я. Точнее даже не традиции, а часть дизайна паттерн-матчинга.
VD>Вариантных типов нет в мэйнстрим-языках. По этому, если кто-то хочет использовать их в своих проектах, то придется привыкнуть к чужим традициям. Поверь, это с лихвой окупается.

Мне нужен парсер C#, а не Nemerle или F# со всеми их прелястми. Меня не должно волновать на каком языке он написан, это не должно быть видно снаружи. Всё что с модификатором internal может называть как угодно, всё что public должно называться так, как принято под .Net. Это следование правилам платформы, а не мои личные капризы. Если вы собираетесь предоставлять свой код для использующих другие языки, то лучше бы переделать правила именования у себя, чем пытаться навязать их сообществу куда большего размера чем ваше.

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

A>>Заметно затрудняет. Плохое начало, если ты хочешь чтобы библиотеку использовали где-то ещё.
H>Эмм я не понимаю как это может затрудить. Правда — не понимаю.

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

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

Tom>Причём тут вообще IQ, я даже при очень большом желании использовать немерл не смогу пробить стену мэнеджмента который справедливо боится что поддержка сего проекта закончится сразу после того как кто то не ухватится за новую супер пупер идею, как это было с R#

Как причем? Боятся как рез те у кого IQ низкий. Те что с IQ повыше просто разбираются в вопросе и бояться им не чего.

Тут можно только сказать бессмертную фразу из Золотого теленка — "Пилите Шура, пилите! Они золотые...".

Все кому не нравится немерл или они его боятся, идут пилить гири (создавать парсеры самостоятельно). Те у кого IQ совсем низкий при этом напишут все руками (точнее в большинстве случаев, просто ничего не сделают), так как генератор парсеров тоже продукт неизвестно чей и все аргументы боязливых товарищей к нему так же применимы. Те кто имеет немного больший IQ возьмут какой-нить ANTLR и с помощь какой-то матери за пол годика получают требуемый результат. Далее они начинают всю жизнь его поддерживать. Ну, а те чей IQ достаточен чтобы разобраться в немреле и посему его не бояться, просто берут готовое и используют. Если что не так подкручивают самостоятельно. Могу похвастаться. Моего IQ хватило разобраться с немрелом. И как только я это сделал мне стало совсем не страшно его использовать. Сейчас я его использую при написании любого кода. Скажем новая версия RSDN Authoring Pack практически (если не считать запускающих макросов) целиком написана на Немерле и отлично работает. Его пользователи, наверно, даже не знают об этом и смело им пользуются.

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

VD>Вариантный тип — это не просто класс. Если присмотреться к коду по внимательнее, то можно заметить, что описание полей полностью совпадают с описанием параметров одного из конструкторов. Это не случайно! В это есть большой смысл. Немерл гарантирует это. В результате мы можем в распозновать объекты вариантных типов типов с помощью образцов описывающих конструктор такого типа. Скажем, конкретный экземпляр Alias-а можно распознать таким образом:

VD>match (ast)
VD>{
VD>  | Alias(id) => WriteLine(id);
VD>  ... // другие образцы
VD>}

VD>По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.

ОК, но тут нет никакого обращения к полям/свойствам варианта. Если я правильно понимаю "id" в примере — это переменная, имя которой матчится с именем параметра конструктора варианта. Имя переменной матчится с именем параметра конструктора. Ни слова об имени свойства!
Вспомним, ка кобъявляется вариант:

variant RgbColor
{ | Red
  | Yellow
  | Green
  | Different { red : float; green : float; blue : float; }
}

А теперь представим сеье такое объявление:

variant RgbColor
{ | Red
  | Yellow
  | Green
  | Different { Red : float; Green : float; Blue : float; }
}

Что мешает по такому определению сгенерировать класс с полями (пускай пока с полями) Red, Green и Blue и с консруктором, параметры в котором называются red, green, blue — так же как и поля, только в lowerCase? Это не вызовет никаких конфликтов с темми, кто предпочитает имеющийся синтаксис.

Таким образом Alias(id) отматчится верно по имени параметра конструктора.

VD>Конечно можно сгенерировать (причем автоматически) свойства дублирующие эти поля. Но на мой взгляд — это все вкусовщина на которую не стоит тратить время. Плюс дублирование сущностей (поля и свойства будут мало чем отличаться) не есть гуд.

Совершенно верног, _дублировать_ (то есть иметь и открытые поля и открытые свойства) не нужно совсем, уж лучше как есть.

VD>Так что если нужно ехать, а не шашечки лучше переступить через свои привычки и все будет ОК.

Ну в таком случае может вам свои гайдлайны начать писать? Имеющиеся-то не подходят, оказывается

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

VD>Ну, а еще лучше попробовать освоить немерл. Ведь распознавание АСТ в десятки раз проще осуществлять с помощью паттерн-матчинга. Немерл ничем не отличается от Шарпа по возможнсотям.

Не спорю. Но правильно ли я понимаю, что в самом Немерле нет необходимости [часто?] обращаться явно к полям варианта? Потому что иначе получается странно — у одних типов свойства "как у людей" по гайдлайнам, а у других — с маленькой буквы. Тогда, может, в Немерле стоит придерживаться гайдлайна что поля в lower а свойства в Upper вне зависимости от открытости?

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

Tom>>Причём тут вообще IQ, я даже при очень большом желании использовать немерл не смогу пробить стену мэнеджмента который справедливо боится что поддержка сего проекта закончится сразу после того как кто то не ухватится за новую супер пупер идею, как это было с R#
VD>Как причем? Боятся как рез те у кого IQ низкий. Те что с IQ повыше просто разбираются в вопросе и бояться им не чего.

Ты предлагаешь менеджменту выучить язык Nemerle и осознать его мощь?

VD>Тут можно только сказать бессмертную фразу из Золотого теленка — "Пилите Шура, пилите! Они золотые...".

Как мы все помним Паниковский ошибался.

VD>Все кому не нравится немерл или они его боятся, идут пилить гири (создавать парсеры самостоятельно). Те у кого IQ совсем низкий при этом напишут все руками (точнее в большинстве случаев, просто ничего не сделают), так как генератор парсеров тоже продукт неизвестно чей и все аргументы боязливых товарищей к нему так же применимы. Те кто имеет немного больший IQ возьмут какой-нить ANTLR и с помощь какой-то матери за пол годика получают требуемый результат. Далее они начинают всю жизнь его поддерживать.

Влад, ты глубоко не прав. ANTLR и Nemerle сравнивать просто смешно. У вас нет большого многолетнего опыта использования в разных промышленных проектах. Меня как менеджера не волнует что Nemerle крут, это не аргумент. Но меня волнует если кто-то успешно решил с помощью Nemerle реальную задачу и остался доволен. Ну и не забываем про порог вхождения. Сколько у нас есть опубликовых книжек про Nemerle на русском языке, которые можно купить в каждом городе?

VD>Ну, а те чей IQ достаточен чтобы разобраться в немреле и посему его не бояться, просто берут готовое и используют. Если что не так подкручивают самостоятельно. Могу похвастаться. Моего IQ хватило разобраться с немрелом. И как только я это сделал мне стало совсем не страшно его использовать.

Влад, ты борешься не с тем врагом. Проблема не в том что все вокруг трусы-тупицы. То есть да, все вокруг трусы-тупицы, но Nemerle не популярен не из-за этого.

VD>Сейчас я его использую при написании любого кода. Скажем новая версия RSDN Authoring Pack практически (если не считать запускающих макросов) целиком написана на Немерле и отлично работает. Его пользователи, наверно, даже не знают об этом и смело им пользуются.

Я им не пользуюсь, его инсталлятор блокируется антивирусом, а VB скрипты в ворде глючны. Об этом писали многократно, это настоящие проблемы. Мне как пользователю и правда плевать на чём это написано, на C# или на Nemerle, если не работает как надо.

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

A>Влад, ну причём тут интеллект? C# и T4 официально поддерживаемые продукты, Nemerle — нет.

Да ладно. Это где T4 официально поддерживается. И где хотя бы одна гарантия? Если завтра его бросят (как это было с кучей продуктов МС), то ты только локти покусать сможешь.

А немерле тоже официально поддерживается. Причем с теми же гарантиями что и C# (т.е. с никакими

).
Но при этом у него есть дно несомненное достоинство. Он идет с исходными кодами и наилебиральнейшей лицензией.

А интеллект он позволяет разобраться в предмете и перестать его бояться.

A>Вне зависимости от конкретного положения дел, стоящего за словами "официально поддерживаемый" менеджменту сложно согласиться использовать Nemerle. Я понимаю, что ситуация как в анекдоте "Не трахают, потому прыщи. Прыщи, потому не трахают.", но это реальность.

Да кто же вас заставляет. Пилите Шура, пилите! Пишите парсеры C# 4.0 сами. Ищите готовые. Только они, скорее всего, все равно будут созданы на базе некоторых генераторов парсеров которые так же являются внешними зависимостями и которых так же будут бояться ваши менеджеры.

Я уже не раз говорил, что это даже хорошо. Так как те кто рискнет не бояться (гы-гы, хорошо звучит!) будет реальное конкурентное преимущество.

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

VD>Да кто же вас заставляет. Пилите Шура, пилите! Пишите парсеры C# 4.0 сами. Ищите готовые. Только они, скорее всего, все равно будут созданы на базе некоторых генераторов парсеров которые так же являются внешними зависимостями и которых так же будут бояться ваши менеджеры.

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

VD>Я уже не раз говорил, что это даже хорошо. Так как те кто рискнет не бояться (гы-гы, хорошо звучит!) будет реальное конкурентное преимущество.

Пожалуйства не испугайся написать примеры использования на C# и документацию. Это даст конкурентное преимущество.

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

A>Заметно затрудняет. Плохое начало, если ты хочешь чтобы библиотеку использовали где-то ещё.

Это... Неправильный акцент. Этого никто не хочет. Мы просто не против этого. Но библиотека создавалась в своих личных целях. Нам нужно было просто научить компилятор немерла компилировать C#-Файлы в составе проектов немерла. Ну, и на будущее сделать автоматический конвертер из шарпа в немерл.

АСТ это, конечно же, разрабатывалось для исползования в Немерле. Просто кое-кто ошибочно считает, что варианты невозможно использовать из C#. Вот это не так, что я собственно и популярно разъяснил.

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

A>>Заметно затрудняет. Плохое начало, если ты хочешь чтобы библиотеку использовали где-то ещё.
VD>Это... Неправильный акцент. Этого никто не хочет. Мы просто не против этого.

Учитывая правильный акцент такой парсер становится для меня неподдерживаемым продуктом. Потому что если завтра в нём будет что-то, что удобно (естественно) использоват из Nemerle и не удобно использовать из C# я получу порцию пропаганды Nemrele, а не исправление под C#.

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

_FR>>Странно, что он небыл решён в самом начале. Майкрософт уже со времён второго фреймворка успешно избегает public instance fields в своих типах.

VD>В МС в большей части работают орлы которые или не догадываются о существовании readonly в C#, или искренне считают его рудиментом неизвестно зачем всунутым в язык.

Я вот наоборот, просматривая исходники четвёртого фреймворка нарадоваться не мог тому, что количество sealed классов (даже с private областью вилимости) увеличилось и readonly поля стали использоваться заметно чаще.

VD>Сейчас ситуация постепенно выправляется, но все же императивная идеология крепко засела во многих головах (и в вашей, кстати, тоже).

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

Этот аргумент в данном обсуждении по силе не хуже того, что у меня ухи торчком или нос пяточком.

VD>Меж тем никаких проблем с публичными полями нет, если, конечно, они доступны только на чтение. Более того, в таких условиях свойства просто не ясно зачем нужны.

Я же показал один пример — биндинг. Глубже думать пока нет необходимости.

VD>Ну, и еще раз повторюсь, это все же не классы. Это варианты. Их идеология идет от ML-подобных языков. Этой иделогии больше лет чем самому Майкрософту (не говоря уже о Шарпе). Она проверенна временем. Посему менять ее ради соответсвия гайдлайнам другого язык, конечно же никто не будет. Надо просто понять, что никаких реальных проблем тут нет. Это просто не привычно для кто много лет слушал только то что говорят в МС.

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

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

ВВ>>В противном случае будет неразрешимый на уровне парсера конфликт:
ВВ>>| something => ...
ВВ>>something — это что? Конструктор или просто переменная?
VD>Просто переменная. Даже так: "| Aliase(id)" — это будет просто переменная введенная в паттерне и связанная с параметром конструктора варианта (т.е. с его соответствующим полем). И имя переменной может отличаться от имени поля.
VD>Ограничение имеется только на название вариантов, их вхождений и переменных объявляемых в паттерне. Первые должны быть всегда с большой буквы (что совпадает с гайдлайнами), последнее (переменная) должна быть всегда с маленькой (что так же совпадает с гайдлайнами).

Ну вот если убрать ограничение на название вариантов и переменных, то и получится конфликт, о чем, собственно, и спрашивалось, если я правильно понял.

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

A>Для меня указ — FxCop в данном случае.

FxCop он умный. Ему многое можно объяснить

.

A>Мне нужен парсер C#, а не Nemerle или F# со всеми их прелястми. Меня не должно волновать на каком языке он написан, это не должно быть видно снаружи. Всё что с модификатором internal может называть как угодно, всё что public должно называться так, как принято под .Net. Это следование правилам платформы, а не мои личные капризы. Если вы собираетесь предоставлять свой код для использующих другие языки, то лучше бы переделать правила именования у себя, чем пытаться навязать их сообществу куда большего размера чем ваше.

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

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

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

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

Тебе нужен парсер шарпа не просто так? Это ведь не самоцель? Ты, наверно, с его помощью хочешь делать что-то хитрое с кодом, да? Если задачи, стоящие перед тобой, не тривиальные, ты можешь получить очень существенную (да что там, НЕСРАВНИМУЮ) выгоду, если потратишь день на изучение вариантных типов и паттерн-матчинга, и в результате напишешь код обработки АСТ на Немерле, а не на Шарпе. Разница будет настолько существенной, что твои опасения, и тем более недовольство регистрами полей, померкнут на фоне тех преимущество, что ты получишь. Ну, а результат ты можешь завернуть в библиотеку которая будет иметь кошерный публичный интерфейс в лучших традициях FxCop. И уже его можно будет использовать из проекта на шарпе.

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

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

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

A>Что происходит чаще: создание объекта или обращение в его члену?

Конечно создание объектов, если мы говорим о вариантах и их использование в немерле.
В немерле увидить код в котором к полям вариантов обращаются через точку можно очень редко.
А вот увидеть "создание объекта" можно очень часто, так как именно синтаксис конструкторов используется при паттерн-матчинге.

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

A>Тем более что при создании имена параметров не используются, а при обращении к члену имена членов используются.

Почему же? Используются иногда. В немерле с самого начала были именованные параметры. В Шарпе они появились в 4.0. Но теперь и в нем они могут использоваться. Иногда это повышает выразительность.

VD>>Так что если нужно ехать, а не шашечки лучше переступить через свои привычки и все будет ОК.

A>Как ты размахнулся, привычки. Это не привычни, это номенклатура. Правила, позволяющие разным людям одни и те же вещи называть одинаково и, таким образом, понимать друг друга.

Нет, нет, нет дорогой товарищ! Ты все же оцени за и против. Насколько твои привычки дороги? Можно ими пожертвовать ради резкого упрощения реализации?

VD>>В общем, надо просо понять, что Немерл имеет тотальное приемущество перед Шарпом в вопросе работы с иерархиями.

A>Пропаганда неуместа, время одноязычных программ давно прошло. Ты либо интегируешься, либо умираешь. Максимум на что ты можешь сегодня расчитывать — это использование твоего парсера из C#. Причём удобное использование, чтобы Nemerle не торчал из библиотеки во все стороны.

ОК. Хочешь я тебя удивлю? Обращайся ко мне на Скайп (логин такой же как ник тут) и я тебя за вечер научу как устранить проблему с именами полей. Уверяю тебя, что при этом ты к тому же получишь массу удовольствия.

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

_FR>

VD>>match (ast)
VD>>{
VD>>  | Alias(id) => WriteLine(id);
VD>>  ... // другие образцы
VD>>}
_FR>

_FR>ОК, но тут нет никакого обращения к полям/свойствам варианта. Если я правильно понимаю "id" в примере — это переменная, имя которой матчится с именем параметра конструктора варианта.

Правильно понимаешь. Но бывают и более сложные случаи. Если параметров более одного, то чтобы вписывать вместо игнорируемых плэйсхолдеры ("_") используется такой синтаксис:

match (ast)
{
  | Alias(имяПараметраКонструктора=образец) => ...
  ... // другие образцы
}

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

Да и сам объект может быть создан с помощью конструктора с использованием имен параметров.

ЗЫ

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

_FR>Имя переменной матчится с именем параметра конструктора. Ни слова об имени свойства!
_FR>Вспомним, ка кобъявляется вариант:
_FR>

_FR>variant RgbColor
_FR>{ | Red
_FR>  | Yellow
_FR>  | Green
_FR>  | Different { red : float; green : float; blue : float; }
_FR>}
_FR>

_FR>А теперь представим сеье такое объявление:
_FR>

_FR>variant RgbColor
_FR>{ | Red
_FR>  | Yellow
_FR>  | Green
_FR>  | Different { Red : float; Green : float; Blue : float; }
_FR>}
_FR>

_FR>Что мешает по такому определению сгенерировать класс с полями (пускай пока с полями) Red, Green и Blue и с консруктором, параметры в котором называются red, green, blue — так же как и поля, только в lowerCase? Это не вызовет никаких конфликтов с темми, кто предпочитает имеющийся синтаксис.

_FR>Таким образом Alias(id) отматчится верно по имени параметра конструктора.

VD>>Конечно можно сгенерировать (причем автоматически) свойства дублирующие эти поля. Но на мой взгляд — это все вкусовщина на которую не стоит тратить время. Плюс дублирование сущностей (поля и свойства будут мало чем отличаться) не есть гуд.

_FR>Совершенно верног, _дублировать_ (то есть иметь и открытые поля и открытые свойства) не нужно совсем, уж лучше как есть.

VD>>Так что если нужно ехать, а не шашечки лучше переступить через свои привычки и все будет ОК.

_FR>Ну в таком случае может вам свои гайдлайны начать писать? Имеющиеся-то не подходят, оказывается

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

VD>>Ну, а еще лучше попробовать освоить немерл. Ведь распознавание АСТ в десятки раз проще осуществлять с помощью паттерн-матчинга. Немерл ничем не отличается от Шарпа по возможнсотям.

_FR>Не спорю. Но правильно ли я понимаю, что в самом Немерле нет необходимости [часто?] обращаться явно к полям варианта? Потому что иначе получается странно — у одних типов свойства "как у людей" по гайдлайнам, а у других — с маленькой буквы. Тогда, может, в Немерле стоит придерживаться гайдлайна что поля в lower а свойства в Upper вне зависимости от открытости?

От:	VladD2	www.nemerle.org
Дата:	02.11.10 16:25
Оценка:

От:	hardcase	http://nemerle.org
Дата:	02.11.10 16:29
Оценка:

От:	adontz	http://adontz.wordpress.com/
Дата:	02.11.10 16:31
Оценка:	+1

От:	adontz	http://adontz.wordpress.com/
Дата:	02.11.10 16:33
Оценка:	+2

От:	VladD2	www.nemerle.org
Дата:	02.11.10 16:38
Оценка:

От:	_FRED_	@ViIvanov
Дата:	02.11.10 16:48
Оценка:

	От:	Воронков Василий
	Дата:	02.11.10 17:03
	Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	02.11.10 17:34
Оценка:	+1