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

>> Пожалуйста. Код одинаковый до смешного (хотя это мало о чем говорит;
>> поскольку все, что кроме магического "select/Filter" выглядело бы
>> практически так же на любом языке, хоть VB).
C>А как сделать чтобы он искал по имени и дате, используя индексы?

Вопроса не понял

Зверёк Харьковский wrote:
>> > Пожалуйста. Код одинаковый до смешного (хотя это мало о чем говорит;
>> > поскольку все, что кроме магического "select/Filter" выглядело бы
>> > практически так же на любом языке, хоть VB).
> C>А как сделать чтобы он искал по имени и дате, используя индексы?
> Вопроса не понял
У вас просто строится фильтр, который фильтрует данные при проходе по
коллекции. Соответственно, поиск будет занимать O(N) времени.

В RTL (Relational Template Library) строится сложный функтор, который
может использовать специально построенные индексы по полям.

Например:

//Определяем колонки
BOOST_RTL_DEFINE_COLUMN(std::string, Name);
BOOST_RTL_DEFINE_COLUMN(bool, IsMale);
BOOST_RTL_DEFINE_COLUMN(gregorian::date, BirthDate);

//Список полей таблицы
typedef boost::mpl::vector3<Name,IsMale,BirthDate> fld_list;
//Список полей для построения индексов
typedef boost::mpl::vector3<Name,BirthDate> idx_list;
//Информация о таблице включает в себя список полей и индексов
struct People : table_info<fld_list,idx_list>{};

expr_type epxr=select((m_people),
     col<0, People::Name>() == "Thor The Mighty" &&
     col<0, People::IsMale>() == true &&
     col<0, People::BirthDate>() < gregorian::date("1/1/1910")
     ;

selection(expr,table);

Поиск будет занимать O(log N) времени.

Причем, в отличие от обычных БД (предвидя восклицания VladD2) — я могу
использовать _любые_ типы для которых введена операция сравнения. В
примере с библиотекой идет программа для поиска в базе геоинформации,
например.

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

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

VD>>Зачем в List<T>?

O>Я рассматривал решение для фильтрации коллекции при использовании средств исключительно из BCL.

А я воспользовался чем-то из другой библиотеки?

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Пожалуйста.

Спасибо.

ЗХ>Код одинаковый до смешного

Вот и я о том же.

ЗХ> (хотя это мало о чем говорит; поскольку все, что кроме магического "select/Filter" выглядело бы практически так же на любом языке, хоть VB).

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

ЗХ>Но я ведь влез с рубей не для того, чтобы рассказать, какой я знаю крутой язык. Мне правда интересно, что в этой Карменсите за идея такая хитрая лежит. К сожалению, после диалога с Oyster'ом так и не понял Торможу сегодня.

Нет в ней идей. Это очередной на фиг не упавший велосипед.

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

VD>А я воспользовался чем-то из другой библиотеки?

Для фильтрации — написал свой метод. В общем, это уже разговор о мелочах.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Коллега, а ты можешь объяснить этот нюанс как для дурака? Т.е. "вот такой код, вот так бы работал без карменситы, карменсита позволяет избежать того-то". А то я чегой-то не проникся покуда

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

Ты предложил вариант на анонимных методах. Для такого варианта необходимо трансформировать внутреннее представление контейнера во что-то, что подойдёт делегату. Например, в список объектов класса с определёнными пропертями. Проблема тут в том, что нам для каждого нового типа объектов, которые могут храниться в контейнере, прийдётся дописывать какой-нибудь трансформирующий код.

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

Примеры

Есть у нас, скажем, List<T> и DataTable. Мы хотим уметь фильтровать оба контейнера единообразно, используя при этом анонимные методы. Например, у нас есть вот такой вот анонимный метод из моего предыдущего примера, предназначенный для фильтрации списка кастомеров:

Predicate<Customer> p = delegate(Customer cust)
{
    return
        cust.Name == "Thor the Mighty" &&
        cust.IsMale &&
        cust.BirthDate.Year < 1910;
});

