дцать причин не любить AS3, AVM1 против AVM2 Опции

[chingachgoog]

В свое время в сети попалась презентация "50 причин перейти на AS3", так, что тут будет (со временем) нечто вроде контрответа, а также разбор отличий AVM1 (AS1/AS2) от AVM2 (AS3).

(не следует считать этот топик отрицанием AVM2 и AS3. Хороший флешер должен уметь понимать любой код: от кода в стиле флеш-5 (на объектах), до кода AS3. Но чтобы хорошо в чем-то разбираться, надо знать не только сильные стороны, но и слабые, а также тщательно скрываемые)

Итак, поехали:

1) Адоб сознательно (умышленно) пошла на СДЕРЖИВАНИЕ развития AVM1. От версии к версии (флеш-плеера) AVM1 развивалась. Но адоб выпустила новые продукты - основанные на AVM2 (флеш-редактор-9 - он же CS3 и уже CS4, флексы всех мастей и аир). Развитие AVM1 тормозиться, заставляя переходить сообщество на продукты с использованием AVM2.
Например, интерпретатор AVM1 может считывать байт-коды названия меток кадра. Т.е. в самом ФП эта возможность реализована. А вот реализацию этого в AS1/2 адобовцы добавить "забыли", хотя для AVM2 с AS3 это сделано. И так во многом.

2) AS3 не сохранил преемственности с прежними версиями AS. Это ДРУГОЙ язык. С другими традициями и особенностями применения. По сути, те, кто захочет и кого заставит адоб перейти на AVM2 будут должны выучить новый язык.

3) AS3 имеет незаметные, но фатальные отличия от AS2. Например, в типизации :Void и :void
Пустячок? Но отчего у макромедии с каждым обновлением ФП не скакали зарезервированные слова?

4) AS3 гораздо более НЕГИБКИЙ (какое издевательство над слово флекс), чем AS1. Это касается очень широкого спектра средств языка: наследования, областей видимости, обращения к объектам, формата записи во внешние файлы и т.д. и т.п. (см. ниже)

5) AS3 не позволяет менять родителей класса. AS1 делает это легко, динамически и в любое время.
Например, после этого:

Код

Video.prototype.__proto__=MovieClip.prototype

У объекта Видео начинают работать методы мувиклипа типа swapDepths() и removeMovieClip() !!!

6) Код на таймлайне
7) Новый синтаксис пакетов и классов
8) Нет duplicateMovieClip
9) Необходимость деструкторов
10) Мучения с Sound
11) Выделение искусственных классов
12) Громоздкий хелп
13) Кастрация событийной модели
14) Смешной onReleaseOutside
15) Зачем в AS3 убили arguments.caller
16) Как сыпятся песочницы адоба
17) Восьмеричный запрет
б/н Откровения мистера Ли из адоба
18) Жесткий override
19) Ограничения override
20) Убогий super
21) А есть ли полиморфизм?
22) Немного об ECMAScript
23) Ограничения таймлайна
24) Глобальный объект и глобальная видимость
25) Они убили watch()...
26) Нет глобальных событий
27) Компилятор AVM2 не оптимизирует код
28) valueOf ()
б/н Про вес ФП
29) Виртуализация таймлайна и баги с этим связанные
30) Идиотизм Loader-а
31) "Легкие" глубины.
32) Автосоздание прототипов
33) allowDomain у LocalConnection
34) Неоправдавшиеся надежды по поводу расшаренных объектов
35) Преобразование типа null к числам
36) Зачем buttonMode для мувиклипов?
37) Run-time ошибки
38) Ограничения с работой JavaScript
39) isDown почила в бозе...

Сообщение отредактировал chingachgoog - 1.07.2011 - 14:38

[chingachgoog]

Жаль, что вместо разбора пунктов по существу (или добавления своих), начинается разбор личностей. Впрочем в сети это обычное явление.

[Maxim I]

