Четырнадцатый мегавыпуск мегаподкаста.
- Media Temple DDOS
- I was featured at art lebedev studio’s business lynch project
- NAS iStor 607
- Игра для Braun
- Как меня обманули Морганы во вконтакте
- MXML в AS3 проектах и как я патчил компилятор
- Как я притворялся бомжом, чтобы получить Flex Builder
- Как мы ржали над вакансиями и где взять AS2 программиста?
- Сложность разработки социальных игр
- Unity3d, Flash и JD interstellarmarines.com
- HTML5 vs Flash, куда без него
- AS3 — отстой
- Джоинимся в RAFPUG и приглашаем ботов во имя добра!
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
Я автор той статьи на хабре. В примере про трейс abc, проблема не в порядке сортировки, а в том что {} и new Object() ведут себя в этом примере по разному, т присваивание в new Object() работает конкретно, с учетом что из документации следует что это один и тот же тип объектов.
Мне интересно мнение про пиление сука, на котором сидишь, и как вы предлогаете модифицировать объекты с большим количеством параметров и возможно вложенных объектов с максимальной экономией ресурсов. Поделитесь тайными техниками?
Я предлагаю не использовать нетипизированное хрензнаетчто вообще. Собрать все свойства в самом начале и пробежать потом. Правда, это не подходит под экономию ресурсов. Все это барахло написано индусами программистами и тянется еще с AS1. У нас в AS3 до сих пор наследование через прототипы держится. Если смотреть внутрь, то {} и new Object() компилятся в совсем разные инструкции:
NewObject 0
и
FindPropStrict QName(PackageNamespace(”"), “Object”) ConstructProp QName(PackageNamespace(”"), “Object”), 0
>> Я предлагаю не использовать нетипизированное хрензнаетчто вообще. Собрать все свойства в самом начале и пробежать потом.
Ага. Это если по уму, можно еще везде и try..catch..finally использовать. Если бы не приходилось еще помнить о пользователях маков у которых производительность в 4 раза ниже win, и каждое лишнее дествие обходится дорого. Я лично подстраиваюсь под ситуацию, если можно кривым кодом, дать дополнительную производительность пользователям – я буду так делать. А если adobe это пофиксит, перейти на типизацию свойств – не проблема.
На на данный момент индусы пишут код плеера, так что подстраиваться приходится разработчикам а не индусам и чтобы они не написали, проблемы придется решать flash разработчикам.
>> Если смотреть внутрь, то {} и new Object() компилятся в совсем разные инструкции
Я это знаю, о чем и сказал в том посте на хабре в комментариях.
Я какбы согласен, но такие посты разворачивают очередные тупые холивары со стороны ничего не понимающих типов. О чем я собсно говорил на примере некоего пхпшника. Ну так и живем.
Каждый хвалит свою корову, даже если она мертвая. Мне для моих проектов необходимы все возможности языка и плеера. трейс abc это косяк адоба, если это происходит из-за особенностей плеера или AVM, и просто следует использовать в таких случаях new Object ИМХО следует это указывать в документации и отмечать, что это два разных типа объектов, и делать этот текст красным и моргающим.
Со всеми случаями описанными в статье на хабре я сталкивался непосредственно на своем опыте и это статья была объяснением для пользоватлей наших с вами аппликаций далеких от всего этого, в каких случаях виноват разработчик, а в каких индусы из адоба.
слова “экономия ресурсов” и “for in” не сочетаются в принципе
for in медленнее for each в 12 раз, а for – в 15
http://jacksondunstan.com/articles/358
Я это прекрасно знаю. Как через for each получать имена свойств?
Сохраните все свойства через for in в массив, потом уже обходите только массив и меняйте свойства объекта как вам нужно.
А во время for in никаких действий с объектом совершать не надо.
То есть два прохода циклом + доп объект это экономия ресурсов? У меня в динамическом объекте может хранится B-Дерево, каким образом мне сможет помочь массив со свойствами? Если я буду использовать типизированные значения, количество памяти и CPU для работы с ним увеличется в разы, а деревьев могут быть тысячи.
ваше дерево явно не из ниоткуда берется, значит можно сразу загонять его в массив и работать уже с ним
Да, оно берется из внешних нетипизированных данных, тип которых определяется только на момент исполнения кода обработки. К тому же нужна возможность хранения индекса веток, так что массивы тут не подходят. К тому же необходима возможность мерджинга деревьев, опять же с максимальной производительностью.
Древовидные структуры данных бывают разные, изменяемое R-дерево, можно создать только на основе динамических объектов. К тому же если врехняя ветка будет не валидна, можно просто уйти из цикла обработки вашем случае я потрачу кучу ресурсов на поврежденные данные.