9 дней, или приблизительная скорость обработки багов в Adobe JIRA

Я вот подымал вопрос на ruFlash, вроде никто так и не высказал принципиальное кю по поводу таких возможностей:

1. override
При переопледелении метода в подклассе допускать возможность изменения типа возвращаемого значения на дочерний тип.

Пример:

class MyEvent extends Event {
override public function clone ():MyEvent {
....
}
}

2. interface (Аналогично п.1.)
В имплементируемых методах допускать возможность изменения типа возвращаемого значения на дочерний тип.

interface IClonableSprite {
function clone ():Sprite;
}

class MyMovieClip extends MovieClip implements IClonableSprite {
public function clone ():MovieClip {
....
}
}

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

Вероятно, были более приоритетные баги в очереди на исправление.

iv, тут есть сложность — эти баги относятся не ко Флекс Фреймворку, а ко внутренностям самого Flash Player, к реализации самого языка AS3.

Две основные:

1. Организационная: насколько я знаю, сейчас Adobe JIRA не предоставляет публичный доступ к системе учета багов Flash Player.

2. Идеологическая: ActionScript3 реализует стандарт ECMAScript4. Если предлагаемое тобой нововведение идеологически противоречит ECMAScript4, то возникают новые вопросы, связанные с отхождением от стандарта (на базе которого строится также и JavaScript2). Или нужно менять стандарт. Но в данный момент я не готов ответить, противоречит ли твое предложение идеологии ECMAScript4.

-----
Я вот подымал вопрос на ruFlash, вроде никто так и не высказал принципиальное кю по поводу таких возможностей:

1. override
При переопледелении метода в подклассе допускать возможность изменения типа возвращаемого значения на дочерний тип.
----
Я бы не сказал что это баг: все в рамках логики, если ваш код умеет работать с более общим типом, например Object, то должен уметь работать с более частным. В конце концов, один из слонов ООП - наследник некоторого класса должен быть разновидностью базового класса.

в java такая же идеология и есть правила сужения типов также и для генерируемых исключений.

баг - это отсутствие приватных конструторов, перегрузки, мозгов у разработчиков flex :(

----
да, раз пришлось к моменту, есть вопрос: сегодня какой день написания "мой путь" плагина для flex для idea. Столкунулся с тем, что при компиляции через fcsh не воспринимаются пути содержащие пробелы (компайлинг через mxmlc работает пучком), бился долго и упорно, пока не решился декомпилировать fcsh, увидел чудо код:

if(s.startsWith("mxmlc")) {
StringTokenizer t = new StringTokenizer(s.substring("mxmlc".length()).trim(), " ");
String args[] = new String[t.countTokens()];
for(int i = 0; t.hasMoreTokens(); i++)
args[i] = t.nextToken();

это классные парни выполнили парсинг входной строки путем тупого биения ее на подстроки разделенные пробелом, без ... учета экранирования строки в кавычки

-- собственно, я не исключаю момента что "фокусник был пьян и фокус не удался"