Разбирать то нечего, тебе уже все объяснили. Я сейчас нашел баг в проекте на эйре. Искал часа два, ибо классов где-то под 200, и тьма листенеров. На AS1 я бы искал в такой тьме кода неделю

[white-shadow]

для начала я говорю не о ролике с неболшим количеством скриптов, а о полноценных приложениях/сайтах на flash где не 1 человек трудиться.


"Возможно хотеть что угодно. Но то что в AS1 было сверхгибко, в AS3 загнано в строгие тесные рамки. Собственно об этом п.18"

хорошо, есть базовый клас и его метод :

Код

class MySuperClass {
   public function MyMethod(i: Number): String;
}

вы делаете потомка этого класса и переопределяете метод:

Код

class MyClass extend MySuperClass{
   public function MyMethod(i: Number; j: String): String;
}

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

При чем тут приведение типов через as и супер?

вы описали задачу вызвать перезаписанный метод - вообщето обычно наоборот есть MyClass приведенный к базовому и нужно вызвать не метод супер класса а именно переопределенный, тоесть так

Код

(MySuperClassExsemplyar as MyClass).MyMethod(0)

можно и наоборот

Код

(MyClassExsemplyar as MySuperClass).MyMethod(0)

...

"Поэтому в п.20 я немного поглумился над Муком, как он в AS3 собирается ЭКЗЕМПЛЯР подкласса использовать ВМЕСТО (полноценно) ЭКЗЕМПЛЯРА суперкласса, если мы перепишем в подклассе метод суперкласса? В AS1 это легко можно, а в AS3 - нет (см. выше)"

см. выше.

"Полиморфизм - это вообще более архитектура логики, он возможен даже в языках, которые не являются языками ООП."

я знаю что такое поли и что такое морфо, и раз ООП придумали после процедурного программирования то ваше удивление неуместно, только выглядит это так (Pascal):

Код

function MyFunc(param1: string): string; overload;
function MyFunc(param1: integer): string; overload;

и архитектуры у логики нет...

