Цепочка функций
 

Сделал аналог цепочек jQuery.

код:

(function(){

var 
    window = this,
    undefined,

    jQuery = window.jQuery = window.$ = function( selector, context ) {
        return new jQuery.fn.init( selector, context );
    };

jQuery.fn = jQuery.prototype = {
    init: function( selector, context ) {

        // Если selector - объект, возвращаем его
        if ( selector.nodeType ) {
            this[0] = selector;
            return this;
        }

        // В противном случае берем элемент по id
        var elem = document.getElementById( selector );
        var ret = jQuery( elem );

        return ret;
        
    },

    // Наши функции
    raz: function() {
        this[0].innerHTML += 'первая пошла, ';
    return this;
    },
    
    dva: function() {
        this[0].innerHTML += 'вторая пошла, ';
    return this;
    },
    
    tri: function() {
        this[0].innerHTML += 'третья пошла ';
    return this;
    }
};

jQuery.fn.init.prototype = jQuery.fn;

})();

sample:

<div id='sampleid'></div>
    <script type="text/javascript">
    
        $('sampleid').raz().dva().tri();

    </script>

Можно ли использовать такую реализацию цепочек? Какие могут возникнуть проблемы?

что-то куча связей fn-init-prototype и ненужных оберток

function $(…) {
    return new $.wrapper(…);
}

$.wrapper = function (…) {
    this… = …;
};

$.wrapper.prototype = $.prototype = {
    constructor: $,
    raz: …,
    dva: …,
    tri: …
};

Проблем вроде нет, если удобно, ни что не мешает использовать.

Зачем это?

Это из jQuery

var 
// Will speed up references to window, and allows munging its name.
window = this,
// Will speed up references to undefined, and allows munging its name.
undefined,

Тот, кто это написал (я не знаю, Резиг или нет) не понимал две важные вещи:

1. Самое главное - если он вызывает в дальнейшем код в контексте this, который был присвоен изначально в локальную переменную window (т.е. глобальный объект), то this - всегда будет работать быстрее, т.к. this не резолвится вообще, он определён единожды при входе в контекст, а вот локальная переменная window будет резолвится всегда при обращении. Так что, здесь имеет место быть явное недопонимание, как и почему "оно" так работает.

2. Есть принципиальная разница между объектом window и глобальным объектом (this в глобальном контексте - есть глобальный объект). Первый - это хост-объект, второй - это нативный объект. Да и не всегда, window - рекурсивная ссылка на глобальный объект; в некоторых реализациях это не так (хотя в стандарте - и в 3-ей, и в 5-ой редакциях это отмечается).

А тут, получается, автор этого кода сохраняет в локальную переменную глобальный объект (т.е. уже меняет поведение, которое было бы у хост-объекта windiow), и, наивно думает, что это что-то ускорит. Наоборот.

Если бы он сделал var window = window, было бы другое дело. А в его случае, удобней было бы всегда использовать this, который был бы определён только один раз, а не постоянно, как window.

Спасибо.
А разработчикам jQuery это никто не смог объяснить?

те кто юзают jQuery вобще походу не смотрели исходники... вот и юзайте дальше....

Что касается данного выражения, думаю это было сделано из учета обращения к глобальному объекту в коде фреймворка, где this - не является глобальным объектом, пример:

1) Тут вполне можно вместо window поставить this
2) В данном случае, window ссылается на Global, а вот this уже на jQuery (или я не прав? =) ), но вот я так и не понял, для чего реализована функция noConflict
3) И тут понятное дело, this уже не указывает на Global
Возможно я и ошибся, но введение данной переменной было необходимо, но в кое каких местах можно было обойтись без нее, но вот вопрос, а на сколько бы изменение в первом примере window на this дало бы выигрыш? может быть он настолько маленький, что разработчики jquery забили на него болт? =)

кстати, присоединяюсь к PeaceCoder, по поводу использования фреймвороков, порой зайдешь на форум, что бы найти алгоритм решения определенного вопроса, и порой появляется отвращения от всех тем(даже в разделе "для профи"), так как все только и знают, как решить вопрос с помощью фреймворков, а где же чистый javascript, про который наверно уже все забыли...а может и вообще не знали, в итоге появляется стада баранов, а не программистов, у которых спросишь "А ты знаешь javascript?" а они ответят: "да, конечно, это же jQuery", прям даже страшно становиться ))))

если не вводить переменную window, которая покроет глобальный обьект window, то где бы ты не обращался к window - он и в африке будет window. для этого надо знать что такое область видимости переменных и как она работает.
согласен на все 100%. иногда сталкивался со знатоками фреймворков и когда начинаешь с ними разговаривать на эту тему аж отвращение появляется что к фреймворку, что к самому человеку, который не хочет понимать, что ты ему обьясняешь/говоришь.
фреймворки vs. JS это тоже самое как Assembler vs C++ или C++ vs VisualBasic
Как можно доказывать что высоко уровневый язык быстрее своего родителя? А таких не мало...

благодарю за поправку, область видимость переменных то знаю (за что спасибо Dmitry A. Soshnikov), но вот сглупил и забылся из-за малого опыта программирования на JS.

имхо, таких людей лучше обходить стороной, толку от них мало, а мозг и нервы потреплют хорошо :)