Maxmaxmахimus,
А не лучше ли прототип объектом присвоить.

/**
 * Переключатель.
 * Имеет 2 состояния.
 * Если включен, то возвращает хранимое значение,
 * если выключен, то возвращает undefined.
 * По умолчанию включен
 *
 * @param value - значение
 * @constructor
 */
function Toggle ( value ) {
    this._state = true;
    this._value = value;
}
Toggle.prototype = {
 on : function() {
    this._state = true;
 },
 off : function () {
    this._state = false;
 },
 toggle : function () {
    this._state = !this._state;
 },
 state : function () {
    return this._state;
 },
 value : function ( value ) {
 
    if (  arguments.length < 0 ) {
        this._value = value;
    }
    else if ( this._state ) {
        return this._value;
    }
 }
}

Я пишу код понятный для меня. Как мне удобно. Какой смысл писать весь код в сточку, а потом когда он работать не будет, копаться в соей писанине в поиске ошибок?

поясни и первое, и второе.

что тут не так ?

function a(b){ 
  this.b = b; this.scream(); 
}

a.prototype = { 
  scream: function(){
    alert(this.b + ", World!")
  } 
};

new a("Hello");

код из твоего примера:

Hash.prototype.keys = function () {
	var elements = this._elements,
		keys = [];

	for ( var key in elements ) if ( elements.hasOwnProperty( key ) ) {
		keys.push( key );
	}

	return /*массив ключей*/;
};

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

А что быстрее, хранить имена всех свойств в массиве и когда нужно делать перебор циклом for, или юзать for-in

Hash.prototype.keys возвращает массив. не нужно делать перебор.

for по массиву быстрее, чем for-in по объекту.

если ты на серъёзе собираешься оставить эту строчку, то IE7, IE8, Opera будут срать кирпичами при каждом вызове keys.


Ы. тут ситуация такая же, как и у свойства length у массивов в старых браузерах (напомню, он не кешировался)

return cached_keys;
// vs
for(i in elements) keys.push(i);
return keys;

ты так думаешь? "просто вернуть" и "перебрать".
у тебя все операции с элементами сделаны через высокоуровневые методы. при добавлении элемента просто увеличиваешь цифру количества элементов на один.
при добавлении добавляешь в кэш. при удалении - удаляешь. это все операции с изменением кеша.

PS. а давай протестируем Hash на больших данных? что голословить...

Ещё такой вопрос: что считаете правильнее, использовать замыкания или _доверится _соглашению _программистов?

тут надо всё взвесить. лучшего варианта нет.

• устойчивость кода к воздействиям извне
  замыкания

  если код не дает возможности изменить её, то её не изменить, т.е. устойчивость высокая.

  соглашение

  можно изменить, как и любое свойство (конечно, если не запретить изменение\конфигурировани� � свойства в дескрипторе)

• простота использования
  замыкания

  
  новичкам бывает трудно понять замыкания. после осознавания сути они становятся обычным приёмом
  

  соглашение

  
  легче, чем замыкание. тут присутствует сходство с обычным ООП.
  

• сжимаемость кода
  замыкания

  отлично сжимаются, как обычные локальные переменные

  соглашение

  
  после сжатия в GCC в advanced mode могут возникнуть проблемы, если такие приватные свойства будут переименовываться минификатором.
  если сохранять имена - то может страдает качество сжатия кода.
  

я, вероятно, не всё учел. пишите, может быть, добавлю в ФАК .

что скажите на этот счет? (от поста по ссылке, до конца темы)

Функция inherit для эмуляции Object.create(proto)

Хороший вопрос.. Определить бы :)