"Но JS и AS1 будучи прототипными, более гибкие, чем AS3. "
про тотже яваскрипт написано много толмутов что это скорее зло чем благо.
кстати из примеров с адоба [url http://help.adobe.com/ru_RU/ActionScript/3...18a9b90204-7fa3]

Код

Object.prototype.toString = function()
{
    // statements
};

Вы этого хотели в п. 20?


"В смысле кому разбирать?"
вдруг (не дай бог конечно) комуто придется разбирать и дорабатывать код написаный на тамлайне да еще таким способом, или сам автор будет вынужден доработать СВОЙЖЕ код через пол года.

"Я просто написал об очередных граблях с AS3. Грабли есть? Есть. И надо понимать механизм граблей."

для меня это не грабли а вполне нормальное явление присущее не только AS но и многим другим языкам программирования и помоему не только для меня.

ЗЫ. наткнулся на эту тему когда искал документации по ас3 поэтому и решил поспорить, думаю многие желающие изучать актион скрипт будут введеы в заблуждения.
ЗЫЗЫ. гдето на 1 страницы вы писали про Void и void. void - видимо введено для совместимости и привычности (в томже с с++ именно так)
ЗЫЗЫЗЫ многи писали по существу и лично Вас никто не знает, так что причем тут личности?

[white-shadow]

и вообще полиформизм не означает что хочу то и творю даже для прототипов, нельзя перечеркивать инкапсуляцию - вам впринцне не нужен базовый класс у вас есть его потомок и экземпляр потомка, а базывай класс может быть вообще абстрактным...

и вы людей обвиняеете в неконкретике - слово гибко тоже не очень конкретно хотя оно идет через приложение...

и тут действительно уместно сравнение с явой и яваскрипт = as3 и as1-2.

[chingachgoog]

для начала я говорю не о ролике с неболшим количеством скриптов, а о полноценных приложениях/сайтах на flash где не 1 человек трудиться.

Тут никакого секрета нет. Если речь о многотысячестрочном коде, над которым работают более трех программистов - то работа с классами и даже с интерфейсами будет идти быстрее. Но есть полноценные приложения где кода где-то 2-3 килостроки. Где работает 1-2-3 программиста. Там быстрее и удобнее AS1.

хорошо, есть базовый клас и его метод :

Код

class MySuperClass {
   public function MyMethod(i: Number): String;
}

вы делаете потомка этого класса и переопределяете метод:

Код

class MyClass extend MySuperClass{
   public function MyMethod(i: Number; j: String): String;
}

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

Вы меня спрашиваете? Это адоб надо спросить, зачем они так сделали. (наверное данная архитектура AVM2 по-другому просто не позволяет)
В AS1 это делается легко и безо всяких ошибок - AVM1 последовательно идет по области видимости цепочек прототипов и найдя искомую переменную (в данном случае название метода) более ничего не ищет. О чем я и говорил в пп. 18, 24 Ничего прятать в приват и оверрайдить не нужно.

вы описали задачу вызвать перезаписанный метод - вообщето обычно наоборот

Обычно да. Но Мук утверждает про наоборот. И я с ним согласен - это круто. Вот беда - Мук забыл рассказать, как это делать на AS3.

есть MyClass приведенный к базовому и нужно вызвать не метод супер класса а именно переопределенный, тоесть так

Код

(MySuperClassExsemplyar as MyClass).MyMethod(0)

можно и наоборот

Код

(MyClassExsemplyar as MySuperClass).MyMethod(0)

...

Это привод типизации. Как это поможет вам вызвать метод суперкласса у ЭКЗЕМПЛЯРА подкласса, у которого этот метод был переписан?
Вот вам простые классы:

Код

package {    
    public class A {
        // Суперкласс
        public function use1(){
            trace("суперкласс")
        }
    }            
}

Код

package {    
    public class AB extends A {
        // подкласс
        public override function use1(){
            trace("Подкласс")
        }
    }            
}

Создайте пожалуйста экземпляр подкласса AB и сделайте так, чтобы при вызове метода use1 писалось "суперкласс".
На AS1 такая задача решается на раз.

Код

Object.prototype.toString = function()
{
    // statements
};

Вы этого хотели в п. 20?

Я хотел аналога

Код

экземпляр.__proto__.__proto__.метод()

для AS3

"В смысле кому разбирать?"
вдруг (не дай бог конечно) комуто придется разбирать и дорабатывать код написаный на тамлайне да еще таким способом, или сам автор будет вынужден доработать СВОЙЖЕ код через пол года.

Вам удобно рыться по десяткам отдельных .as файлов, где зачастую вместо одной нужной строчки надо писать три (п.24) в отдельном файле.
Кому-то удобно писать код на таймлайне.
Для каждого конкретного случая что-то будет более оптимальным, а что-то менее.

"Я просто написал об очередных граблях с AS3. Грабли есть? Есть. И надо понимать механизм граблей."

для меня это не грабли а вполне нормальное явление присущее не только AS но и многим другим языкам программирования и помоему не только для меня.

Я за вас рад, особенно если вы понимаете МЕХАНИЗМ граблей, а не просто тупо следуете правилам, знакомым с других языков.
Но после неприхотливого AS1 такие огричения AS3 будут восприниматься именно как грабли. И мне кажется важно показать именно механизм граблей.

[chingachgoog]

Я сейчас нашел баг в проекте на эйре. Искал часа два, ибо классов где-то под 200, и тьма листенеров. На AS1 я бы искал в такой тьме кода неделю

Далеко не факт. Кода на AS1 было бы раза в два меньше...
AS1 позволяет писать централизованный код с разбивкой при необходимости на .as файлы.

и вообще полиформизм не означает что хочу то и творю даже для прототипов, нельзя перечеркивать инкапсуляцию - вам впринцне не нужен базовый класс у вас есть его потомок и экземпляр потомка, а базывай класс может быть вообще абстрактным...

Вот беда - в AS абстрактные классы можно только эмулировать. А при чем тут перечеркивание инкапсуляции я не понял - кто перечеркивает? Где перечеркивает?
Полиморфизм в AS1 более мощный и гибкий, чем в AS3. С этим надо смириться.

[Maxim I]

вообще-то если я перегрузил метод в классе-потомке, это означает только одно - МЕТОД РОДИТЕЛЯ МНЕ АБСОЛЮТНО НЕ НУЖЕН, именно поэтому я его и перегрузил. я в страшном сне только представлю что какой-нибудь идиот вздумает вызвать не то, что надо. только не надо фантазий "а что если мне понадобиться". за такое отрывают руки

а про меньше строк кода на AS1 даже не смешно. с твоими мыслями рабочий код хотя бы строк тысяч в 10 будет ужасен и имхо никогда не заработает

[Maxim I]

В последний раз, когда пришлось вдруг игру писать под AS1/AS2 я рвал на себе волосы, и проклинал все на свете. Чувак, как я счастлив что это позади и с АS1 мне больше не по пути. Подумай об этом на досуге, хотя если ты мазохист, ничего не имею против. Засим откланиваюсь, а то так работа встанет на болтовню

[chingachgoog]

Как предсказуем оказался Maxim I...
Сленг а-ля "чувак", много эмоций и ничего из конкретики...
Надеюсь на код от white-shadow.

[Maxim I]

Обращаюсь применительно к Вашему юному возрасту, может так реальнее достучаться. Пока никому это не удалось.

Код

public class Player {

public function Player(){
something();
}

protected function doThis():void{
...
}

}

public class MyPlayer extends Player {

override protected function doThis(){
super.doThis();
.....
}
}

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

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

[Maxim I]

void забыл добавить. кстати тот проект в котором участвовал на AS2 так и не смогли отладить и закончить, вроде переписывают под AS3. первый экшнскрипт, равно как и AVM1 для более-менее серьезных проектов - это шаг в пропасть, Я ГАРАНТИРУЮ ЭТО!

[chingachgoog]

Обращаюсь применительно к Вашему юному возрасту, может так реальнее достучаться. Пока никому это не удалось.

Код

...
override protected function doThis(){
super.doThis();
.....
}

может так понятнее?

Приветствую конкретику!
Но что должно быть понятней? В п.20 я именно про это и писал:

super в AS3 можно выполнить только внутри описания класса.

В данном случае оверрайд бессмысленен - перезаписанная функция делает тоже самое, что родительская.
В данном случае налицо недопонимание именно со стороны Maxim I. Он не понимает, что может, а что НЕ может делать AS1 и AS3.
В AS1 можно обращаться с экземпляром подкласса ПОЛНОСТЬЮ ТАК ЖЕ, как если бы это был экземпляр его суперкласса. Именно в тот момент когда мне это надо. Т.е. экземпляр один, а в зависимости от задачи он может вести себя либо как собственный экземпляр, либо как экземпляр своего суперкласса. В AS3 это невозможно - необходимо будет сделать дополнительные костыли, дергая за которые можно будет частично имитировать поведение экземпляра под экземпляр суперкласса.
Вот собственно и все.

Далее можно развести демагогию, что мол в AS3 это вовсе и не нужно, что мол перезагрузка и означает, что метод родителя не нужен...
Может быть, может быть... Но в AS1 такая возможность есть, а в AS3 - нет.
Мук ляпнул про полиморфизм - а это лишь в AS1 возможно. Кто за честь Мука постоять сможет?

Жду разгромного ответа (кода) от white-shadow. А там глядишь и Maxim I сможет нехитрую интерполяцию сделать:
"смотрите де - тут chingachgoog оконфузился - глупость де написал, значит и его остальные пункты такая же глупость...

тебе уже все разжевали, AS3 сделали донельзя удобным и читаемым...

Ну да ну да. Кому и кобыла невеста... ©

[Maxim I]

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

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

[chingachgoog]

он и ведет себя именно как экземпляр суперкласса. иначе почему мне его наследовать?

В этом месте важная деталь:

В AS1 можно обращаться с экземпляром подкласса ПОЛНОСТЬЮ ТАК ЖЕ, как если бы это был экземпляр его суперкласса.

ПОЛНОСТЬЮ!
А в AS3 - лишь где методы родителя не были переписаны (не говоря уже о свойствах запрятанных в приват).

... пляски с прототипами в коде, упаси господь, это саботаж

Кому как удобней. Дело хозяйское. Была бы ВОЗМОЖНОСТЬ. А возможность эту в AS3 прикрыли и получили массу ограничений.

[white-shadow]

я не говорю что мне нравиться организация один файл один публичный класс (именно 1=1), но по крайней мере это очень логично. многие изменения языка (ограничения как вы выражаетесь) позволяют повысить производительность виртуальной машины AVM. Кстати про малость кода, ООП в том числе и для этого придумали - чтобы повторно использовать код и делать меньше его повторов.

про вызов метода базового класса по экземпляру - это и нарушает инкапсуляцию - вам не нужно знать как все сделано у вас интерфейс (не тот который interface) чтобы работать с классом описанный в базовом классе - ваша база для универсализации, например у вас есть класс Stream где есть методы read write seek и так далее и есть его потомки MemoryStream и FileStream где все это переписано и есть класс в котором используется класс Stream например в качестве буфера и вам не важно как он храниться в памяти или на диске (какой потомок создан) есть методы read write и с ними работаете (вызываете переопределенные методы).

Основной смысл ооп это то что вам всеравно как реализован класс (где хранить буфер) а важно что можно читать и писать. А если вы знаете и зависите от реализации то зачем все эти грабли с объектами...

а если немного поменять цепочку наследования? добавить промежуточный класс между Stream и *Stream с переопределенными методами, то код использующие ваше предложение не сможет работать (вы вызовете уже не ту функцию на которую расчитывали).

"Мук ляпнул про полиморфизм - а это лишь в AS1 возможно. Кто за честь Мука постоять сможет?"
полиморфизм это как раз от старшего к младшему а не наоборот. по поводу вызова перегруженного метода соглашусь что в AS3 нельзя так (super определен только внутри методов класса), но это нормально ибо наоборот - как минимум не безопасно потомучто нарушает логику работы класса и результат трудно контролировать.

эти минусы скорее смахивают на хаки чем на реальную необходимость. повторюсь полиморфизм !== как хочу так и делаю. полиморфизм(много форм) это много реализаций методов класса с одним описанием и никак не иначе. если изменить описание вы вычеркиваете наследование, если вызывать метод супер класса переписанный в потомке, то вы нарушаете еще и инкапсуляцию - вы знаете как внутренне реализован класс (сколько прото нужно написать чтобы добраться до нужного метода) получается вы зависите от его реализации и изменить ее уже нельзя иначе ваш код перестанет работать правильно.

банальное ооп на классах проще читать писать и контролировать не аргумент? к томуже позволяет более жестко проверять типы переменных и описание методов еще на этапе компиляции...

"Если звезды зажигают -- значит -- это кому-нибудь нужно?"
если чтото запрятали в приват то может не дурак был этот человек. к томуже есть еще final даже есть final классы.


пока вспомнил про восмиричную систему.
Теперь ActionScript 3 интерпретирует строку, начинающуюся с нуля как десятичное число.
Код:
// ActionScript 3
trace(Number("010")); // 10
Если же нужно интерпретировать строку как восьмеричное число (или в любую другу систему счисления), то нужно использовать функцию parseInt:
Код:
trace(parseInt("010", 8)); // 8

и по поводу onReleaseOutside тоже можно (естественно своими силами), поисчите 100 советов по AS3 от senocular тамже и про duplicateMovieClip было...

вобщем смысла устраивать холивар я не вижу нравиться на прототипах - дай бог, просто наткнулся на этот топик при поиске доков по АС3 (решил написать конкретное приложение (редактор изображений), до этого собо не "флешил" ) и думаю некоторых может ввести в заблуждение что все так плохо. Лично был очень рад если бы аваскрипт имела бы хоть половину "ограничений" как в АС3(хотябы реализацию на классах). И вообще прототип он чтобы добавить свою функцию, расширить функционал так сказать, например из жизни:
есть ByteArray и есть у него метод compress(algo: String) но во флеш плеере нету дефлейта тока zlib (algo = void - compress() ) поэтому приходиться переписывать алгоритм сжатия на флеш и очень удобно расширить ByteArray новым методом CompressDeflate...

Сообщение отредактировал white-shadow - 20.06.2009 - 08:29

[MustLive]

white-shadow, Maxim I и другие участники форума, замечу вам о том, о чём уже замечал Rohan-у и chingachgoog-у, не нужно устраивать потасовки и перепалки на форуме. Держите себя в руках и не допускайте чрезмерных потоков эмоций, которые отнюдь не делают дискуссию в этой теме более конструктивной .

К примеру, white-shadow обратил внимание на этот аспект, и в своём последнем посте перевёл разговор в конструктивное русло (чтобы не устраивать холивар на форуме). После того, как вначале немного поддался эмоциям. Так что от других пользователей также ожидается подобный конструктивный подход.

Я прекрасно понимаю, что тема поднятая chingachgoog весьма неоднозначна, и не всем она может понравиться (особенно апологетам AS3), но сравнение различных версий AS и AVM дело нужное. И от данной темы будет польза для флешеров и чем конструктивнее будет дискуссия, тем лучше будет для всех.

[MustLive]

Может баян, но я не нашел ни одного аргумента со стороны %username%

VivaKalman

Ты о ком говоришь? В следующий раз вместо %username% используй имя участника форума .

Скажем, если мы пишем на AS2/1 (для веб), то предполагается, что на браузер пользователя установлен Flash player не ниже 9 версии, в то время как As3 предполагает наличие версии >=9.

Если пишем на AS1, то версия флеш плеера может быть любая, как последняя, так и предыдущие. Если на AS2, то версия флеш плеера д.б. 7 и выше, а если на AS3, то версия д.б. 9 и выше.

При этом нужно помнить, что некоторые возможности AS1 появлялись в более новых версиях флеша (т.е. после 6 версии, в последующих версиях добавлялись функции в AS1). Подобное может произойти и с AS2. Поэтому в некоторых случаях нужно учитывать не только версию AS, но и версию флеш плеера, в которой была добавлена данная функция.

На вряд ли, у всех рядовых пользователей интернета стоит плаер выше 8 версии

У большинства уже давно стоит 9 и после выхода 10 версии, пользователи потихоньку обновляются на новую версию. О статистике использования различных версий флеша (размещённой на сайте Адоба) я писал в прошлом году.

заставлять выкачивать пользователя плагин, только для того, что посетить ваш ресурс - по меньшей мере не разумно

Это не особо разумный подход - заставлять выкачивать более новую версию плагина, но он весьма распространён. И с 1998 и по сей день я нередко с такими сайтами сталкиваюсь, которые увлекаются авангардизмом . И многие серьёзные порталы регулярно обновляют свои флешки до последней версии и требуют от пользователей обновить флеш плагин, и пользователи таких сайтов совсем не уходят от них, а спокойно обновляют свои флеш плагины (сам столкнулся с подобным на Ютюбе в прошлом году). Поэтому иногда сайты вынуждены требовать от своих пользователей наличия последних версий флеш-плагина.

[chingachgoog]

я не говорю что мне нравиться организация один файл один публичный класс (именно 1=1), но по крайней мере это очень логично.

Вы правда так считаете? Что это ЛОГИЧНО? Да еще и "очень"?
Может тут и есть логика с точки зрения компилятора. Но сточки зрения программиста-конечного пользователя - логики нет. Почему я не могу в тело пакета запихнуть несколько внешних классов/функций/переменных? Почему я должен называть файл именно именем единственного внешнего класса/функции/переменной? И еще десяток почему.
Это, возможно, было удобно программистам-разработчикам адоба, но ни разу не удобно конечному программисту-пользователю продукта.

многие изменения языка (ограничения как вы выражаетесь) позволяют повысить производительность виртуальной машины AVM.

Да, я об этом говорил - динамическая трансляция кода требует жертв. На мой взгляд жертвы перевешивают получаемые блага.

Кстати про малость кода, ООП в том числе и для этого придумали - чтобы повторно использовать код и делать меньше его повторов.

Не пойму, к чему это? Никто не спорит, что ООП, доступное еще с AS1, делает возможным повторно использовать код.
Я же говорил про громоздкость кода AS3 по сравнению с кодом AS1, о чем кстати говорил и мистер Ли.

про вызов метода базового класса по экземпляру - это и нарушает инкапсуляцию - вам не нужно знать как все сделано у вас интерфейс (не тот который interface)...
Основной смысл ооп это то что вам всеравно как реализован класс (где хранить буфер) а важно что можно читать и писать. А если вы знаете и зависите от реализации то зачем все эти грабли с объектами...
...

Мук ляпнул про полиморфизм - а это лишь в AS1 возможно. Кто за честь Мука постоять сможет?

полиморфизм это как раз от старшего к младшему а не наоборот. по поводу вызова перегруженного метода соглашусь что в AS3 нельзя так (super определен только внутри методов класса), но это нормально ибо наоборот - как минимум не безопасно потомучто нарушает логику работы класса и результат трудно контролировать.

Тем не менее я дал цитату из Мука. По-моему ее трудно понять иначе. Единственное, на что могут рассчитывать адепты Мука - это ошибка переводчика.
Что касается полиморфизма - я дал ссылку на Бадда (см. выше). Это очень широкое понятие, которое в AS3 сужается до очень конкретного использования. В этом смысле полиморфизм на AS3 гораздо гибче и шире.
А инкапсуляция, когда у экземпляра мы можем вызвать метод его суперкласса через __proto__ ни разу не нарушается - в любом случае мы знаем, кто чей наследник и какова цепочка наследования. А имена методов называются одинаково, в данном случае. Т.е. интерфейс нам знаком и цепочку наследования мы знаем. Далее наше право использовать экземпляр как нам заблагорассудиться - либо как экземпляр его собственного класса, либо как экземпляр его суперкласса (о чем так неудачно заявил Мук).

"Если звезды зажигают -- значит -- это кому-нибудь нужно?"
если чтото запрятали в приват то может не дурак был этот человек. к томуже есть еще final даже есть final классы.

Иногда и так. Но как я писал в п.19 другого выхода, когда переменные имеют одно имя теперь ПРОСТО НЕТ. Только в приват их! Дурак не дурак - компилятор по-другому не позволит. А ведь может и не дурак и специально их одинаково обозвал (как раньше можно было в AS1) - ан нет. Пишите ка лишние геттер/сеттер функции для приватных переменных. Вот это все и делает код в AS3 более громоздким.

пока вспомнил про восмиричную систему.
Теперь ActionScript 3 интерпретирует строку, начинающуюся с нуля как десятичное число.

Ага. В п.17 я про это уже писал.

и по поводу onReleaseOutside тоже можно (естественно своими силами), поисчите 100 советов по AS3 от senocular тамже и про duplicateMovieClip было...

Да-да. Постоянно тут ссылки на эти 100 премудропескарских советов даю. Поэтому в п.14 и спросил, сколькистрочный уродец вышел.

[chingachgoog]

банальное ооп на классах проще читать писать и контролировать не аргумент?

Это не аргумент. Это спорное утверждение (если речь со сравнением с ООП на прототипах)

к томуже позволяет более жестко проверять типы переменных и описание методов еще на этапе компиляции...

Не. Это использование типизации позволяет проверять и контролировать. Собственно проверку типизации можно использовать и в AS1, если кому это необходимо (но с точки зрения выполнения программы просто в этом нет смысла - в AVM1 нет динамической трансляции кода)
Но подлинно динамическому коду проверка типизации транслятором только помеха.

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

Плохо не то, что кто-то пишет на классах или прототипах. А то, что AVM1 остановили в развитии. Ведь стоило в нее добавить работу хотя бы с тем же ByteArray и про AS3 вспоминали бы только сишники (хотя мне странно, что они делают во флеше, когда есть WPF с C#) или 3D-шники (код с динамической трансляцией пошустрей будет в мощных тригонометрических вычислениях).

И вообще прототип он чтобы добавить свою функцию, расширить функционал так сказать, например из жизни:
есть ByteArray и есть у него метод compress(algo: String) но во флеш плеере нету дефлейта тока zlib (algo = void - compress() ) поэтому приходиться переписывать алгоритм сжатия на флеш и очень удобно расширить ByteArray новым методом CompressDeflate...

Прототип можно использовать как угодно. Можно и для расширения. Как удобно было в AS1 расширять НЕПОСРЕДСТВЕННО нативные классы... Можно было бы и с ByteArray так делать:

Код

ByteArray.prototype.мой_метод=function(){...}

А можно было и подкласс сделать:

Код

SubByteArray.prototype=new ByteArray()

или так:

Код

SubByteArray.prototype.__proto__=ByteArray.prototype

[white-shadow]

Сразу: вы требуете конкретики, но сами говорите гибко и гибко, хоть один пример реального применения кода в студию (особенно про метод суперкласса по экземпляру).

ByteArray.prototype.мой_метод=function(){...} - этот код замечательно работает в AS3
а что может быть нелогичного в том что чтобы найти описание класса нужно открыть файл с его именем (зы компиляторы впринце побарабану сколько их).
как можно проверить код:

Код

ByteArray.prototype.myfunc = function (a: Number) {
   // ....
}

var b: ByteArray = new ByteArray();
b.myf();

на этапе компиляции?

"Но как я писал в п.19 другого выхода, когда переменные имеют одно имя теперь ПРОСТО НЕT" зачем переменным давать одно имя?

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

"Не пойму, к чему это?" это к тожу что можно сколько угодно доказывать что чтото плохо и неудобно, а все в большей степени зависит от программиста который этим пользуется, если нехватает опыта/умения то и никакие языковые конструкции не помогут, а если вернуться к объему - то размер исходного кода на одном языке не говорит о размере его скомплиированной версии (если исходник на АС3 и получиться больше в килобайтах то не значит что он будет больше в исполняемом виде, а скорее наоборот). Сначала тоже кричали про XP как все плохо, а 98 рулит и тоже говорили вот тут подругому тут не так и т.п., но реально поработав сейчас такого человека уже не встретишь (из Windows пользователей).


"А инкапсуляция, когда у экземпляра мы можем вызвать метод его суперкласса через __proto__ ни разу не нарушается" - не игнорируйте текст моего поста, я сразу написал примеры. А в отношении полиморфизма - все довольно узко - как было в процедурном программировании:
одно имя функции но много реализаций с разными параметрами, так и осталось только в другой форме (параметры вынесены в свойства класса)...

"Это не аргумент. Это спорное утверждение (если речь со сравнением с ООП на прототипах)".
"и про AS3 вспоминали бы только сишники" а это бесспорное из чего следует?

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

адоб хочет научить людей хорошему тону в программировании и не все с этим согласны, ИМХО.



Сообщение отредактировал white-shadow - 23.06.2009 - 00:17