Ну, не знаю, как еще объяснить, ну, не возможно скрестить верблюда с носорогом...
Строгая типизация - это не только удобство, это то, что делает в конечном итоге вычисления и работу программы быстрее. Поэтому, либо строгая типизация + быстрая работа, либо отсутствие типизации + медленная работа. 2 в одном получить не удасться, потому как эти вещи не совместимы вообще никак, они в корне противоречат друг другу.

Что невозможно? Сделать новую AVM совместимую со старой? На 100% уверен, что возможно. А вот почему не сделали - вопрос другой. Но опять-таки уверен, что дело вовсе не заботе о пользователях и их удобстве.

Вот характерное заблуждение. Типизация ГДЕ существует? В скрипте или в байт-коде? Поэтому если в байт-кодах типизации нет (и старый добрый флеш использует динамический код), то о каком убыстрении работы идет речь?

Кто бы говорил про наглость.
Так значит ты chingachgoog хочешь сказать что ты скрипт не заказывал? :)

http://flasher.ru/forum/showpost.php...9&postcount=38

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

простите, но вы вообще не в курсе по поводу внутреннего устройства файлов скомпилированых для AVM2... вы несете чушь, стыдитесь! =).

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

Вы путаете причину со следствием. Да, в НАСТОЯЩЕЙ ситуации AVM1 несовместима с AVM2. Но это вовсе не значит, что ее нельзя было сделать совместимой. Насчет "ничего общего" - я бы так не говорил (см. расчеты веса ФП 8 и 9 версий).

А при чем тут внутреннее устройство в AVM2. Да я его не знаю. И думаю вообще его мало кто знает (иначе мысли нехорошие могут возникнуть).
Или вы хотите сказать, что код написанный на AS3 БЕЗ строгой типизации работать не будет? Будет.

add:
http://flasher.ru/forum/showpost.php...9&postcount=38
(администрацию о лживых сообщениях TERRORist уведомил)

Поймите, что вы хотите проапгрейтить чернобелый телевизор до цветного... да, это где-то близкие вещи, но кроме коробки и провода питания вам нечего будет взять от старой модели. Или вы бы пошли по пути изобретения сверхточной технологии по отделению светочуствительных элементов впаяных в матрицу Ч/Б экрана и замене их на новые, способные отображать разные цвета? Зная, что жить этой технологии ровно пару секунд на время апгрейда?
А размер плеера такой, потому что в нем половина - поддержка AVM1... помоему это очевидно...

Код написаный без типизации будет работать так же плохо, как и любой код написаный для AVM1 - т.е. медленно.

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

Кстати это задача элементарная (точно также как и в случае с AVM).
Эту задачу решали еще в XIX в (для кино конечно).

Наоборот. Размер ФП, на удивление МАЛЕНЬКИЙ. Т.е. логично предположить, что AVM1 и AVM2 в нем частично совмещены, а не полностью раздельны.

Как это не имеют??? С чем работает AVM? Со скриптом или с байткодом? Если бы в байткоде присутствовала типизация, то тогда бы еще можно было предположить, что время выполнения байткода от этого улучшается. Но типизация - в скрипте - и живет ровно до компилирования в байткод. Потому на скорость выполнения интерпретатора байткода она никак не влияет.

NB!
Кстати, насчет "информативности" строгой типизации.
Помимо засорения текста кода дополнительными символами есть еще один момент. Что будет с информативностью через полгода?
Так, строчка коментария "тут делается то-то" будет через полгода самым ценным местом кода и никакая типизация по информативности с комментарием не сравниться (а по объему текста комментарий много меньше текста типизации и расположен более удобно - чуть в стороне от кода, а не внутри него).

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

Не знаешь не лезь:)
В avm2 типизация сохраняется.
Пример
Результат примерно 450, если убрать типизацию у "e", то уже 1870

Роль типизации огромная в плане автокомплита, никакой комментарий не поможет тебе вспомнить множество методов и свойств у объекта класса написанного полгода назад, придется лезть и смотреть исходник.

