Просмотр полной версии : Зачем AS превращать в Си++?
chingachgoog
04.11.2006, 16:52
Открываем хелп и берем следующий код:
var connection_nc:NetConnection = new NetConnection();
connection_nc.connect(null);
var stream_ns:NetStream = new NetStream(connection_nc);
my_video.attachVideo(stream_ns);
stream_ns.play("video2.flv");
честное слово обычный флешовский код будет работать ничуть не хуже:
connection_nc = new NetConnection();
connection_nc.connect(null);
stream_ns = new NetStream(connection_nc);
my_video.attachVideo(stream_ns);
stream_ns.play("video2.flv");
Не в этом ли была прелесть флеша: любая переменная может быть и числом и строкой и булевым параметром?
В чем тут подвох? Т.е. какой выигрыш?
А затем что в Си самый удачный и продуманный синтаксис.
А зачем нужно всё это писать? Вот пример я как-то приводил
http://flasher.ru/forum/showthread.php?t=87112&highlight=%EB%EE%EA%E0%EB%FC%ED%EE%E9
Выигрыш в том что в АС 3,0, флеш плеер не будет терять время на определение переменной.
a = 56;
что это? точка , мувиклип, срока, число.
var a:Number = 56
А здесь сразу ясно и тебе и плееру, что это число.
Проверка типов.
AS2 - проверка типов, если везде указаны типа, код легче читать, легче искать ошибку(особенно при использовании 50+ классов)
AS3 - Все вышеперечисленное, плюс при указании типа приложение работает быстрее.
Тему перенс в раздел для начинающих, автору темы устное предупреждение, ибо тема поднималась 1000 и 1 раз.
2 miramax
В си++ синтаксис не самый лучший.
2 miramax
В си++ синтаксис не самый лучший.
Он был лучшим... давно. Когда "боролся" с паскалем и бэйсиком )))
Теперь на основе Си и лучше появились синтаксисы
chingachgoog
04.11.2006, 17:17
Проверка типов.
AS2 - проверка типов, если везде указаны типа, код легче читать, легче искать ошибку(особенно при использовании 50+ классов)
Это спорно. Кому легче читать слева направо, а кому и снизу вверх. :-)
Дело привычки.
AS3 - Все вышеперечисленное, плюс при указании типа приложение работает быстрее.
А вот тут самое интересное.
Насколько велик выигрыш? Стоит ли из-за него пыхтеть вбивая столько "лишних" символов?
Это спорно. Кому легче читать слева направо, а кому и снизу вверх. :-)
Дурные привычки это плохо, это у юзеров могут быть привычки, а программист должен соблюдать правила и стиль.
А вот тут самое интересное.
Насколько велик выигрыш? Стоит ли из-за него пыхтеть вбивая столько "лишних" символов?
Сколько строк кода было в твоей самое большой "проге" ?
Уверен что после 1 000 наступит переломный момент... ООПэшник будет терять мало скорости девелопинга от рамера кода.
Интересно сколько раз ты напарывался на такое ?
a = 5;
trace( a+5 ) // ??? 10 или 55 ?
А выигрыш очень большой. Скажем до 20 раз для арифметических операторов.
И в фиг знает сколько раз быстрее будет проходить вызов метода ( не исполнение метода)
chingachgoog
04.11.2006, 17:50
...а программист должен соблюдать правила и стиль.
Сколько строк кода было в твоей самое большой "проге" ?
Уверен что после 1 000 наступит переломный момент...
Я понимаю, что программисту приятно тешить свое самолюбие "профессиональным" подходом и заморочками типа "правильного стиля", большим количеством строк кода и т.п.
Честно говоря мне интересен сугубо утилитарный подход:
за КОРОТКОЕ время написать ПОНЯТНЫЙ код, который будет РАБОТАТЬ.
если
a=5
против
var a:Number=5
то я выбираю первый вариант.
Когда повсеместно на коммерческий сайтах будут принимать работы в AS3 и он будет давать преимущества, то перейду ко второму варианту.
Я понимаю, что программисту приятно тешить свое самолюбие "профессиональным" подходом и заморочками типа "правильного стиля", большим количеством строк кода и т.п.
то я выбираю первый вариант.
Когда повсеместно на коммерческий сайтах будут принимать работы в AS3 и он будет давать преимущества, то перейду ко второму варианту.
Чё-та вспомнил анекдот про chingachgoog'ка и грабли....
Я много раз на них наступал.... И теперь внимательно слушаю советы опытных программистов, слежу за их стилем. Если что-то не знаю, стараюсь тупо следовать рекомендациям. Потом когда разберусь с чем-нибудь, для себя решаю как лучше писать код.
Посмотри сам на коды Nirth'a и __etc'а ....
Их классы можно использовать в любом проекте, эти классы можно доработать, эти классы относительно легко понять.
Да, в ас 2 нет настоящей типизации, но лучше писать типизированный код.
Это конечно твоё дело, в каком стиле писать, но рано или поздно сам поймёшь , что лучше изучить сначала чужой опыт, а не отвергать его после поверхностного осмотра.
DarkLight
04.11.2006, 18:09
2chingachgoog
Кстати, a=5 вместо var a = 5 внутри функции например или внутри цикла тормозит работу в 2-10 раз)
Сначала я тоже называл переменные a,b,c и думал что жесткая типизация - бред, но потом изменил мнение:
- читабельность не ухудшается
- проще отловить ошибки с повтором имен переменных
- в чужом типизированном коде разбираться легче
например есть переменная loaded, это может быть и процент загрузки и флаг ее окончания. Можно писать имена вроде mainMovieLoadedPercent, но это слабо читаемо. Код ПОНЯТНЫЙ и он БУДЕТ РАБОТАТЬ
miramax, я свободно могу писать как со строгой типизацие так и без нее. Во флеше мне всегда нравилась именно ее отсутствие. А проблемы поиска ошибок... либо я такой гений, либо еще что, но из-за ошибок типов за мою практику я ошибался не более 10 раз.
2chingachgoog
Кстати, a=5 вместо var a = 5 внутри функции например или внутри цикла тормозит работу в 2-10 раз)А причем тут типизации? var можно было и в 5 и 6 использовать, но типизации там не было.
DarkLight
04.11.2006, 18:25
2iNils
ну да...про var не в тему...
А про поиск ошибок...редко бывает...но пару раз из-за такой ошибки я полдня разбирался почему глючила флешка...
2chingachgoog
зачем затягивать с переходом на написание типизированного кода? Тогда его будет проще переносить на АС3
А вообще это личное дело каждого. А скорость написания кода - понятие относительное
miramax, я свободно могу писать как со строгой типизацие так и без нее. Во флеше мне всегда нравилась именно ее отсутствие. А проблемы поиска ошибок... либо я такой гений, либо еще что, но из-за ошибок типов за мою практику я ошибался не более 10 раз.
А как же этот случай ?
a = 5;
trace(a+6);
От теста к тесту трейс может быть разным !!!!
сначала я писал такие конструкции, а потом, по непонятным причинам плеер определял типы не верно. И мне приходилось перекапывать весь код, выставляя типизации.
т.к сначала
a = 5;
b = a+6
b было равно 11 , а потом 56.
И это самое безобидное что может произойти.
Что лучше, не делать ошибки или быстро находить их?
Люди полагаясь на то, что они быстро найдут ошибку, могут начать писать расслаблено и тем самым увеличивать их число. То, что у тебя разные трейс выходит, говорит лишь о том, что ты не предусмотрел проверку в процессе выполнения и перевод в нужный тип. Что будешь делать, когда данные будут поступать динамически?
Мирамакс вы начинаете косить под клишина, сходите к психотерапевту =)
Мирамакс вы начинаете косить под клишина, сходите к психотерапевту =)
Неееее)))
Я злился на типизацию. Я не понимал, нафиг это нужно, нафига все кругом пушит в два раза больше кода. Я не понимал почему все на меня лают за не типизирвоанный код. Пока сам не попробовал. Оказалось, плюсов больше чем минусов. Теперь это у меня в привычке, но типизация конечно не панацея.
И никому ничего не навязываю, а говорю как всё было у меня.
И никому ничего не навязываю, а говорю как всё было у меня.А выглядит совсем наоборот :) Надо четко понимать, что начинающие или даже у кого средний уровень, только осваиваются, а вы их типизацией по голове. Это пугает. А ввести типизацию в оборот и сделать это потом привычкой довольно быстро.
Согласен с miramax'ом : чем раньше учишься писать правильно и понятно, тем лучше. И типизация первый шаг к этому.
Реализуйте во флеше со строгой типизацией в аргументах, следущее аналог метода setTextFormat:
TextField.setTextFormat (textFormat)
TextField.setTextFormat (index, textFormat)
TextField.setTextFormat (beginIndex, endIndex, textFormat)
Реализуйте во флеше со строгой типизацией в аргументах, следущее аналог метода setTextFormat:
TextField.setTextFormat (textFormat)
TextField.setTextFormat (index, textFormat)
TextField.setTextFormat (beginIndex, endIndex, textFormat)
Боюсь здесь тупик, т.к. в AS нет понития "сигнатура". Можно поставить аргументы по дуфолту. Можно только так
TextField.setTextFormat (textFormat, beginIndex, endIndex) Да и не логично это, менять порядок аргументов в функции.
Хотя.. может кто-то и реализует ? :)
Как вариант: не подойдет, проверять в методе setTextFormat типы передаваемых аргументов (массив arguments) и в зависимости от этих типов делать то что нам нужно?
Реализуйте во флеше со строгой типизацией в аргументах, следущее аналог метода setTextFormat:
TextField.setTextFormat (textFormat)
TextField.setTextFormat (index, textFormat)
TextField.setTextFormat (beginIndex, endIndex, textFormat)
А чем это относиться к типизации? во флэше нету оверлоадинга, но оверлоадинг в конечном итоге просто замещается на обычную проверку типов аргументов функции как сделанно например в as2lib
потом динамичность никто не отменял, а код со строгой типизацией действительно легче читать. (ИМХО)
class TextField {
public function setTextFormat ():Void {
if (TextFormat (arguments [0]) != null) {
__setTextFormat (0, this.length, TextFormat (arguments [0]));
} else if (TextFormat (arguments [1] != null)) {
__setTextFormat (arguments [0], text.length, TextFormat (arguments [1]));
} else if (TextFormat (arguments [2] != null)) {
__setTextFormat (arguments [0], arguments [1], TextFormat (arguments [2]));
} // end if
}
private function __setTextFormat (beginIndex:Number, endIndex:Number, tf:TextFormat):Void {
}
}
А я бы проверку на каждый параметр поставил, какого он типа — Number, String, Object и т.п. и указал бы везде тип Object.
Что касается типизации, то, к примеру, FDT научит ею пользоваться и застрахует от ошибок в типах. Если не проставишь тип — ошибка, если где-то захочешь присвоить значение другого типа — тоже ошибка. Это позволяет найти ошибку в кратчайшие сроки, даже не компилируя по сто раз проект.
Вы можете и не пользоваться FDT, писать код в блокноте и, если он работает и нет проблем с типами данных — хорошо. Но я бы ни в коем случае не выложил класс в сеть для общего пользования. Потому что если такой класс положить в тот же FDT (как бы я и сделал), то ошибки и варнинги будут если не на каждой, то через одну строку. Не хочу потом целыми днями икать, когда те, кто решили воспользоваться моим классом, будут меня поминать нехорошими словами. Бывают ещё такие моменты, когда две ошибки, сложенные вместе, приводят к верному результату и фактически о них, если ничего не проверять, можно забыть навсегда.
говорит лишь о том, что ты не предусмотрел проверку в процессе выполнения и перевод в нужный тип
Верно, и кто об этом должен позаботиться? Конечно же компилятор.
Я же не должен кастить переменную, которую я обьявил типа Стринг в Намбер везде, где я ее использую.
Без строгой типизации компилятор нам ничего не скажет.
Верно, и кто об этом должен позаботиться? Конечно же компилятор.
Я же не должен кастить переменную, которую я обьявил типа Стринг в Намбер везде, где я ее использую.
Без строгой типизации компилятор нам ничего не скажет.Причем тут компилятор?
Если вы вводите число в текстовое поле, а потом хотите с ним произвести некое математическое действие, то делать Number (txt) будете вы, а не компилятор.
Если я в классе объявил
private var s:String;
....
а потом где нибудь в функции сделаю так
private function func(n:Number) {
s = n;
}
то комилер ругнется.
ir73, как раз должен. Компилятор понятия не имеет, что вы хотите сделать с переменной и он не телепат.
И правильно ругнется компилятор, потому что просто так сказать, что слон равен мухе нельзя.
Rustem-inside
05.11.2006, 16:45
Мирамакс вы начинаете косить под клишина, сходите к психотерапевту =)
Что вас беспокоит? Вы хотите поговорить об этом?
ir73, как раз должен. Компилятор понятия не имеет, что вы хотите сделать с переменной и он не телепат.
И правильно ругнется компилятор, потому что просто так сказать, что слон равен мухе нельзя.
ну я вроде как раз это и написал.
А я бы проверку на каждый параметр поставил, какого он типа — Number, String, Object и т.п. и указал бы везде тип Object.
Для чего же потом указывать тип Object? Почему не вызывать потом разные методы с этими же типами данных?
Для того, что после получения данных не делать никаких преобразований типов и проч. Просто в зависимости от типа вызывать соответствующие ему методы.
Если вы поставите тип Number, то в случае, если параметр окажется типа String, то компилятор вам скажет, что вы типом ошиблись. В случае использования Object такого не произойдет.
Мы проверяем тип данных typeof (пусть будет пременная someVar) и в зависимости от его типа вызываем тот или иной метод, если typeof someVar показал что тип Number- что нам мешает предавать в качестве параметра Number(someVar)? Ошибки гарантировано не будет (т.к. приведение типа самого к себе пройдет успешно), а метод будет принимать в себя правильные типы данных, а не абстрактные Object.
Можно и так, но выше был поставлен четкий вопрос и это ответ на него.
Sneg, не, можно, конечно, проверять arguments.length, но можно указать Object и проверять их тип. Равнозначно.
Типизация (не в AS2, правда) способствует увеличению скорости работы. Компилятор точно знает, что работает с конкретным типом данных, не говоря уже о том, что простые типы данных гораздо быстрее работают.
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.