> Тем более в библиотеках.

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

http://bit.ly/Q9uqxR

Потому что у меня сложилось впечатление, что тебе это не нужно. Тем более что пользоваться ты этим точно не будешь. Соответственно, для меня это пустая трата времени.

Мир не идеален, да...

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

А по факту ты окончательно слился, ты сказал много слов, пытался кого то троллить, а в итоге затроллил себя сам, твои доводы никому не интересны и собеседник ты скучный, т.к. глупый и не видишь ничего дальше своего носа. Прими это как факт и иди займись чем нибудь общественно полезным, шкет:)

> http://bit.ly/Q9uqxR

по какой из ссылок полученных по запросу "best practice xslt" я смогу найти описание упомянутого тобой "layout" в правильной интерпретации?

> Потому что у меня сложилось впечатление, что тебе это не нужно. Тем более что пользоваться ты этим точно не будешь.

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

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

ты писал много псевдокода, и копипастил левые примеры из документации.

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

Пример, этой лёгкой реализации наверно бессмысленно просить?

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

Запрос "временные деревья в xslt" выдает более релевантные результаты. Есть несколько статей у Лебедева на эту тему.

> Запрос "временные деревья в xslt" выдает более релевантные результаты.

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

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

Нет, просто ты не понимаешь, что я имею ввиду. Ну да ладно.

Я в курсе как оно реализуется, спасибо.

kobezzza, хочу попробовать заюзать вашу разработку в своей. Список задач:
1. Хочу сделать undo/redo хранилище со следующими полями:
[действие, диапазон изменяемых данных, данные(Array или JSON), диапазон отката]
2. Хранение лога действий.
Основной компонент работает на jQuery
Сложных выборок не будет, надо получать и сохранять данные.

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

А может быть для моих задач и не нужен Collection?

Спасибо.

Либа однозначно интересная и перспективная, особенно для тех кто делает клиентские приложения. ИМХО.
Советую также сайт и доки перевести на инглиш и запостить где-то на SO например.

antonM завтра будет статья на сайте, которая ответит на все вопросы :)
Разумеется Collection не обязателен, но с ним эту задачу можно будет сделать быстрее:)

Я думаю о переводе сайта на инглиш, но пока времени не хватает.

Закончил работу над первой минорной версией ветки 3.8.x - 3.8.1!
Несмотря на маленькую цифру данное обновление действительно включает в себя много улучшений:
1) Проведена оптимизация конструктора, теперь его создание крайне мало времени, по наставлению B~Vladi второй параметр конструктора был выпилен для оптимизации работы в V8;
2) Очень сильно оптимизирована логика работы всех итеративных методов, теперь в браузерах, где интерпретатор не умеет развёртывать Array.forEach и т.д. (на данный момент развёртывать нормально forEach может только ИЕ10) скорость работы Collection.forEach в некоторых случаях превышает нативную браузера (в 1.5-2 раза);
3) Практически полностью переписан модуль компиляции фильтров, теперь простые строковые сокращения (состоящие из 1-го фильтра) по скорости почти равны явным функциям, работы составных фильтров ускорена почти в 10 раз!
4) В метод forEach добавлена стратегия анализа фильтров: в зависимости от фильтра метод выбирает наиболее оптимальную стратегию работы, что даёт сильный прирост производительности в некоторых случаях;
5) Исправлено множество ошибок версии 3.8.

:blink:
Вот это хорошее обновление :)