Чтобы использовать этот делегат для фильтрации DataTable, нам прийдётся написать код, который будет трансформировать DataRow в Customer:

public Customer ToCustomer(DataRow row)
{
    ...
}

Хуже того — нам прийдётся писать такой код для каждого класса вроде Customer, который мы захотим использовать. И для каждого типа контейнера.

Karmencita же позволит нам написать некий код один раз для данного типа контейнера и использовать строковые запросы с любыми классами вроде Customer.

Старался как мог

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

VD>Нет в ней идей. Это очередной на фиг не упавший велосипед.

Не скажи — идея в ней есть, как есть она во многих библиотеках. И это совсем не велосипед — это весчь, которая может реально помочь тем, кто педалит на C# 2.0, и которую я, например, раньше не встречал.

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

Судя по твоему описанию, это похоже на привнесения динамической типизации в язык со статической типизицией. Я прав или нет?

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

ЗХ>>Коллега, а ты можешь объяснить этот нюанс как для дурака? Т.е. "вот такой код, вот так бы работал без карменситы, карменсита позволяет избежать того-то". А то я чегой-то не проникся покуда

[почитано, покусано]

O>Старался как мог

Фух, понял наконец-то!
Спасибо

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

EB>Судя по твоему описанию, это похоже на привнесения динамической типизации в язык со статической типизицией. Я прав или нет?

Нет Это всего лишь унифицированный язык фильтрации, на самом деле. Например, поля, указанные в текстовом фильтре, могут быть именами колонок DataTable или тегов/атрибутов XmlDocument. Они могут быть и пропертями объектов, но как частный случай.

Но в общем это не попытка привнесения динамической типизации — в конце концов, reflection для этого лучше подходит.

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


VD>Не. Не скажи. Я как бы знаком с другими языками и знаю насколько более громоздким получается код на них.

Ты вроде раньше говорил что это неважно

VD>А то что Немероловский код оказался очень близким по объему к Рубивскому — это как раз и есть достижение.

Да согласен очень мощная штука получается.

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

Я думаю полно задач где динамика лучше.

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

FR>Я думаю полно задач где динамика лучше.

Если бы таких задач не было, не было бы Ruby

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

VD>>Не. Не скажи. Я как бы знаком с другими языками и знаю насколько более громоздким получается код на них.

FR>Ты вроде раньше говорил что это неважно

Где?

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

FR>Я думаю полно задач где динамика лучше.

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

Единственный скриптовый язык который я использовал за последние 5 лет это StringTemplate. И то подумываю как бы Немерле снабдить поддержкой такой же фичи но разбирающей строку во время компиляции.

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

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

VD>>>Не. Не скажи. Я как бы знаком с другими языками и знаю насколько более громоздким получается код на них.

FR>>Ты вроде раньше говорил что это неважно

VD>Где?

Когда мы с тобой про питон vs C# беседовали

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

FR>>Я думаю полно задач где динамика лучше.

VD>Динамики в дотнете хоть отбавляй. Среда то компонентная. Ну, и если вдруг понадобится динамический язык, то без проблем можно воспользоваться одним из скриптов совместимых с дотнетом. Вот только за 5 лет еще ни разу не понадобилась.

Так тебе и функциональщина раньше не нужна была, а появился немерле понадобилось

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

FR>Когда мы с тобой про питон vs C# беседовали

Хм. Меня не устраивает сокращение кода если он при этом станет медленее или проверки будут отложены до рантайма. Так что Питон и Руби это несколько иной случай. Я не против их краткости. Я против того, что за эту краткость приходится слишком дорого (по крайней мере для меня) платить. По этому подход ML смело утащенный Немерлом мне очень даже по душе.

FR>Так тебе и функциональщина раньше не нужна была,

Серьезно? Где я такое говорил?

FR>а появился немерле понадобилось

И это тоже заблуждение. Функциональщика в некоторых ее проявлениях мне нравится. Вот только как и в предыдущем случае (с Питоном и Руби) она не явлется единственным фактором. Мня не радует идея, что мне прийдется все писать в функционалном стиле, или что императивный стиль будет выглядить более убого. Мне хочется иметь язык поддерживающий множество парадигм. Причем поддерживающий максимально качественно.