Ну, смотрите, насильно мил не будешь, не хотите поверить на слово - чтож, это кажется Черчиль сказал, что готов положить жизнь за право другого человека иметь точку зрения отличную от его собственной =) Есть разумный предел любым попыткам убедить кого-то. Иногда, усердная агитация только мешает адекватному восприятию. Поэтому, на этом я прекращаю спорить. В конце концов, вы взрослый, нормальный человек - захотите - сами все поймете =)

ЗЫ. В 19-м веке не было телевизоров...
ЗЫЫ. По поводу быстродействия и связи с байткодом: вот вам элементарнейший пример, умышленно не связаный с флешем, и сильно упрощенный:
существует такой формат видео файлов AVI, внутренний формат которого, как правило RIFF, принцип построения файла очень простой:
есть чанки - каждый описывает дату одного кадра, и есть заголовки - 16 байтов описывающих соответственно: 4 - "заголовок канала", 4 - нули (разделитель), 4 - длина чанка, 4 - позиция в файле. RIFF не регламентирует куда писать заголовки, т.е. их можно записать и в начало файла и в конец (большинство редакторов пишут их в конец файла). Так вот, представьте, что у вас AVI файл размером 2Гб (это его максимальный размер), и у вас есть приложение, которое должно воспроизводить видео. Если бы заголовки были в начале, а еще лучше - перед каждым соответствующим чанком, приложению бы не пришлось листать огромный файл из конца в конец для определения где же начинается следующий кадр. И вообще, можно было бы потоком передавать самые обычные AVI файлы... Но, при абсолютно одинаковом количестве байткода на чтение файла может уйти разное время и разное количество системных ресурсов.

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

Надо же - не знал.
И как же это на уровне байт-кода организовано?
В чем разница будет в байт-коде у просто e и e:Number?
Может дело не в типизации, а в компиляции?

Может быть. Однако пока я не достиг, видимо, ТАКОГО уровня "множества" методов и свойств у объекта. А строки внутри кода типа :Длиннющее_название_класса делают код для меня менее читабельным.

Ну да ладно, дело ведь не в типизации - ее-то как раз макромедия с адобом сделали НЕ обязательной. И это я приветствую - кто хочет - типизирует, не хочет - не типизирует. Это правильный подход.
А вот насчет поддержки AVM1 дело совсем другое. Даже __etc долго юлил, но в конце концов в посте 28 фактически согласился, что имеет место насильственное сдерживание AVM1 перед AVM2.

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

Я же сказал, что о кино :)
Но этот принцип также хорошо сработает и на ч/б телевизоре, если вы догадались о чем я. (подсказка - см. принцип работы одноматричного проектора).

Действительно. И те, каких, видео кодеки, столько понаписали. Зачем? Можно ведь было так написать, чтобы была обратная совместимость.
Я ведь написал "не знаешь, не лезь" не просто так, что бы спорить, надо знать тему спора. А ты не знаешь. Пример с типизацией тому свидетельство. А тебя поддерживал в мысли, что в avm1 могли бы побольше добавить возможностей который появлись в as3, который добавить можно. Но в теме, что avm2 не нужна совсем, ты похоже в одиночестве.

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

__etc, а зачем повторять? Номер поста я дал. Если кто-то увидит там другое - ну чтож...
Решили продолжать утверждать, что бюджета не хватило сделать чтение метки кадра или останова всех циклов? :)

С кодеками дело другое - там война форматов идет. А с кем воевать swf? ФП только адоб выпускает.

Так я не спорю, а узнать хочу!
Есть байт-код примера с e и e:Number?

Не говорю я, что AVM2 не нужна. Даже в том неправильном виде, что она есть - я не против - нехай буде.
Я против насильственного насаждения AVM2.
Сами подумайте и честно ответте на вопрос (это не только к iNils):
сделали бы в AVM1 функционал как в AVM2, то сколько бы народу перешло бы на AVM2?

Последний раз говорю: AVM1 для Adobe умер, причем отсутствие вами перечисленных фич наглядно это показывает. Если вам угодно, то это сделано специально. Тем более, какой смысл добавлять эти фичи, если они один фиг требуют нового плеера, в котором уже есть новая AVM. Рано или поздно, вам придется переходить на неё и для вас таких любителей AS1 даже предусмотрели писанину в кадрах и без типизации, хотя я бы за это руки поотрывал.

