Тут я больше верю Блуду.
Я не думаю, что содержание детей такой "простой" код, который было бы выгоднее реализовать копипастом. Я думаю, что скорее это тупо прикрыли, повыпиливав каким либо образом на уровне ФП.
А так - "меньше знаешь - крепче спишь". Чисто рассуждая логически можно понять, что адоубовцы хотят, чтобы их продукт был крайне стабильным - у них это не очень хорошо получается, но я думаю что они стараются. Stage - по идее DOC (DisplayObjectContainer), потому что должен вести себя именно так - это логично. А то что во внутренней реализации TF (TextField) тоже используется DOC - совсем не логично, текст должен быть текстом, а не контейнером. С симплбаттоном так же ситуация, в какой стейт добавлять новых детей? Короче, помимо Stage`а, которому функционал этот нужен не могу найти логичных доводов оставить этот функционал в TF или SB. Это инкапсуляция, только на уровень выше.
По поводу тестов скорости - я не знаток внутренней реализации, но считаю что виртуальные методы вызываясь составляют таблицу, по которой "всплывают" вверх до первого переопределения/определения (как в си, короче) - идём по скоупу выше, пока не найдём, а на это тоже нужно время. ED -> DP - > Interactive Object -> DOC -> Sprite.
Поиск нужного метода тоже занимает какое то время, вполне возможно соизмеримое с переопределением метода в производном классе сразу от ED. Хотя опять таки, я не знаю как с этим обстоит дело. Может быть это в теории так, а на практике ФП использует какое-нибудь супер-кеширование и все методы вызываются с одной скоростью... Короче, надо тестить, а мне лень.
Но это так, просто мысли вслух, а метод dispatchEvent переопределён чуть более, чем наверняка - потому что бабблинга вне DP не существует.
06.08.2010, 13:28
Линейный вид
