onEnterFrame: delete vs null
 

Две нижеприведенные строчки казалось бы выполняют одно и тоже. По крайней мере мне так какзлось до определенного момента. Хотелось бы услышать про отличия в их работе, когда какой из вариантов следует использовать. У меня почему-то в некоторых случаях работает только 1й вариант (могу привести конкретные примеры, но хотелось бы понять суть их работы, поэтому я пока послушаю теорию, и если не осилю - буду упрощать свою задачу и предлагать конкретный код)
Заранее спасибо.

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

Т.е. в 1с варианте сама функция onEnterFrame не исчезает? Т.е функция продолжает работать, возвращая "ничего"? Тогда есть ли смысл в такой конструкции?

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


Так вот если не выполнить прединициализацию свойства myProp компилятор выдаст ошибку.

А вообще-то null означает "пустое" значение. Оно нужно если мы нехотим передавать никакое значение значение параметра в функцию. Или, допустим в какой-то момент мы незнаем значение переменной, но в данном конкретном месте ее прединициализация целесообразна из соображений контроля типов, ну и тд.
Однозначно пользуйтесь delete

Alex_beginner, спасибо за исчерпывающий ответ.

Alex_beginner, инициализации при объявлении вовсе необязательна, достаточно и var myProp:Number;
кстати, поправь свой пример, объявить свойство класса как this.myProp:Number = null; никак не выйдет

ps: onEnterFrame не нуждается ни в инициализации, ни даже в объявлении поскольку речь все же о наследниках MovieClip,
т.е. такой класс, например, не вызовет ошибки:

Несколько раз обсуждалось это. Использовать нужно delete.

silin! Красивый реверанс)). Вы не забывайте Вы создали подкласс от MovieClip, в нем инициализирован этот метод(onEnterFrame). А здесь Вы его просто переопределяете. Пожалуйста, мою мысль некаверкайте и людей с толку несбивайте.

сори, не имел намерения каверкать Вашу мысль, а только уточнить некоторые нюансы с инициализацией:
-инициализация при объявлении не нужна, а в некоторых случаях и вредна (инициализация непримитивных типов в AS2 приводит к неприятному косяку)
-поскольку вопрос был об onEnterFrame, то логично и говорить об наследниках MovieClip, у которых onEnterFrame уже есть (какой смысл в "прединициализации" в этом контексте не очень понятно)
-onEnterFrame в MovieClip не инициализирован (undefined), а только объявлен, но этого достаточно

ps. дискутировать не стану, нечего обсуждать

Верно! Дискутировать неочем, я рассказывал в начале TanaTix о null, а не о onEnterFrame (см. выше). Об onEnterFrame я "заикнулся" в конце поста.
Слово "объявлен" лучше подходит к тому что я имел ввиду. Тут вы правы.
Но приводить такой пример, где скрыта идея об объявлении от вопрошающих, было дело скорее запутывающее их, нежели раскрывающее сакральный смысл объявления и инициализации свойств. Теперь люди будут думать, что такое возможно - без предварительного объявления создать в нединамическом классе свойство или метод (синтаксис АС2).

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

Об этом я говорил выше!!:):D Но мы то должны им еще до компилятора разъяснить, а то нашим разъяснениям грош цена:)

В этом нет ничего невозможного.

Замечательно, что проверка "верности" кода компилятором настолько же тупа, как и сама идея такой проверки. Т.е. компилятор можно запросто надуть.

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

chingachgoog!
А обоснование в примерах.
А потом зачем вообще компилятор надувать - он призван помочь Вам не далать грубых ошибок. Он вроде соседа который напомнил Вам, что Вы забыли ключи от квартиры (пример Колина Мука).

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

silin!!:taunt::taunt::D:taunt:
Прошу прощенья!

Давайте, ваш пример. А я покажу как компилятор надуть :)

А если не забыл? Если я ключи специально не взял? А этот тупой сосед меня не пускает на улицу без ключей? Я ему спасибо должен сказать?

chingachgoog!
В этой ситуации, обход компилятора дело нужное, не спорю.
Но таких ситуаций относительно немного. Тогда, как ситуаций, когда этот "сосед" находит из 10 000 куб.м кода мелкую ошибку (не логическую), поверьте, он сильно облегчает Вам жизнь, сокращая Ваш поиск данной конкретной ошибки до минимума.


А то, что касается примера, то Вы упустили логическую цепочку нашего разговора, а именно, Вы (не я) утверждали, что без предварительного объявления создать в нединамическом классе свойство или метод (синтаксис АС2) вполне возможно, обманув компилятор. Посему, Вы и должны представить код, доказывающий Вашу правоту.

Согласен. С помощью синтаксиса доступа [] можно создать сие свойство.
Но ведь с помощью [] можно получить доступ даже к приватным свойствам и методам класса (баг), т.е. "увенчаные" директивой private, другое дело нужно ли это, если есть официальный синтаксис. А то все перемешается сразу динамические классы, нединамические итд.

AS2 не существует. Существует конвертер AS2 в AS1 и все, а посему ничего удивительного и странного в том, что нет прав доступа и прочих фич, нет.

__etc, а что, компилятор AS3 так не проведешь?

Конечно нет. Даже если и проведете, то получите ошибку уже в runtime.

Ну значит это дело времени - пока AVM2 еще не распотрошили как AVM1 :)

Это вы не распотрошили.