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

[Psycho Tiger]

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

Да не, контейнер с одними приватами был бы кстати. Я не о том говорю или меня не так понимают

Я тут писал-писал, а потом стёр. Увидел, что ты назвал Python и Ruby "деградирующими языками". Видимо, у нас настолько сильно расходятся понятия красивого, что к общему мы никогда не придём.

Я за то, чтобы у языков была невероятная гибкость даже под самые извращенные фантазии, но точно не за то, чтобы язык был одной здоровенной затычкой. Говоря "извращенные фантазии" я подразумеваю только хорошее: содомию можно устроить на любом языке, что не разобраться без бутылки.

[Wolsh]

Гибкость подразумевает что тебе не придется заниматься сомнительным хакингом и кастрировать полтора-два десятка пабликов у класса, играющего основную роль в любом приложении, и делать это всегда, в каждом проекте, потому что "нормальный" нативный класс тебе не предоставили. Речь ведь идет не о замене Спрайта на ЗакрытыйКонтейнер! Спрайт это удобная оболочка чтобы что-то сгруппировать по-быстрому. Он в любом случае должен остаться, даже не говоря о совместимости версий. Речь о том, что нужен ЕЩЕ ОДИН тип-наследник InteractiveObject (а Tails хочет и еще один DisplayObject, то есть без EventDispatcher) c собственным списком отображения. Видимо, это противоречит современному состоянию концепции и реализации СпискаОтображения. Вот только эта концепция напрочь противоречит самим основам ООП. И с точки зрения ООП, красоты и гибкости, AS3 с его единственным дырявым контейнером как раз и является "одной здоровенной затычкой", затыкая любые поползновения сделать грамотно и красиво.
pS. Важен не только результат в виде бабла, когда "работает и ладно". Хочется так же получать удовольствие от качественно сделанной вещи и от процесса ее создания.

Я впервые споткнулся на этой теме, когда захотел наконец написать себе более-менее универсальный Лейаут, систему для автоматического управления расположением и масштабированием любого визуального контента. До этого меня тоже особо не коробило — когда лепишь какие-то конкретные штучки "на раз", всегда сохраняется иллюзия контроля, ты просто знаешь, что "сюда лезть не надо" и вроде бы все в порядке. А здесь вся разработка как раз и была контейнером, принимающим и опекающим детей. Контроль над каждым ребенком являлся самой сутью Лейаута. И проблема бесконтрольного доступа к беззащитным детишкам нарисовалась во всей красе. Точно так же с компонентами, контролами, фреймворками. Как только появляются амбиции сделать какой-то реюзабельный инструмент, облегчающий работу в будущем, ООП перестает быть эфемерным параноидальным призраком. Хочется сделать все качественно и надежно. И оказывается, что реализация языка не позволяет этого сделать из-за генетической болезни: есть либо неперевоспитываемый гулящий контейнер, либо не контейнер.

[iNils]

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

Увидел, что ты назвал Python и Ruby "деградирующими языками".

Я такого не говорил, я сказал "деградирующие примеры". Это как слова "глупая у вас мысль" воспринять как "он меня глупым назвал"

[Babylon]

Мое частное мнение: каркас системы должен быть типизирован и заинтерфейсен,т.е. фактически это должен быть движок для контента, а любой контент лейатируемый в контейнеры должен определяться по XML.

[Wolsh]

Вот только Списку Отображения нет дела до ваших типов и интерфейсов. Он просто напросто параллелен всем вашим ООП-стараниям. Через getChildAt() можно добраться до любого ДО и тупо удалить его через parent.removeChild(). Для него есть только один тип — ДО, и только один модификатор доступа — паблик.
Только пожалуйста, не начинайте новую волну размышлений об оверрайдах. Я итак до глубины души поражен, с каким рвением народ стал отстаивать свое право страдать и извращаться.

[MikroAcse]

любой контент лейатируемый в контейнеры должен определяться по XML.

Везде вы со своим XML, что же он настолько идеален и для всего подходит?
Просто уже надоело его навязывание.

[Babylon]

Что такое ООП? Это механизм работы с объектом. В данном случае с DOC.
А теперь представьте, что у Вас один механизм работы с ДОС, а у кого то другой и что Вы будете делать без интерфейсов если всё закрыто?
На XML можно более менее понятно описать алгоритм работы и
+ это объект который хранится в памяти как иерархическая структура и + может быть сохранена во внешнем файле.
override часто как раз и преодолевает отсутствие интерфейсов. Что неправильно в корне. Поэтому компоненты в AS3 это нечто неописуемое. Последнее слово является ключевым.

Добавлено через 10 минут
Cписок отображения это часть Вида в паттерне MVC. Где всё остальное?

[Psycho Tiger]

Я такого не говорил, я сказал "деградирующие примеры".

Тут видишь, дело-то в другом.
Когда программист дёргает приват извне – это значит что у него есть на это везкие причины. Настолько везкие, чтобы дёрнуть приват. Я говорю о людях, которые достаточно квалицифированны чтобы понимать последствия, конечно Я никогда не встречал ситуации, в котором можно было бы дёрнуть приват в AS3. Но встречаю, когда пишу на Ruby/Rails.

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

Не, ты меня не так понял. Я за "закрытый" DOC, идея здравая. Я про то что его отсутствие – не такая трагедия, как мне кажется ты считаешь.
То есть, когда статические языки имеют 2 публичных метода, а не 20, из которых 18 – неправильные – это здорово.
Но вот, ты как девелопер знаешь, что унаследованный addChild в твоих компонентах работает неправильно. Ты можешь его вызвать, но это приведёт к логической ошибке. Поэтому, всё сводится к тому чтобы помнить, дёргать addChild или addCustomChild. Я не уверен, но [Exclude] у оверрайденных методов же убирает его с автокомплита? ...

Да, это костыль. Да, это проблема. Но если бы было голосование, что добавить в язык/API – приватный DOC был бы для меня на последних местах.

На XML можно более менее понятно описать алгоритм работы

Вот так?

<root>
<actions>И тут в общем марио бегает по платформам а работает всё на движке папервижн и на мобилках можно</actions>
</root>

Извините за сарказм, конечно – но алгоритмы на XML описывать уже явно перебор. Вы программировать на нём уже тоже пытались?

[Babylon]

Мы говорим про рантайм, то есть сборку вида по XML и выполнение предписанных сценарием действий.

[Psycho Tiger]

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

Мы говорим про рантайм, то есть сборку вида по XML и выполнение предписанных сценарием действий.

Да какая разница, рантайм или компайл-тайм.
Вы действительно считаете что XML удобен для описания алгоритмов? Опишите какой-нибудь, мне интересна эта "красота" )