Это понятно, как и то, что это ошибка адоба.

Конечно мне угодно, чтобы вещи назывались своими именами.

Вот люблю я таких радетелей о моем счастье, которые готовы мне руки поотрывать :)
Чем хорош AS1? Хочешь - в кадрах пиши. Хочешь - в скриптовых отдельных файликах (называй тоже как хочешь).
Вот интересно: меня ни капли не злит ни AS2 ни AS3. Но почему же столько ненависти к AS1? Что мешает сделать его нормальную поддержку, раз ВСЕ РАВНО во ФП будет AVM1?

Это не ошибка, а эволюция. Для вас пусть будет ошибка.

Да, собственно, и в AS3 в IDE тоже самое есть.

Лучше полмегабайта нового кода в AVM2 засунуть, чем ещё столько же в AVM1.

Ага. Ошибкой эволюции. И экономисты это поймут.
(+ см. мой общий вопрос)

Смогете в кадрах классы AS3 написать?
А в AS1 классы можно и в кадрах и во внешних файлах писать.
К тому же в AS3 есть ограничения на код в кадрах.

А у меня нет уверенности, что они полностью раздельно существуют. Т.е. врядли придется ДУБЛИРОВАТЬ функционал.

Без комментариев.



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

Где я могу классы в кадрах писать? В AS3?
Чем класс в AVM2 классичнее класса в AVM1? :)

Зачем Вам кадры эти. Я тоже раньше думал, что в кадрах удобнее, но сейчас даже на работу не беру где AS2. Потому что жутко неудобно. Если Вы не хотите учиться делать правильнее,а не тяп ляп, то флаг Вам в руки. Понимаю кадры только со стороны художника, а не программиста.

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

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

А в чем тут плюс? Скорее наоборот.
А насчет того, что нельзя - не уверен.

Так вы ответте на вопрос: кто будет писать на AS3 (AVM2), если AVM1 проапдейтят? Я понимаю, отчего такое затруднение с ответом.

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

Проапдейтить каким образом? Добавить те фичи, что вы перечислили? Если да, то ничего не изменится, никто не побежит писать на AS1/AS2 ради этих фич, т. к. они уже есть в AS3. Работа с бинарными данными, e4x, права доступа, типизация, рантайм проверки? Этого не будет в силу архитектуры и скорости работы AVM1.

Отчего же? Просто, например, далеко не сразу ПОСЛЕ того как я писал на AVM1, я смог разобраться как же она на самом деле работает и что там можно обойти запреты. Предполагаю, что и тут также. Запреты есть, но это не значит, что их обойти нельзя. Наверняка есть способы или недокументированные методы, типа ASSetPropFlags.

Опять же интересно. Зачем мне ломать голову собирать какой-то конструктор из разных программок? Есть флеш-редактор и там все должно быть. Никаких проблем с кодом у меня нет.

Вернее никто не побежит на AS3, так как они И ТАК есть (в смысле будут если...) на AVM1.

Возможно, а возможно и нет. Все зависит от желания апдейта.

Нетрудно понять какого уровня код :)

Может хватит? Никто ничего менять не будет, ибо нет необходимости.

Запреты есть и обойти нельзя, хаки — бич AS1/AS2. Язык должен позволять все, но не позволять издеваться над собой.



Это вам минус, как разработчику, что вы не используете инструменты, упрощающие и увеличивающие скорость разработки. Вы хоть раз пользовались редакторами типа FD, FDT, Sepy? По всей видимости, нет. Вы же и на AS2-то не пишете.



Вы всерьез полагаете, что не бывает задач, в которых не требуется ничего из AS1/AS2+перечисленные вами фичи?


Если бы все было так просто, то AS3 бы сейчас не существовало. Ну, право, зачем он нужен, когда у нас есть доступ к меткам кадров?

АС1 и АС3 очень разные и у каждого своя сфера применения. Мне понятна точка зрения человека, который не хочет учить АС3 - это не означает, что человек дурак, просто все-таки писать банеры удобнее на нем.

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

