Не совсем так, но вопрос действительно интересный и сложный.
REST постулирует, что сервер должен отвечать за состояние ресурса, в то время как клиент — за состояние «приложения» (=контекст). Если cookies используются в качестве «ссылки» на состояние приложения, хранимое на сервере (например, содержат session_id), то это не RESTful подход (вернее, не совсем RESTful), если же Cookies содержат всю информацию, необходимую для определения контекста, то это вполне RESTful. Потому что запрос клиента должен полностью и однозначно определять контекст, а cookies — это часть запроса.
Для прототипа wrapper можно создать, таким образом, и «холостые выстрелы» исчезнут. Прототип wrapper'a будет указывать на прототип родительского конструктора.
function A() { alerr('A'); }
A.prototype.fn = function () {};
function B() {
B.parent.apply(this, arguments);
alert('B');
}
// связка прототипов для делегирования
var __wrapper = function() {};
__wrapper.prototype = A.prototype;
B.prototype = new __wripper();
B.prototype.constructor = B;
B.parent = A;
var obj = new B(); // alert('A'), alert('B')
В то время, как, если бы не было wrapper'a — alert('A') «выстрелил бы в холостую» когда создавалась цепь наследования.
все как мантру повторяют «наследование, инкапсуляция, полиморфизм» и даже не задумываются о том, что наследование и инкапсулящия противоречат друг другу. наследование — распространённая, но не слишком удачная схема реюзинга кода, порождающая жёсткую зависимость внутренней структуры потомков от внутренней структуры родителя.
штрихи — это подмножество примесей, а примеси — подмножество «множественного наследования», а оно есть подмножество «реюзинга кода». при этом концепции их таковы:
реюзинг — не надо писать одно и то же дважды
наследование — берём существующий класс и хачим его до нужного нам поведения
примеси — создаём класс, примешиваем другой класс с дефолтными реализациями методов и хачим получившегося монстра
штрихи — создаём класс с минимально необходимым интерфейсом, примешиваем другой класс реализующий другой интерфейс на базе нашего.
но основная проблема всех этих «наследований» — потенциальные конфликты интерфейсов. поэтому требуется обеспечивать глобальную уникальнойсть имён методов. у агрегации с этим делом по проще ( obj.width.enlarge() или obj.height.enlarge() вместо obj.enlarge() ), но проблема решается лишь частично…
REST постулирует, что сервер должен отвечать за состояние ресурса, в то время как клиент — за состояние «приложения» (=контекст). Если cookies используются в качестве «ссылки» на состояние приложения, хранимое на сервере (например, содержат session_id), то это не RESTful подход (вернее, не совсем RESTful), если же Cookies содержат всю информацию, необходимую для определения контекста, то это вполне RESTful. Потому что запрос клиента должен полностью и однозначно определять контекст, а cookies — это часть запроса.
function A() { alerr('A'); } A.prototype.fn = function () {}; function B() { B.parent.apply(this, arguments); alert('B'); } // связка прототипов для делегирования var __wrapper = function() {}; __wrapper.prototype = A.prototype; B.prototype = new __wripper(); B.prototype.constructor = B; B.parent = A; var obj = new B(); // alert('A'), alert('B')В то время, как, если бы не было wrapper'a — alert('A') «выстрелил бы в холостую» когда создавалась цепь наследования.
Дело генерации. Или Вы на счетах считаете, а не на компьютере?
Один из лозунгов «какой-то» философии:
штрихи — это подмножество примесей, а примеси — подмножество «множественного наследования», а оно есть подмножество «реюзинга кода». при этом концепции их таковы:
реюзинг — не надо писать одно и то же дважды
наследование — берём существующий класс и хачим его до нужного нам поведения
примеси — создаём класс, примешиваем другой класс с дефолтными реализациями методов и хачим получившегося монстра
штрихи — создаём класс с минимально необходимым интерфейсом, примешиваем другой класс реализующий другой интерфейс на базе нашего.
но основная проблема всех этих «наследований» — потенциальные конфликты интерфейсов. поэтому требуется обеспечивать глобальную уникальнойсть имён методов. у агрегации с этим делом по проще ( obj.width.enlarge() или obj.height.enlarge() вместо obj.enlarge() ), но проблема решается лишь частично…