Эх сегодня видимо не судьба закончить с докой :( Завтра надеюсь допилю всё

kobezzza,
каким законам подчиняется нумерования версий ?

Первая версия означает очень сильные, затрагивающее всю библиотеку в целом, во всяком случае так было 4-и версии подряд (0, 1, 2, 3), т.к. я пишу её почти стока же, сколько пишу на ЖС, то каждую версию я переписывал почти с нуля, пробуя новые решения и архитектуры. Сейчас первая цифра просто означает мажорный апдейт. Вторую цифру в принципе можно приравнять к первой, но раз уж так сложилось исторически, то пускай так и остаётся. Вторая цифра - мажорный апдейт, в включающий в себя "новые фишки", фишки которые будут добавляться от версии к версии расписаны в моём roadmap, так например по плану в 3.9 должно добавится 2 мощных нововведения: поддержка хранилищ больших данных и поддержка множества сторонних шаблонизаторов. В 4-й версии всё внимание будет сконцентрированы на автоиндексах, картах взаимоотношений и поддержкой параллельных операций (веб воркеры). Минорные апдейты (3-я цифра) как правило несут в себя исправления ошибок и различные оптимизации, но изредка я добавляю новые микро фишки, тогда в таком случае к последней версии я прибавляю 0.0.2, а не 0.0.1.

Даты выхода версий плавают, т.к. я веду разработку либы в свободное от работы время, а работы у меня 2: Яндекс и мой личный стартап (находится в разработке), поэтому например летом я почти не работал над ней. Пока у меня как минимум есть идеи насчёт 3-х мажорных версий, что будет дальше я не знаю, но вероятность того, что я заброшу разработку маловероятна, т.к. для меня эта либа имеет особое значение:)

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

Эх чёто я окончательно увяз, адская это работа делать нормальную доку.
antonM дабы не ждать, пока я всё рожу, сразу расскажу про то, как сделать свою сборку:
1) Ставим на компьютер Git (если есть, то можно пропустить);
2) Ставим на комп Java и Node.js (если есть, то можно пропустить);
3) git clone https://github.com/kobezzza/Collection.git
4) Открываем files/core.js

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

//#include

или так:

// #include.

Если нужен модуль с определённой настройкой, то ставим флаг, например:

//#include ./drivers.js::DOM_jQuery

.
Если нужен модуль с базовой настройкой, то, например,

//#include ../mult/mult.js::base

.
(описание сборщика, https://github.com/Kolyaj/BuildJS)

Минимальная сборка с SQL интерпретатором (с поддержкой старых ИЕ).

//#include ./static.js

// >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
// Драйвера, для взаимойдействия с другими библиотеками:
// 1) DOM (драйвер для работы с DOM):
// 1.1) DOM_qsa;
// 1.2) DOM_Sizzle;
// 1.3) DOM_jQuery;
// 1.4) DOM_dojo;
// 1.5) DOM_MooTools;
// 1.6) DOM_Prototype.
//#include ./drivers.js::DOM_jQuery
// <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

// Реализация методов массивов из ECMAScript5 для старых браузеров
// (флаг сборки: ArrayProto).
//#include ./array.prototype.js

//#include ./prototype.js

//#include ../other/other.js
//#include ../compile/func.js

//#include ../fields/fields.js
//#include ../stack/stack.js

//#include ../single/single.js

// >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
// Методы для итеративных операций:
// 1) Mult_Get;
// 2) Mult_Set;
// 3) Mult_Remove;
// 4) Mult_Search;
// 5) Mult_Map;
// 6) Mult_Move;
// 7) Mult_Group;
// 8) Mult_Stat.
//#include ../mult/mult.js::base
// <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

//#label Sort
//#include ../sort/sort.js
//#endlabel

//#label Local
// #include ../local/local.js
//#endlabel

//#label DOM
// #include ../dom/collection.js
// #include ../dom/compile.js
//#endlabel

//#label Design
// #include ../design/print.js
//#endlabel

//#label Design_Table
// #include ../design/table.js
//#endlabel

//#label CSQL
//#include ../csql/csql.js
//#endlabel

5) Теперь запускаем сборку: compiler.bat (разумеется это под винду).
6) Моно запустить тесты и проверить, что всё ок (tests/index.html).

Для сравнения: в случае PMS сборщика достаточно создать отдельную директорию, поместить туда файлик с расширением .meta.tree и коротким содержанием:
include module= Collection/DOM_jQuery
include module= Collection/csql