Ща как дам по МувиКлипу, все Фреймы посыплются! ©

А почему обязательно куда-то надо идти? Представьте, что у вас есть проект, который разрабатывался в течении 2-3 лет еще на as2 и продолжает дорабатываться. А в as3 появились вещи, которые бы вы с радостью у себя использовали, но для этого вам надо сначала потратить время и средства на переписывание всего проекта под as3, при том, что выигрыш будет только от самих этих фич, так как феш в проекте не требует скорости работы AS3. Вот и скажите, выгодно вам с финансовой точки зрения переходить на as3 или нет.
Ой, ну не надо про чудовищ. AVM1 прекрасно справлялась и справляется со многими задачами, а иногда и лучше AS3 (взять тот же onReleaseOutside).
"Как хочу так и верчу", с чего вы взяли, что не принесет? Полный переход на AS3 будет долгим процессом, и в течении этого времени многие люди будут писать на AS1/AS2. Но вот какой смысл покупать им новые IDE? Ведь возможности для as1/as2 те же самые. То есть, либо они переходят на as3 и покупают, ведь возможности те же самые.
И скажите, сколько времени и денег уйдет на добавление метода, который возвращает имя метки текущего кадра? Страшно много?

Да нет, я говорил о MPEG-1, MPEG-2, MPEG-4, а не о Blue-Ray vs. HD DVD

Будет - не будет, есть - нету, работает - не работает, сделали - не сделали...
8 страниц пустого флуда, а у нас заводы стоят...

В продолжение можно добавить, что обычный фрезерный станок все-же лучше убожества с ЧПУ

Угу, я прекрасно фрезерным пользуюсь, как захочу. Нет, а то пихают это ЧПУ, лучшеб интерфейс бы для фрезерного бы сделали!

Свой уровень вы показали этим сообщением :)

Нет необходимости?
Обоснуйте.

А я уверен, что можно много чего обойти.
"Хаки" - это такие же элементы языка, основанные в первую очередь НА ПОНЯТИИ механизма работы AVM. Просто сейчас механизм работы AVM2 плохо изучен, но это дело времени. Никакого криминала или "бича" тут нет.

А зачем мне "упрощать" и "увеличивать скорость" разработки если она у меня и так упрощена и достаточна? Именно потому, что я пишу на AS1. Писал бы на AS2/3 то конечно в стандартном флеш-редакторе было бы непросто.

Ну что вы, я даже полагаю, что есть задачи где НИКАКОЙ флеш не справится. Ну и что? Бросить флеш перейти на ассемблер? :)

А все действительно просто. Просто надо честно ответить на вопрос (без юления о бюджете и т.п.): почему адоб БОИТЬСЯ расширить функционал AVM1?

Спасибо, Яски. Баннеры я уже несколько лет не пишу. :) Но мне тоже понятна точка зрения, кто считает, что раз AS1, то значит - баннеры. Это точка зрения тех, кто слабо разбирается в функционале AVM1 и с большой вероятностью не сможет переписать классы AS2/3 под AS1 (и даже удивится, что классы есть в AS1).

Что значит ДАЛЬШЕ? Дальше изучать ассемблер? А зачем?
А вы дальше не хотите изучить как все-таки работает ФП, AVM1 и как переписать классы из-под AS2/3 на AS1? Это лень или что?
Я вот искренне не понимаю таких высказываний. Раньше: хотел человек писал на AS2, хотел на AS1. Все в равных условиях, с одинаковым набором возможностей.
А сейчас не то, что набор неодинаков, но так его еще и искусственно сдерживают.

Адоб добьется только того, что флеш станет не более популярен, чем си++ билдер вот и все. Со всеми вытекающими в т.ч. и финансовыми.

матерый тролль, давно такого не видел ))

люди, dont feed the troll. Вас разводят

А что в AS1 были классы?:eek:
Я не говорил, что язык плохой, но для тех задач, что я решаю он не удобен и не подходит по скорости.
Билдер это IDE, причем здесь это?

Были, только они писались по другому.