Корректный оверрайд

[Котяра]

По хорошему, я тоже в обработчике onCancel вызвал бы лучше переопределяемую ф-цию
cancel()
Но особо криминала всё же не вижу.
Система похожа на события в AS2 и не совсем уж ужас-ужас.
Особенно если в обработчике необходимо обрабатывать свойства события.

[arkadattx]

Вопрос по схожей проблеме: правильно ли переопределять базовые методы? Например, addChild? Или лучше создать отдельный метод со схожим функционалом?

[Bgg]

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

Вопрос по схожей проблеме: правильно ли переопределять базовые методы? Например, addChild? Или лучше создать отдельный метод со схожим функционалом?

Смотря где, как и зачем.

[arkadattx]

Bgg, а можно поподробней? В каких случаях это оправдано, а в каких нет?

[scarbo]

Ну если к примеру создаете тайл-грид контэйнер, то переопределение было бы оправдано, тогда в методе addChild() можно сразу же назначать нужные координаты элементу контэйнера.

[wvxvw]

Касательно addChild и им подобным - я все таки за то, чтобы этого не делать. Вернее, не совсем так, если делать, то в финальных классах, либо классах заточеных под какую-то определенную задачу, у которых будет ограниченный набор наследников, и все они будут опять же финальными. Даже более того, в виду того, что практика нашего мира такова, что получить хорошо, да что там хорошо, хоть как-то спроектированную схему классов к проекту - такого просто никогда не произойдет, я строю наследование по следующему принципу: пишется класс А и класс Б, сравниваются, если у них есть что-то общее, то пишется класс В, в куда это общее выносится, А и Б наследуются от В. Так я хоть немного застрахован от ситуаций, когда "внезапно" нужно переделывать базовый функционал, который я описал не там, где нужно.
Да, еще такой вариант, иногда нужно "немного" переделать базовый метод, если он делает что-то определенно не то. Например, тот же addChild может "своровать" ребенка у другого контейнера - переопределить addChild, чтобы он этого не делал - это как бы даже благородный поступок, по своему А переопределить его и бросить в нем ошибку, как это делает флексовый фреймворк - это "ой беда беда огорчение..."
Но, опять же, в том что касается дисплей объектов - я стараюсь их не трогать. B смысле, просто использовать их как контейнеры для графики, а если мне нужно описать логику - делаю это в классах, метдоы которых принимают эти самые визуальные объекты в качестве аргументов - так проще жить. Особенно в ситуациях когда например, хочется вернуть обратно метод супер-супер класса, и начинаешь ломать голову, как же его так перестроить. Вообще, очень часто получается, что функции, которые не привязаны к контексту (this) класса легче заменяются при необходимости.
Что я имею в виду:

public class SuperSuper extends Sprite
{
	protected static function doSomething(to:Sprite):void
	{
		to.x = 100;
	}
 
	public function SuperSuper()
	{
		super();
		doSomething(this);
	}
}

public class Super extends SuperSuper
{
	protected static function doSomething(to:Sprite):void
	{
		to.x = -100;
	}
 
	public function Super()
	{
		super();
		doSomething(this);
	}
}

public class Orphan extends Super
{
	protected static function doSomething(to:Sprite):void
	{
		to.y = 50;
	}
 
	public function Orphan()
	{
		super();
		// Заметте, что при традиционном подходе к наследованию 
		// это бы выглядело как-то типа super.super.doSomething();
		// что, вобщем не возможно.
		SuperSuper.doSomething(this);
		doSomething(this);
	}
}

Но с другой стороны у такого подхода есть недостатки - с точки зрения AS3 это вообще не наследование, а просто случайное совпадение имен. Такая практика не распростанена и скорее запутает читающего. Кроме того, нам нужно вызывать все функции с одним "лишним" аргументом (опять же именно изза того, что AS3 не считает такой подход наследованием). Очень часто this используется для хранения состояния объекта, например button.enabled и нам удобнее найти свойство напечатав точку после имени объекта, чем сравните:

static function clickHandler(event:MouseEvent):void
{
	// Предположим, что у класса Button существует методы:
	// static enabled(Button):Boolean
	// static enable(Button):void
	// get enabled():Boolean
	// set enabled(Boolean):void
	var button:Button = event.currentTarget as Button;
	if (enabled(button))
	{
		enable(button);
	}
	// Т.как редактор кода не знает, что enable() связан с SimpleButton - вы будете его долго искать
	if (button.enabled)
	{
		button.enabled = false;
	}
	// Потенциально прийдется писать лишний (возможно ошибочный) код, 
	// если вы задумаете переопределить button.enabled
}

[Котяра]

меня больше напрягает что нет IDisplayObject

[i.o.]

меня больше напрягает что нет IDisplayObject

в смысле? Просто интерфейса или возможности его реализовывать?
Если второй вариант, то любопытно, как задумывается производить отрисовку содержимого?

[wvxvw]

Ну IBitmapDrawable же есть А я так подозреваю, что как раз этот интерфейс силами AS можно было бы реализовать. Если уж речь зашла о пожеланиях, то IDisplayObject мне как-то представляеся не особо полезным, а вот что-то типа IDisplayObjectContainer и IInteractiveObject - очень даже бы пригодились. А то сечас получается, что сколько от Bitmap не наследуйса, мышиные события не получить. ISoundTranformable или как-то так, а то свойство soundTransform возвращающее SoundTransform есть у 5-6 классов, а они все в одну категорию никак не укладываются, IGraphicsContainer - а то иногда приходится строить какие-то дурацкие конструкции для определения, есть ли у объекта свойство graphics, или нет его... А там и генерики не за горами... а еще чтобы для CLR компилировался, и чтобы лучше, чем C#

[Котяра]

Я про другое.
например я сделал класс имплементирующий IEnemy - у него есть, например, только свойство hp,
но сам класс имплементирующий IEnemy - является спрайтом.
как мне достучаться до

var enemy:IEnemy;
//..
enemy.x

если бы можно было сделать IEnemy implements extends IDisplayObject и если бы дисплэйобжекты реализовывали бы этот интерфейс было бы неплохо. Ведь IEventDispatcher есть.
PS Много "бы", но ведь это мечты -мечты.. Хотя я обхожу это всё композицией обычно, но сам факт неприятен. Не один раз сталкивался с этим. Особенно при загрузке внешних модулей. когда контент вроде и интерфейс должен иметь и спрайтом никак.