Собственно поддержка функционашьщины появилась еще в C# (даже в 1.0, а уж в 2.0 и подавно). Была она, правда в изрващенном виде, и в С++. Но конечно назвать поддержку ФС в этих языках идеальной язык не поворачивается.

Немерле просто явился решением которое отлично интегрировало ФС в ООЯ. В купе с макросами вообще изумительно получилось.

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

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

FR>>Когда мы с тобой про питон vs C# беседовали

VD>Хм. Меня не устраивает сокращение кода если он при этом станет медленее или проверки будут отложены до рантайма. Так что Питон и Руби это несколько иной случай. Я не против их краткости. Я против того, что за эту краткость приходится слишком дорого (по крайней мере для меня) платить. По этому подход ML смело утащенный Немерлом мне очень даже по душе.

Быстродействие я думаю проблема решаемая (и начала решатся уже сейчас, например авторы psyco, jit компилятора для питона, работают над своей реализацией языка, и обещают что ядро сразу написаное с расчетом на jit, даст скорость близкую к компиляторам) к проверкам в динамике просто другой подход.

FR>>Так тебе и функциональщина раньше не нужна была,

VD>Серьезно? Где я такое говорил?

Такой тон у тебя был раньше, у меня кстати тоже

FR>>а появился немерле понадобилось

VD>И это тоже заблуждение. Функциональщика в некоторых ее проявлениях мне нравится. Вот только как и в предыдущем случае (с Питоном и Руби) она не явлется единственным фактором. Мня не радует идея, что мне прийдется все писать в функционалном стиле, или что императивный стиль будет выглядить более убого. Мне хочется иметь язык поддерживающий множество парадигм. Причем поддерживающий максимально качественно.

Ты самое важное забыл (с которого и начинается большинство споров): "и нравящегося лично тебе"

VD>Собственно поддержка функционашьщины появилась еще в C# (даже в 1.0, а уж в 2.0 и подавно). Была она, правда в изрващенном виде, и в С++. Но конечно назвать поддержку ФС в этих языках идеальной язык не поворачивается.

Ну так можно сказать что и си в нектором роде "подерживает" функциональщину (кстати пробовал писать на си кое-что с рекурсией и без модификации переменных, вроде получается, и даже неплохо оптимизируется современными компиляторами)

VD>Немерле просто явился решением которое отлично интегрировало ФС в ООЯ. В купе с макросами вообще изумительно получилось.

Немерле согласен интересная штука, но я пока почему-то никак ни могу начать его серъезно ковырять

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

FR>Быстродействие я думаю проблема решаемая (и начала решатся уже сейчас, например авторы psyco, jit компилятора для питона, работают над своей реализацией языка, и обещают что ядро сразу написаное с расчетом на jit, даст скорость близкую к компиляторам) к проверкам в динамике просто другой подход.

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

FR>>>Так тебе и функциональщина раньше не нужна была,

VD>>Серьезно? Где я такое говорил?

FR>Такой тон у тебя был раньше, у меня кстати тоже

А тебе не кажется странным, что я просто буквально пробил создание на РСДН форума "декларативное программирование"?

Я как раз очень даже за использование ФС, но разумного, без зацикливания на нем.

VD>>Мне хочется иметь язык поддерживающий множество парадигм. Причем поддерживающий максимально качественно.

FR>Ты самое важное забыл (с которого и начинается большинство споров): "и нравящегося лично тебе"

Это связанные вещи.

FR>Ну так можно сказать что и си в нектором роде "подерживает" функциональщину

Ага.

VD>>Немерле просто явился решением которое отлично интегрировало ФС в ООЯ. В купе с макросами вообще изумительно получилось.

FR>Немерле согласен интересная штука, но я пока почему-то никак ни могу начать его серъезно ковырять

Я вот пытаюсь. Но времени катастрофически нехватвает.

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

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