потом запустить компиляцию и все необходимые зависимости подтянулись бы автоматом

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

//#include core.js::DOM_jQuery::csql

(зависимости подтянутся)
но у твоего варианта синтаксис по приятней, наверно в будущем так и сделаю

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

Не всё идеально в этом мире:)
Хотя ща, наверно так не получится. В смысле сборщик позволяет, но кривовато зависимости расставлены, нужно будет причесать.

kobezzza, если использовать Collection на сервере, проводили ли Вы какие-либо нагрузочные тесты? Например хранение 2-3 млн. записей типа ключ:значение. Выборка из такого объема, скорость и требования к железу при таких нагрузках?

Использую на серве в качестве стандартного итератора или в качестве memcached, но пришлось сильно попотеть, чтобы всё работало быстро, но в качестве основной серверной БД использовать не нужно, она просто не для этого была создана.

Уже довольно давно в бранче висит новая версия 3.9, в которой был реализован JIT компилятор и работа с indexedDB, но никак не найду время чтобы закончить релиз, т.к. Collection является частью моего другого проекта, на который я сейчас направил все свои силы.

Но если сравнивать по скорости, то версия 3.9 примерно в 4-10 раз быстрее нативных реализаций во всех браузерах. Релиз почти готов, но к сожалению пока нет времени.

Спасибо за ответ, а не подскажите БД под такие объемы информации для Ноды? (у Вас практики поболее)

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

ЗЫ: а вообще сейчас уже есть драйвера под ноду для любых СУБД, если вам например нравится MySQL, то используйте его.

7000 строк

if (!condition) { /*do stuff*/ }
!condition && ( /*do stuff*/ );

!String.prototype.trim && (
	String.prototype.trim = function() {
		return this.replace(/^\s+|\s+$/g, '');
	}
);

там же в лоб все делается, регулярками сто раз по строке пробегаем, все компилируется в js, я думал там все по-честному разбиваем на лексемы, строим синтаксическое дерево, интерпретируем

JSON.parse( JSON.stringify(o) ); это хакирство быстрее чем

function clone(o) {
    if (!o || typeof o != 'object') {
        return o;
    }
    
    var c = o.constructor == Array ? [] : {}, 
        p, 
        v;
    
    for (p in o) {
        if( o.hasOwnProperty(p) ) {
            v = o[p];
            c[p] = v && typeof v == 'object' ? clone(v) : v;
        }
    }
    
    return c;
}

???

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

qwerty-клавиатура, ты вообще о чём?) Для интерпретатора SQL (во всяком случае на таком уровне) нет необходимости строить дерево, но если бы ты внимательно изучил код, то увидел бы что никакой магии регулярок там нет, они используются исключительно для подготовки, а так код SQL преобразуется в последовательность токенов, которая затем выполняется.

Про какие встроенные методы говоришь? Какая потеря производительности?
Как я уже писал выше, в последней версии (3.9) использует специальный JIT компилятор (вот он то и деревья строит и блек джек с инлайнингом делает), что даёт прирост во всех браузерах в скорости минимум в 4 (а в некоторых случаях и в 10) по сравнению с нативными реализациями. Никакой геометрической прогрессии нет. И да, я прогонял на миллиарде.

Ну у меня так и делается.

Вот реализация в исходниках:

Collection.clone = Collection.prototype._clone = function (obj) {
    if (JSON_IS_NOT_DEFINED) {
        throw new Error('Object JSON is not defined!');
    }

    return JSON.parse(JSON.stringify(obj));
};

ЗЫ: не хочу спорить и читать кучи несвязных постов о гадании по коду, задавай конкретные вопросы - я отвечу.

нативные

Ты можешь отвечать нормально?

Ответ гораздо проще, я тупо не заморачивался :) Эта функция вызывается у меня крайне редко при некоторых условиях и такое изменение видимых изменений в скорости не даёт вовсе, вот и оставил так поэтому:)