Самовызывающийся конструктор Джона Резига и размышление о том, почему это решение не прижилось

определяемый этой библиотекою конструктор называется (очевидно, для краткости) просто «L» — а не «Leaflet», например. Шесть букв экономятся. Но ведь можно, можно было бы сэкономить ещё четыре символа

Зачем, зачем подменять собою функции минификатора?

В atom.Class есть статический метод invoke. Как-то так:

var MyClass = atom.Class({
	Static: function () {
		invoke: function () {
			// source here
		}
	}
});

Эта функция отвечает за то, что произойдёт при вызове класса как функции без «new». По-умолчанию это создание класса, такое поведение, как описанное в топике, но иногда поведение альтернативное.
Но иногда поведение меняется. Вспомним оригинальный JavaScript и разницу между следующими строчками:

var number =     Number(arg);
var number = new Number(arg);

var string =     String(arg);
var string = new String(arg);

Интересно, что вызов метода без new ознатает приведение, а не создание. Я часто пользуюсь этой же техникой. Например, когда метод может получить объект, похожий на точку. Это может быть массив [x, y], может быть объект с полями {x, y}, а может быть и собственно Point. Если пришёл объект или массив, то из него создаётся точка, а если точка, то она не создаётся, а возвращается существующая. Таким образом имеем код:

var source = new Point(3, 4);
 
var clone  = new Point(source);
var same   =     Point(source);

console.log(
	clone == source, // false
	 same == source  // true
);

Идея, в общем, в том, что вызов с new и вызов без new могут оба использоваться для создания изящного api библиотеки.

Отсутствие arguments.callee — совершенно не проблема. Просто нужно использовать named function expression:

function makeClass(){
return function Constructor(args){
if ( this instanceof Constructor ) {
if ( typeof this.init == "function" )
this.init.apply( this, arguments );
} else
return new Constructor( arguments );
};
}


Пара простых правил, которые искореняют всякие непонятки:
1. JavaScript надо не просто знать, его надо понимать.
2. Долой привычки, надо читать докуметацию/код, раз уж решили использовать чужую работу.
3. Надо думать головой а не одним местом.

В защиту new надо сказать такие слова.
В программистской среде существуют «мемы» — уловимые глазом сокращения понятий. Мемов для понятия «создать экземпляр класса» существуют 2 основных: оператор new и функция или метод create(). Причём, программисты-идеологи типа Крокфорда более склонны поддерживать второе. Это упрощает работу: если в тексте увидел new или create, то здесь встретится конструктор. Если мы введём допустимость конструктора без этих слов, мы усложним работу для других по чтению своего кода в дальнейшем. Правда же, код будет иезуитским, если j7() — конструктор, а j91() — функция?

По arguments.callee — совсем другая история. Её неперевариваемость лучше всего, хотя и не досконально, объясняют эти комментарии: habrahabr.ru/blogs/javascript/130713/#comment_4334433, stackoverflow.com/questions/103598/why-was-the-arguments-callee-caller-property-deprecated-in-javascript — в 2 словах — нет явного вызова функции как самой себя. Это также усложняет авто-оптимизацию, хотя это другая сторона проблем.

Сокращение корневых объектов — третья история. Здесь совсем не о чем спорить — корневые объекты стараются сделать покороче, потому что их чаще всего в коде приходится писать. $, ext, qx, GA, GP_… (последнее — от Google+). Но это не повод сокращать мемы и вообще сокращать (не в целях обфускации) нечто узнаваемое (document, window, addListener, .next()...).

А потом куча народу пишет на JQuery и не знает, что

$(this) !== $(this);

это два разных обьекта.

На самом деле эта проблема не специфична для JavaScript, она универсальна: стоит ли пытаться предотвращать некоторые типы ошибок и какой ценой это допустимо делать? Философский вопрос без правильного ответа — нужно искать идеальный баланс, а он в разных случаях будет разным.

Мой ответ на этот вопрос звучит так: я разделяю интерфейсы на внешние (публичные) и внутренние.

На внешних должна быть реализована максимально возможная защита «от дурака» (a.k.a. «от хакера» a.k.a. полная валидация входных данных), при этом предпочтительнее не исправлять молча ошибки (создавая объект на лету при вызове без new) а отказываться работать и выдавать ошибку.

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

Мне эта проблема кажется проблемой, стоящей рядом с проблемой нулевого указателя в Си, т.е. делают кучу обёрток, механизмов, усложнений. А ведь это по сути дело стиля написания и аккуратности.
Простое отличие: конструкторы называть с большой буквы, методы с маленькой. Ошибся — сам себе бяка.
Единственный механизм защиты, который должен быть — выброс исключения при вызове конструктора без new.
Конечно есть исключение — внешний интерфейс сложных библиотек. Там может быть оправданным показанный в статье механизм, но я предпочту этому хорошую документацию.

В книге «JavaScript шаблоны» все эти мелочи разжованы.

Иногда мне хочется думать, что Джон Резиг поступил бы дальновидно, кабы вовсе воздержался от arguments.callee, ограничившись только наглядным примером

Аналог можно реализовать и без arguments.callee:

'use strict';
function makeClass() {
  var newClass;
  var factoryIndicator = {};
  return newClass = function(isFactory, args) {
    if (this instanceof newClass) {
      if (typeof this.init == 'function') {
        this.init.apply(
          this, (isFactory == factoryIndicator) ? args : arguments);
      }
    } else {
      return new newClass(factoryIndicator, arguments);
    }
  };
}

Спасибо за упоминание Leaflet. :)

Насчёт L вместо Leaflet — как уже прокомментировали выше, тут различие только в названии переменной, в случае же с new меняется семантика кода. Я предпочитаю, чтобы различие между созданием объекта с помощью определённой функции в качестве конструктора и просто вызовом функции было явным, а не скрытым какими-то магическими конструкциями — как по мне, это делает код более читабельным и понятным, особенно людям, привычным к активному применению ООП.

Я уверен, что настоящие ООПшники никогда не используют методы Array.concat и Array.slice, ведь они неявно создают новый объект и не обозначены как конструкторы. И в своих программах никогда не возвращают из функции объекты, созданные в этой функции, а всегда принимают в параметрах объекты, которые нужно модифицировать, чтобы пользователь в явном виде вызывал new и никогда не забывал, где чего и сколько он создал.

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