FR>>Быстродействие я думаю проблема решаемая (и начала решатся уже сейчас, например авторы psyco, jit компилятора для питона, работают над своей реализацией языка, и обещают что ядро сразу написаное с расчетом на jit, даст скорость близкую к компиляторам) к проверкам в динамике просто другой подход.

VD>Дык, я тебе скажу чем это закончится. Они ничего путного не сделают. Знаешь почему? А потому, что базы нет. Немерле и есть эдакий Питон спроектированный в рассчете на компиляцию. Ну, просто ребята не заморачивались конкретно на Питоне, а просто брали лучшее из других языков. Но получилось нечто очень похожее на описываемый тобой статический Питон. Ну, разве что со скобками и более функциональный, что ли.

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

FR>>>>Так тебе и функциональщина раньше не нужна была,

VD>>>Серьезно? Где я такое говорил?

FR>>Такой тон у тебя был раньше, у меня кстати тоже

VD>А тебе не кажется странным, что я просто буквально пробил создание на РСДН форума "декларативное программирование"?

нет

VD>Я как раз очень даже за использование ФС, но разумного, без зацикливания на нем.

Ты осторожнее, оно затягивает

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

FR>Со скобками это уже лисп

Дык скобки не той системы. Они фигрные и польская нотация не приветствуется.

FR>Я бы не стал пророчествовать, у них вполне может получится.

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

Так вот разумной альтернативой интерпритации, "утиным историям", и прочим прелестям того что называется скриптами является использование вывода типов и обощенного программирования.

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

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

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

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

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

А виной тому порочность самой идеи. Нужно проектировать и язык, и джитер одновременно. Тогда все будет пучком. А пытаться заставить динамический язык компилироваться так же как С/С++ занятие не благодарное.

FR>А немерли с питоном трудно сравнивать, даже в плане возможностей, слишком разные.

Что же трудного? Есть задачи которые можно решить на Питоне, но нельзя на Немерле? Таких задач нет. А писать на Неперле не сложнее чем на Питоне.

Ну, да если тебя сложно сравнивать с Немерле. Сравни с тем же boo. Это уж точно клон Питона.

VD>>Я как раз очень даже за использование ФС, но разумного, без зацикливания на нем.

FR>Ты осторожнее, оно затягивает

Да, я то, что. Это ты осторожнее...

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


FR>>Я бы не стал пророчествовать, у них вполне может получится.

VD>Я только делаю предположение. Но основания довольно серьезные. Они изобретают велосипен не с того конца. Они взяли за основу язык не преспособленный для компиляции и пытаются его преспособить.

VD>Так вот разумной альтернативой интерпритации, "утиным историям", и прочим прелестям того что называется скриптами является использование вывода типов и обощенного программирования.

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

VD>При разработке компилируемого Питона его разработчики должны будут неминуемо прийти к этому. Но прийдут они к этому не с того коца. Они получат монстрва вместо того чтобы оплучить чистое основанный на грамотной модели решение.

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

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

Они не пытаются делать Boo, это совсем другое.

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

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

В реальных программах каждая строчка тип ни меняет, так что все разрешимо.

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

посмотрим.

VD>А виной тому порочность самой идеи. Нужно проектировать и язык, и джитер одновременно. Тогда все будет пучком. А пытаться заставить динамический язык компилироваться так же как С/С++ занятие не благодарное.

Не ты не прав из этой идеи вытекает очень интересная и сложная задача

FR>>А немерли с питоном трудно сравнивать, даже в плане возможностей, слишком разные.

VD>Что же трудного? Есть задачи которые можно решить на Питоне, но нельзя на Немерле? Таких задач нет. А писать на Неперле не сложнее чем на Питоне.

Да ну? Любые задачи можно решить на любом Тьюринг полном языке.
Вопрос только в сложности решения. Так вот я как раз не увидел задач решение которых упростилось бы при переписывании с питона на немерле.

VD>Ну, да если тебя сложно сравнивать с Немерле. Сравни с тем же boo. Это уж точно клон Питона.

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

VD>>>Я как раз очень даже за использование ФС, но разумного, без зацикливания на нем.

FR>>Ты осторожнее, оно затягивает

VD>Да, я то, что. Это ты осторожнее...