Нет, у меня цель немного другая.
Грубо говоря объект A сейчас создается один раз и затраты на его создание сейчас большого значения не имеют. А вот объекты типа B будут создаваться регулярно и затраты на их создание мне надо максимально уменьшить. Т.е. минимализировать количество процедур в объекте B и аргументов передаваемых в объект A.

Т.е. надо усложнять объект A, для того чтобы максимально упростить вызов его методов из объектов B. Так-же не будет проблемой если мы усложним конструктор объекта B.

В конце концов, можно добавить какие-то вспомогательные методы в прототип P, через которые я буду оброащаться к объекту A. Но это решение мне уже не нравится, т.к. будет вызывать путаницу. В этом случае уже лучше будет заставлять передавать this, через аргументы.

И в последнем примере у Вас опять this внутри метода объекта A содержит ссылку на "чужой" объект. Меня это решение не устраивает.

чем вам вариант сделать A прототипом объектов B не подходит?
если вам нужен самостоятельный прототип у объектов B, то тогда делаем P прототипом объектов B, а A в свою очередь пусть будет прототипом объекта P

Увы, все не так просто...

Я чуть позже напишу пример того как я пытался решить эту задачу. Но тот пример будет не рабочий. В нем каждый повторный созданный объект затирает предыдущий. Но возможно Вы подскажете как можно в моем примере эту проблему "разрулить".

Если не возражаете, давайте прервем это обсуждение на пару часиков, или, если удобно - до завтра.

no_alex,
та мне-то удобно вообще не решать вашу проблему:wacko:
жду вашего примера. обсудим-попробуем
когда вам удобно, тогда и выкладывайте

JS и так полностью пропитан делегированием. И реализовать именно паттерн "Делегатор" не преставляет труда (что мешает вызвать из a.test() b.test() ?).

Всё-таки, у doesNotUnderstand (Smalltalk), method_missing (Ruby) / __call (PHP), __noSuchMethod__ (JS in Firefox) и т.д. другая цель - выставить последнюю "точку обороны", когда объект (просмотрев всю цепь наследования) не может ответить на сообщение (точно так же, как будто мы открыли неправильный URL - браузер же, всё-таки, отреагировал, выдав нам соотвествующее сообщение). А делегировать или нет в этом методе к другим объектам - это дело десятое.

То, что test может быть любым.

? Ниче не понял =) В паттерне "Делегатор" описывается метод, который вызывает (такой же) метод объекта-делегатора (который может меняться динамически).

В любом случае, __noSuchMethod__ (и иже с ними) тут не при чём (паттерна "Делегатор" это может коснуться только косвенно, т.к. объект может и не делегировать ни к кому, а выполнить какой-нибудь свой другой метод).

И все прекрасно, пока мы знаем имена всех методов, которые могут быть вызваны. Есть у нас допустим объект А, и мы хотим создать для него делегатор Б, который будет как-то изменять вызов некоторого множества методов, а остальные методы должны остаться без изменений. Например, обертка для DOM-узла, которая определяет свои методы, а родные, точнее неопределенные в ней, делегирует DOM-элементу. Такое нереально написать в JS, т.к. руками все методы переписывать нереально и нецелесообразно, а метода а-ля __call нет.

Это и есть паттерн "Делегатор".

А это - обработка события, когда объект не может ответить на сообщение (и как очень частный случай здесь может быть делегация).

Еще раз - под FF - пожалуйста:

var a = {
  __noSuchMethod__: function (id, args) {
    alert('Called: ' + id + ', args: ' + args);
  }
};

a.test();
a.test2(1, 2, 3);

Написать на JS === должно работать везде, где есть JS.