Спасибо, К.О., все мы знаем что такое сеттеры. Только вопрос остался открытым: в чём профит от этого:
...
if ( property === "text" ) {
// то меняем текст кнопки на новое значение
this.node().innerHTML = value;
}
...
И чем оно отличается от этого:
..
setText: function(value) {
// то меняем текст кнопки на новое значение
this.node().innerHTML = value;
}
..
Вообще-то, «километровый switch» можно и не писать. Обычно сеттеров (и геттеров) — один-два на объект. Но если больше — можно сделать объект setters, в котором по имени изменяющегося св-ва будут храниться нужные функции. Тогда достаточно будет просто сделать так: setters[propertyName]().
Тут всё просто:
;var MyClass = (function() {
var _properties = {
'a': 1,
'b': 2,
'c': 'test string'
}
var MyClass = function() {}
MyClass.prototype.property = function(name, value) {
if (typeof name === 'undefined') throw "No name specified"
if (_properties.hasOwnProperty(name)) {
if (typeof value === 'undefined') {
return _properties[name]
} else {
_properties[name] = value
return this
}
} else throw "Property with name '" + name + "' not found";
}
return MyClass
}());
var inst = new MyClass()
inst.property('a') // => 1
inst.property('b') // => 2
inst.property('c') // => test string
inst.property('d') // => "Property with name 'd' not found"
inst.property('a', 10)
.property('b', 15)
.property('c', 'new string')
.property('d', 'fail') // => "Property with name 'd' not found"
inst.property('a') // => 10
inst.property('b') // => 15
inst.property('c') // => new string
inst.property('d') // => "Property with name 'd' not found"
inst.property() // => "No name specified"
Хотя, конечно, это извращение чистой воды. Если есть необходимость «видеть» свойства, то нужно не тратить время на велосипед, а использовать возможности языка и к чёрту инкапсуляцию и всю эту императивщину
Прочитал. В чём профит ваших аксессоров в сравнении с простым обращением к свойствам объекта? Зачем в геттере/сетере писать километровый switch, когда можно просто написать несколько функций/методов(зависит от стиля)?
При наследовании через прототипы все порожденные экземпляры будут использовать общие приватные переменные родительского класса
Чтобы этого не было, не нужно присваивать эти самые переменные контексту родителя:
В своем проекте на этапе разработки использую sprockets – описанной проблемы не возникает, т.к. все шаблоны проходят препроцессинг и передаются в backbone в виде строк без терминальных символов. В продакшн попадает только чистый JavaScript
Небольшая оговорка: я не пытаюсь разжечь холивор, ибо бессмысленно.
Пример можно? Ни разу за 4 года работы с прототайпом не сталкивался с таким.
–когда каждый плагин сидит в своей песочнице и не гадит в общественном месте.
Что такое плагин в понимании JavaScript?
–Идеология модульности и расширяемости
Чем добавление своего метода в prototype объекта не угодило?
И вы действительно считаете подход а-ля джейквери «неявно вернём контекст и применим к нему метод( $(context).myMethod(arg1, arg2) )» нормальным и myMethod.apply(context, [arg1, arg2]) ересью?
Насчёт «понятнее и логичнее». Простой пример:
jQuery.fn.repeat = repeat(num) {
return new Array( num + 1 ).join(this.selector);
}
String.prototype.repeat = function(num) {
return new Array( num + 1 ).join(this);
}
Что понятнее и логичнее?
"lol".repeat(3) //[Prototype style]
или $('lol').repeat(3) //[jQuery style]
И чем оно отличается от этого:
Тут всё просто:
Хотя, конечно, это извращение чистой воды. Если есть необходимость «видеть» свойства, то нужно не тратить время на велосипед, а использовать возможности языка и к чёрту инкапсуляцию и всю эту императивщину
Чтобы этого не было, не нужно присваивать эти самые переменные контексту родителя:
Ваш К.О.
Метод «repeat» возвращает строку, а не объект jQuery.
Теперь про наглядность:
$('header').repeat(2) //-> headerheaderЗдесь контекст становится понятен, только тогда, когда был вызван метод repeat
А если вот так ?:
$('header').animate({'background-color': '#F00'})Я понимаю, что есть гайды от Рейзига, но всё-таки.
Никто не говорит, что расширение прототипа есть панацея. Делать это нужно просто с умом.
В данном примере «человекопонятный» чейн возможен только в случае расширения прототипа:
"lol".repeat(2).repeat(3).repeat(5);А вот так будет у jQ
$($($('lol').repeat(2)).repeat(3)).repeat(5);Думаю нет нужды объяснять, что пример для jQ провалит все тесты.
jQuery.fn.repeat = function(num) {return new Array( num + 1 ).join(this.selector);
}
Пример можно? Ни разу за 4 года работы с прототайпом не сталкивался с таким.
–когда каждый плагин сидит в своей песочнице и не гадит в общественном месте.
Что такое плагин в понимании JavaScript?
–Идеология модульности и расширяемости
Чем добавление своего метода в prototype объекта не угодило?
И вы действительно считаете подход а-ля джейквери «неявно вернём контекст и применим к нему метод( $(context).myMethod(arg1, arg2) )» нормальным и myMethod.apply(context, [arg1, arg2]) ересью?
Насчёт «понятнее и логичнее». Простой пример:
jQuery.fn.repeat = repeat(num) {
return new Array( num + 1 ).join(this.selector);
}
String.prototype.repeat = function(num) {
return new Array( num + 1 ).join(this);
}
Что понятнее и логичнее?
"lol".repeat(3) //[Prototype style]или
$('lol').repeat(3) //[jQuery style]Что плохого в том, чтобы «допилить» стандартные типы js? Б-г запрещает? ECMA запрещает?
Прототайп не столько фреймворк, сколько расширение языка.
parseInt('08', 10) // => 8;parseInt('06', 10) // => 6;
Ваш К.О.
Ваш К.О.