DisplayObjectContainer как на его основе написать класс?

[Bletraut]

И вообще, зачем вам "писать класс на основе DisplayObjectContainer"?
Вам дали Sprite/Shape/MovieClip - пользуйтесь.

А если я хочу закрытый контейнер?

[Wolsh]

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

Не просто в методах, а в методах Списка Отображения, реализованных в плеере ("на с++"))) Это как интерфейс-метка IBitmapDrawable. Метка, что с этим объектом можно делать то-то и то-то. Ну и прицепом набор стандартных свойств типа ширины и высоты.

А если я хочу закрытый контейнер?

Занимай очередь.

[MikroAcse]

А если я хочу закрытый контейнер?

Боишься своего кода? Если все правильно сделать - "закрытый контейнер" не понадобится.

public class ClosedContainer extends Sprite {
    public function ClosedContainer() { super(); }
    override public function addChild(child:DisplayObject):DisplayObject { return; }
    override public function addChildAt(child:DisplayObject, index:int):DisplayObject { return; }
    override public function removeChild(child:DisplayObject):DisplayObject { return; }
    override public function removeChildAt(index:int):DisplayObject { return; }
}

А внутри класса используешь super.addChild/removeChild.

[Wolsh]

MikroAcse, терпения не хватило переписать ВСЕ методы ДОКа? Там еще много-много вкусняшек, getChildAt(), getChildByName(), numChildren, tabChildren, mouseChildren, contains(), getChildIndex(), getObjectsUnderPoint(), setChildIndex(), swapChildren(), swapChildrenAt().
А теперь представь ту же ситуацию: некто видит что это Спрайт, пихает туда своё чадо и начинает с ним работать как ни в чем ни бывало. Компилятор молчит: вызов методов и свойств абсолютно законный. А в рантайме ошибка едет на ошибке и ошибкой погоняет.
Флэш уже пять лет живет с AS3, и все ништяк. Никто не говорит, что это ужасный баг, который похоронит технологию. Никто не говорит, что надо все бросать и вешать на каждый спрайт по менеджеру. Речь о красоте, как бы пафосно это ни звучало. О том, что Спрайт просто мегаизбыточен. У него полтора десятка публичных методов, убивающих накорню всякую инкапсуляцию. Методов, в 95% случаев не нужных вообще извне. Все они должны быть закрыты так, чтобы при необходимости вы могли создать общий доступ в наследнике. Но не открытый доступ по-умолчанию же! Вы когда класс пишете, старательно закрываете доступ ко всем его внутренностям. Приватные свойства, приватные функции. И только один-два метода сознательно(!) делаете публичными. А в это время в замке у шефа у вашего класса душа нараспашку, и любой объект извне может совершенно спокойно добавлять в него что попало и удалять его внутренние органы без разбора. Все то, на что вы сохраняли ссылки в приватных переменных, легко доступно извне в результате родовой травмы ДОК. И единственный ответ — сделай так, чтоб вся программа ломалась в рантайме, оверрайд же шь! Спасибо, конечно.
Я хочу, чтобы этих публичных свойств и методов НЕ БЫЛО вообще, в принципе. Хочу ДО, который "снаружи" не является контейнером вообще, но внутри дает полное API для работы с собственным списком отображения. Все публичные доступы я смогу написать сам. Мне это понадобится раз в полгода и займет четыре строчки, не родив ни одной ошибки.

[Psycho Tiger]

... А зачем?
Что это за перестраховка от атомных взрывов? Когда я писал только на as3 я тоже болел чем-то таким.
Ошибка в рантайме при дебаге – вполне обычная ситуация. В 9 из 10 случаев эта ошибка не произойдёт если проэксклудить "лишние" с автокомплита. Сразу будет видно, что дёргать. В 1 из 10 случаев словить РТЕ – ну вот совсем не страшно. В Ruby или Python'е можно вообще приватные методы дёргать через :send. И дёргают, и живут, и код настолько красив и отDRYен, что такого в AS3 и встретить нельзя.

Красота – это прекрасно и чудесно. Только это всё таки просто код.

[Final Hope]

Сообщение от Wolsh

Я хочу, Хочу ДО

Wolsh, да всё-всё! Тише-тише! Уже все поняли, чего вы хотите. Вот: http://www.adobe.com/ru/support/contact/ Дело за малым.

Сообщение от Psycho Tiger

Только это всё таки просто код.

Который через сто лет даже в школе читать не будут.)

[Babylon]

Wolsh, я представляю, что мог бы написать про избыточность UI

[Final Hope]

Да весь AS избыточен. В топку его. Машинный код - за ним будущее!

[Tails]

Согласен с Wolsh, что избыточность методов чисто морально напрягает. Там ещё эвент диспетчер не всегда нужен. Но на практике это не приносит проблем, а иногда даже полезно. Вот недавно возился с minimalComps компонентами, пришлось в одном случае сверху насильно выдрать маску из компонента.

[iNils]

Сообщение от Psycho Tiger

... А зачем?
Что это за перестраховка от атомных взрывов? Когда я писал только на as3 я тоже болел чем-то таким.
Ошибка в рантайме при дебаге – вполне обычная ситуация. В 9 из 10 случаев эта ошибка не произойдёт если проэксклудить "лишние" с автокомплита. Сразу будет видно, что дёргать. В 1 из 10 случаев словить РТЕ – ну вот совсем не страшно. В Ruby или Python'е можно вообще приватные методы дёргать через :send. И дёргают, и живут, и код настолько красив и отDRYен, что такого в AS3 и встретить нельзя.

Красота – это прекрасно и чудесно. Только это всё таки просто код.

Давай все будет теперь public и без типизации? Работает и ладно.

Давай серьезно и без деградарующих примеров других языков? А то получается так: был AS1 и все торчало наружу. Появился AS2 и народ обрадовался, что есть классы, типизация, модификаторы доступа (хотя до private можно было легко достучаться через ['имя']). Появился AS3, народ от счастья с ума сходит от возможностей. Но проходит время и Psycho Tiger по сути говорит, что мы мучаемся и надо писать в стили AS1.

Собственно, Wolsh излагает то, о чем я ему душу изливал недели две назад. Я был страшно недоволен отсутствием примитивного контейнера для компонентов. Это не болезнь, это желание иметь законченный и целостный компонент. И не перестраховка от атомных взрывов, а защита от дурака. Я хочу быть уверенным, что мой компонент случайно не сломают добавив туда что нить через addChild. Или что загрузив в компонент свой спрайт, не сломают компонент через parent. И если поломки через addChild и тп, можно защитится через переопределение. То из-за parent придется переопределять все. А можно забить. Или же все реализовать в FP примитивный контейнер, где почти все методы и свойства protected и по необходимости делать реализацию для public. Плохо от этого точно не было бы.