Нужно сделать конструктор, содержащий другой конструктор, так, чтобы объект второго можно было создавать через вызов соответствующего метода объекта от первого конструктора.

Что-то типа вот этого,



или




но что бы работало. Почему ни один из этих двух кодов не пашет?

Урааа, нашёл решение!



Всем спасибо за внимание

Greendrake, зачем это?
Любая функция (метод) может быть конструктором, что ты и сделал, определил функцию и запользовал её как конструктор. Можешь и как простой метод вызват, будет this текущим обьектом (object1)

Советую определять методы в прототипе, всё таки логичней создавать одну функцию на все обьекты, чем каждому по closure (когда в конструкторе), да и памяти меньше хавает. Пример:



Можно узнать задачу где это понадобилось? Просто логики мало, возможно ты хотел представить вложенный класс как в Java, но в Java механизм совершенно другой, там вложенный не статический класс имеет доступ до полей внешнего класса (обьекта), что удобно например для построения эффективных итераторов. Только JS это не Java, здесь это можно сделать проще

Конечно.

Я разрабатываю свою CMS. На произвольно запрошенной странице могут находиться совершенно различные блоки (DIV, table - не важно). Где-то будут одни и те же, где-то разные. Многие блоки будут динамическими, т. е. иметь свой "обслуживающий их" JavaScript. Также нужно организовывать взаимодействие этих блоков. Мне показалось вполне логичным решением для каждого динамического блока создать конструктор и инициализировать соответствующий одноимённый объект.

Так вот одним из этих блоков является так называемый RequestDiv. Неотображаемый див, использующийся для временного хранения текстовых результатов запросов по XMLHTTPRequest. Он инициализируется в виде объекта. Сам див - одно из его полей. Я решил что будет логично, если объект XMLHTTPRequest будет каждый раз создаваться НЕ некой глобальной функцией getRequestObject, а конструктором внутри этого RequestDiv. Раскритикуйте, если это не логично / не верно / не оптимально.



Допускаю, что буду послан использовать решение от Котерова, но мне такая громоздкая штука не нужна, т. к. ориентируюсь тока на последние браурезы.

Это сообщение отредактировал(а) Greendrake - 23.2.2006, 17:03

Впрочем ладно, я уже передумал . Я просто сразу не додумался, что вовсе не обязательно сразу в страницу втыкать неотображаемый DIV: его можно создать динамически и пользоваться им, не привязывая его к странице вообще. Поэтому и необходимость вложенных конструкторов отпала (пока ). Вот:



Что любопытно - в строчке 13 внутри алерта this воспринимается по-разному в Опере и Лисе. Так, в Опере this в этом контексте - сам XMLHttpRequest, и в алерте выдаётся его readyState. В Лисе этот this - сама функция - обработчик onreadystatechange. В IE этот this - некий объект, какой не понял (но, по-видимому, то же что в Лисе). Как быть?

Это сообщение отредактировал(а) Greendrake - 23.2.2006, 17:37

Может быть громоздко, если типов блоков много.

Greendrake, Скажи мне, зачем тебе RequestDiv? он создает XMLHttpRequest, затем отдаёт его тебе, где ты сам работаешь с onreadystatechange и т.д. А не проще ли было:


Такой код удобней, не нужно ничего знать о XMLHttpRequest, просто знаем что пришла инфа - всё ОК, пришло null - была ошибка. Вложенный closure "видит" все переменные выше по контексту где был определён, потому не нужно записывать все необходимые переменные в поля временного обьекта, как ты бы это сделал в Java.
Если подход понравился, покажу как реализовать


Необходимости во "вложенных конструкторах" никогда не было, такого термина в JS даже нет Определяй методы обьектов в prototype, помни что это не классы Java. Каждый раз определяя методы в конструкторе ты создаёшь новые обьекты-функции (closures) для каждого создаваемого обьекта, это не экономно в памяти, да и просто не красиво. И вообще совет, освободи своё сознание от впаянного тебе ООП из Java, писать "настоящим ООП" можно проще, без шаманских трюков

Но ведь по-любому не более громоздко, чем если весь JS, обслуживающий все возможные блоки, пихать в один файл в виде безвкусного набора глобальных функций? Надоела мне эта каша, хочу структурированности и логической стройности. "Эффективных интерфэйсов", панимаеш .



Собственно я и заварил кашу чтобы не вспоминать про XMLHttpRequest, и от работы с onreadystatechange пытался уйти. Благодарю за пример, попробую переварить и реализовать, если что не получится, буду просить помочь...



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

А я Java вообще не знаю кстати . Моё ООПшное сознание ещё формируется, отовсюду по чуть-чуть .

не совсем, в конструкторе ты иницализируешь обьект, document.getElementById необходимые элементы, создаёшь чего специфичное для конкретного обьекта. Интерфейс же обьекта (его методы), определяем в прототипе, тогда да, физически на все обьекты будет один экземпляру функции на каждый метод.
Добавлено @ 11:35

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

P.S. сам "фанат" ООП, но после не малого опыта со скриптовыми окружениями понял где она граница между логикой и "фарисейством"