Быдлокод?

[orcpochta]

Полный пример:

var xml:XML = <LOCATIONS>
<LOCATION ID = "1" STATUS = "OPEN" />
<LOCATION ID = "2" STATUS = "CLOSE" />
<LOCATION ID = "3" STATUS = "OPEN" />
<LOCATION ID = "4" STATUS = "CLOSE" />
<LOCATION ID = "5" STATUS = "OPEN" />
</LOCATIONS>;

var openLocationsID:Vector.<uint> = new Vector.<uint>();

xml.*.(@STATUS == "OPEN" && openLocationsID.push(@ID));

trace(openLocationsID);

//#################################

//Output: 1,3,5

Вот эта строчка добавляет в вектор id открытых локаций:

xml.*.(@STATUS == "OPEN" && openLocationsID.push(@ID));

- быдлокод?)))

[i.o.]

- нет.

[orcpochta]

- нет.

обоснуйте свою точку зрения, пожалуйста))

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

[i.o.]

e4x фильтр это называется, а не костыли)

[Котяра]

Я вообще считаю e4x очень быдлокодным в принципе, но он сокращает запись и в чём-то удобен - остаётся только привыкнуть).
Минус его в абсолютной неООПности, т.к. выражения очень зависят от структуры конкретного XML.
А RegExp вообще брэйнфак, но бывает очень нужен.

[orcpochta]

e4x фильтр это называется, а не костыли)

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

Добавлено через 6 минут

Минус его в абсолютной неООПности, т.к. выражения очень зависят от структуры конкретного XML.

Мне кажется он гораздо менее привязан к структуре, чем DOM-овский вариант из AS2, и как-то более абстрактен, что ли...)))

Добавлено через 10 минут
Хотя вы наверно имеете в виду его привязку к именам, а не к структурному скелету, про которую я подумал)))

[iNils]

Если с проверками, то так
var xml:XML = <LOCATIONS>
<LOCATION ID = "1" STATUS = "OPEN" />
<LOCATION ID = "2" STATUS = "CLOSE" />
<LOCATION STATUS = "OPEN" />
<LOCATION ID = "4" STATUS = "CLOSE" />
<LOCATION ID = "5" STATUS = "OPEN" />
<LOCATION ID = "6" />
</LOCATIONS>;

var openLocationsID:Vector.<uint> = new Vector.<uint>();
xml.*.(hasOwnProperty ("@ID") && hasOwnProperty ("@STATUS") && @STATUS == "OPEN" && openLocationsID.push(@ID));

trace (openLocationsID);

[f.g.programmer]

А если нужно будет брать из LOCATION ещё какую-то информацию?
Этот код не читаем (антисоциальный, бескультурный) и крайне не гибкий (грубый, неотёсанный). Его вполне можно назвать быдлокодом.

[iNils]

А если нужно будет брать из LOCATION ещё какую-то информацию? А если не нужно? Что вы придумываете? Код пишется исходя из задачи. Код вполне читаемый. Гибкий? Гибкость кода определяется не одной строчкой, а набором решаемых задач блоком кода.

[f.g.programmer]

А если не нужно? Что вы придумываете? Код пишется исходя из задачи. Код вполне читаемый. Гибкий? Гибкость кода определяется не одной строчкой, а набором решаемых задач блоком кода.

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

<LOCATION ID = "5" STATUS = "OPEN" />

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

xml.*.(@STATUS == "CLOSE" && closeLocationsID.push(@ID));

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

[orcpochta]

>>но в целом это кажется признаком не очень хорошего стиля.

Можно подробней, чем не угодил стиль в случае, когда в каком-то месте программы надо получить список локаций с одним конкретным статусом (даже если статусов более двух)?

Можно, конечно, предположить, что вам не понравилось, что используется магическая строчка "OPEN", а не статическая константа какого-нибудь класса вроде LocationStatus.OPEN, но при чем же здесь как таковая фильтрация xml с занесением результатов в вектор?

[iNils]

А может и не существует. Может разбор вообще ведется после определенного действия пользователя, которого может и не быть.
Это как с if, в зависимости от числа условий, сложность и вложенность if может быть различной.
Не давно была тема про "?:". Там тоже звучали слова про "читабельность". Вот сейчас у меня в проекте есть список действий в switch, больше десятка. Но в зависимости от дополнительного условия, эти действия могут запускаться с разными числами. Типа
offset = isFace ? 10 : 8;
И если использовать if else, то все это разрастается в высоту и становится не читабельным. Но в повседневной жизни "?:" не очень удобен.

Здесь так же. Решается конкретная задача и для этой задачи такой вид кода допустим. Будет другая задача, можно будет пересмотреть код. Будет третья, тоже может придется. А еще... можно писать комментарий над строкой.

Кстати, написание regexp тоже смахивает на быдлокодерство, предлагаю разбирать строки вручную с помощью if и indexOf :D

[f.g.programmer]

?: и regexp прекрасно справляются со своими задачами не уменьшая читабельности, а иногда и улучшая, если ими не злоупотребляют, как здесь с фильтром.

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

[iNils]

f.g.programmer, вот и фильтр прекрасно справился со своей задачей )
Хотите увидеть настоящий быдлокод?
function sample (flag:Boolean) {
if (flag == true) {
///
}
}

[orcpochta]

В чем здесь быдлостность кода?)))

[Bgg]

Видимо стоит писать так:

if (flag)
//вместо
if (flag == true)
ах да, наверно ещё не указано что функция возвращает void

[iNils]

В чем здесь быдлостность кода?)))
Вот Bgg верно заметил :)

[i.o.]

быдлокод - это когда выпоняются лишние телодвижения по отношению к коду. С e4x такого нет. Там четко указано, что он должен сделать, пусть и не очень читаемо.
Посетите *****код.ру - поймете, что такое быдлокодерство.

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

function midVal(X, Y)
{
return (Math.max(X, Y) - Math.min(X, Y)) / 2 + Math.min(X, Y);
}

Вообще-то среднее арифметическое. Что достаточно было бы записать как 0.5*(X + Y).

[orcpochta]

Вот Bgg верно заметил :)

мне кажется это просто хеллоуворлдство, а не быдлокодерство - код-то доступен в своем осмыслении по самое не могу)))

[ir73]

function sample (flag:Boolean) {
if (flag.toString() == "true") {
///
}
}

[iNils]

мне кажется это просто хеллоуворлдство, а не быдлокодерство - код-то доступен в своем осмыслении по самое не могу)))Стоит почитать определение данное i.o., вполне разумно.
Если учитывать, что if работает с логическим результатом в условии, то проверять true на равенство true, это быдлокодерство.

[orcpochta]

Стоит почитать определение данное i.o., вполне разумно.
Если учитывать, что if работает с логическим результатом в условии, то проверять true на равенство true, это быдлокодерство.

согласен)))))))

[wvxvw]

Не нужно делать проверки, XML динамический класс, нужно только удостовериться, что обращаемся именно к XML а не куда-то в другое место:
xml.*.(valueOf().@someAttribute == "foo");
никогда не выкинет исключения.

[iNils]

никогда не выкинет исключения.Ты точно уверен?:D Я просто проверял код и если атрибут не найден, то исключения были.

[orcpochta]

Исключения он не выкинет, но тогда создается потенциальная опасность получить нулевое значение там, где его нет - и все равно придется делать проверки:

var xml:XML = <LOCATIONS>
<LOCATION ID = "1" STATUS = "OPEN" />
<LOCATION ID = "2" STATUS = "CLOSE" />
<LOCATION STATUS = "OPEN" />
<LOCATION ID = "4" STATUS = "CLOSE" />
<LOCATION ID = "5" STATUS = "OPEN" />
</LOCATIONS>;

var openLocationsID:Vector.<uint> = new Vector.<uint>();

xml.*.(@STATUS == "OPEN" && openLocationsID.push(valueOf().@ID));

trace(openLocationsID);

//Output: 1,0,5

Добавлено через 1 минуту
Ты точно уверен?:D Я просто проверял код и если атрибут не найден, то исключения были.

С valueOf() не выкинет))

[iNils]

Берем мой код выше, и удаляем проверку на ID
var xml:XML = <LOCATIONS>
<LOCATION ID = "1" STATUS = "OPEN" />
<LOCATION ID = "2" STATUS = "CLOSE" />
<LOCATION STATUS = "OPEN" />
<LOCATION ID = "4" STATUS = "CLOSE" />
<LOCATION ID = "5" STATUS = "OPEN" />
<LOCATION ID = "6" />
</LOCATIONS>;

var openLocationsID:Vector.<uint> = new Vector.<uint>();
xml.*.(hasOwnProperty ('@STATUS') && @STATUS == "OPEN" && openLocationsID.push(@ID));
Запускаем получаем
ReferenceError: Error #1065: Переменная @ID не определена.
at TestXML/init()[D:\_Library\_Work\home.test\_QuickProject\src\TestXML.as:49]
at TestXML()[D:\_Library\_Work\home.test\_QuickProject\src\TestXML.as:29]

[i.o.]

function sample (flag:Boolean) {
if (flag.toString() == "true") {
///
}
}


if (flag.toString().toUpperCase() == ("True").toUpperCase()){
///
}


Вот теперь тру-быдлокод :)

[iNils]

Вот теперь тру-быдлокод Я так понимаю, надо открыть курсы "Хочешь быдлокодером? Мы научим!":D

[i.o.]

ну если найдутся желающие, то почему бы и нет?))

[TanaTiX]

Если учитывать, что if работает с логическим результатом в условии, то проверять true на равенство true, это быдлокодерство.
А как быть в отношении null и underfined?

[orcpochta]

Boolean не может быть null или undefined, а кто может, тот преобразуется в false.

[Psycho Tiger]

f.g.programmer, вот и фильтр прекрасно справился со своей задачей )
Хотите увидеть настоящий быдлокод?
function sample (flag:Boolean) {
if (flag == true) {
///
}
}
Вот кстати говорил это одногрупнику недавно, смотря в его код. Меня послали :D

[TanaTiX]

Boolean не может быть null или undefined

Я не про Boolean говорил

[wvxvw]

Ты точно уверен?:D Я просто проверял код и если атрибут не найден, то исключения были.

точно уверен :)

А как быть в отношении null и underfined?

Это странность ECMAScript, вообще два разных "ничего" быть не должно, таким образом, очевидно, пытались решить проблемы свойственные динамическим языкам, но так как динамическая часть в реализации AS3 никакая, то лучше считать, что undefined не существует, или считать null и undefined тождественными. Сразу меньше головной боли :)

[iNils]

точно уверенсм. еще раз (http://www.flasher.ru/forum/showpost.php?p=951198&postcount=26)

[orcpochta]

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

[wvxvw]

Потому что XML динамический, ошибки при обращении к несуществующему свойству быть не может, но просмотр цепочки областей видимости внутри фильтра работает несколько иначе чем вне его: сначала будут просмотрены свойсва XMLя, если вернется undefined, то дальше он будет смотреть аргументы функции, потом локальные переменные, потом поля класса и глобальные переменные. Т.как valueOf() вернет ссылку на самого себя, то мы избежим просмотра всей цепочки (операция уже как бы будет вне фильтра), и если свойства нет, то будет просто undefined.

[TanaTiX]

Это странность ECMAScript...
Спасибо. А я надеялся, что я чего-то не догоняю... Жаль :(

[orcpochta]

Ыыыы...))))))

room = roomByID[roomIDByUserID[userID]];

[Dukobpa3]

Ыыыы...))))))

room = roomByID[roomIDByUserID[userID]];

Ну это не самое страшное:)

Вотъ:

private var Category:Vector.<Object> = new Vector.<Object>(19, true);
//**********************************
Category[i].table = new Vector.<Vector.<Object>>();
//**********************************
Category[num].table[r] = new Vector.<Object>(5, true);
//**********************************
Category[num].table[r][0] = new TextField();

:cool:

[Хомяк]

я не покажу вам свои ранние работы :D

[orcpochta]

Как бы вы проверили наличие/отсутствие элемента в массиве или векторе и почему?


if (vect.indexOf(element) != -1) { ... }; //наличие
if (vect.indexOf(element) == -1) { ... }; //отсутствие

if (vect.indexOf(element) is uint) { ... }; //наличие
if (!(vect.indexOf(element) is uint)) { ... }; //отсутствие

if (vect.indexOf(element) >= 0) { ... }; //наличие
if (vect.indexOf(element) < 0) { ... }; //отсутствие


Есть ли принципиальная разница в производительности этих операций (на больших объемах элементов в векторе естественно)? Если есть, то кто кого и где об этом почитать?

[wvxvw]

Я сравниваю с -1, мне кажется, что так нагляднее, но это чисто субъективно.

[incvizitor]

if (vect.indexOf(element) != -1) { ... }; //наличие


По ходу просто первый бит посмотрит, увидит что там 0 и сразу же вернёт false. В Z80 было так, но с тех пор технологии могли измениться :)
А вот в случае когда надо вернуть true - вопрос спорный :)

[i.o.]

if (vect.indexOf(element) >= 0) { ... }; //наличие
if (vect.indexOf(element) < 0) { ... }; //отсутствие

[iNils]

Я вообще избегаю использовать >=, <= и !=, еще со времен as 1/2 :)

[orcpochta]

Я вообще избегаю использовать >=, <= и !=, еще со времен as 1/2 :)

Почему?

Как тогда вы бы получили наличие/отсутствие? is uint/ == -1 ?

[Psycho Tiger]

По ходу просто первый бит посмотрит, увидит что там 0 и сразу же вернёт false.
А если вернёт число 2? 00000010 - а вернёт true.

@iNils,
Я вообще избегаю использовать >=, <= и !=, еще со времен as 1/2
почему?

[orcpochta]

А если вернёт число 2? 00000010 - а вернёт true.

первый - в смысле знаковый имелось в виду (вероятно)

[iNils]

AS 1/2 на много был медленнее, чем AS3. А данные сравнения использовали две команды вместо одной, как <, > или ==. Поэтому часто, в процессе оптимизации быстродействия в циклах, делались замены. Сейчас это конечно смешно, но привычка осталась.

[incvizitor]

первый - в смысле знаковый имелось в виду (вероятно)

Именно)

Добавлено через 54 секунды
2 iNils:
а "!=" чем обидело?

[iNils]

2 iNils:
а "!=" чем обидело?
Да никто меня не обижал, просто я старался не использовать условия, где было две инструкции в AS2
! not
== equals
> greaterThan
< lessThan
=> lessThan + not
<= greaterThan + not
!= equals + not

То есть
if (a == 0) {
} else {
}
оптимальнее, чем
if (a != 0) {
} else {
}
Однако, если else отсутствует, то конечно использовал !=

В ас3 все гораздо лучше. Я когда смотрел описание avm2, то видел
! not
== equals
> greaterthan
< lessthan
=> greaterequals
<= lessequals
!= equals + not

Там еще целая серия инструкций из серии if***, я уже давно в этом не копался, но так подозреваю, что именно они отвечают за условия в if. Но могу и ошибаться. Лучше у BloodHound'а спросить, он точно должен знать.

[Psycho Tiger]

О как интересно. То есть гипотетически != работает медленнее, чем ==. В Си как раз наоборот, что примечательно.

[iNils]

Медленнее - сильно сказано. Сейчас такая скорость выполнения, что разницы нет.
Я же говорю, у меня это сила привычки :)

[incvizitor]

iNils, ну тут как бы дело принципа - работает прилага на 0.0001 мс быстрее, кому какая разница? А вот мне приятно, не потому что мне это принесёт бОльшие деньги, славу или еще что то. Просто это круто и всё)

[i.o.]

если я вам скажу, что:

var i:int = -1;
var l:int = arr.length;
while( ++i < l )
{...}

так циклы крутятся быстрее, чем:

for( var i:int=0, l:int=arr.length; i<l; i++ )
{...}

То вы будете юзать первое или второе? ;)

[orcpochta]

я пользую:


for (var i:uint = list.length; i--; ) { ... }

[iNils]

так циклы крутятся быстрее, чем:

for( var i:int=0, var l:int=arr.length; i<l; i++ )
{...}
Такое вообще не будет работать :D

Добавлено через 9 минут
Кстати, только что проверил на 10'000'000 цикле, где просто был j++. Для for результаты были 67-70, а для while 70-74.

[i.o.]

да, опечатался, лишнюю var написал, все уже поправил :)
результаты в дебаг плеере не в пользу while. Я как то тесты проводил: в release плеере while все же впереди оказывался, у меня по крайней мере :)

[iNils]

в release плеереЧто это?:D

[i.o.]

в смысле "Что это?"? Шутишь? )

[iNils]

Конечно :D

[i.o.]

весельчак :)

[BlooDHounD]

плэйер не причём. важна сама флэшка.

[incvizitor]

i.o., даже если и не буду то что? Знание ценно даже если оно не применяеться, так как помогает более ясно смотреть на вещи.

[orcpochta]

А вот как кто поступает в таких случаях?

Вариант 1:

function someFunction():Object
{
if (...)
{
if (...)
{
if (...) return obj;
}
}

return null;
}


Вариант 2:

function someFunction():Object
{
if (...)
{
if (...)
{
if (...) return obj;
else return null;
}
else return null;
}
else return null;
}


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

[iNils]

Вариант 3:
function someFunction():Object {
if (... && ... && ...) {
return obj;
}
return null;
}
Как только одно из условий равно false, сразу же происходит выход из if.

[orcpochta]

Вариант 3:
function someFunction():Object {
if (... && ... && ...) {
return obj;
}
return null;
}
Как только одно из условий равно false, сразу же происходит выход из if.

Ждал такого ответа от неуемного психоТигра, но никак не от вас))))

А что если одно из последующих условий емкая операция, результат которой потом где-то там же и используется помимо проверки? В этом случае она сначала вычисляется в одном из if-ов, а затем на основе результата делается проверка и дальнейшие операции))))

[i.o.]

orcpochta, "а что, если" нужно задавать в таких случаях перед вопросом, чтобы люди знали, на что отвечают.
Поставили везде многоточие — чего сейчас удивляетесь? )

[iNils]

orcpochta, а что если вместо ... было бы жестко забито false? Тогда и if писать не надо.
Я выше писал, что код пишется исходя из задачи.

[orcpochta]

Мне показалось, что только у одного человека может возникнуть такое предположение, что стоит объяснять как из n вложенных if-ов сделать один - ну согласитесь же, что такой вопрос бы даже школьник не задал - если он, конечно, не только вчера начал учиться программировать)))

[iNils]

orcpochta, задачу надо раскрывать. Я сижу и вижу, что в текущей задаче, ни один из способов не оптимален. И я не должен ломать голову почему вы третий вариант не предложили)

[orcpochta]

Ну, с условием, вроде, разобрались - так какой будет вердикт? Красивый код Vs. мгновенный выход в "точке ясности"?)))

[iNils]

orcpochta, ваше предположение оказалось не верным.
Первый вариант приятней читать - нет грязи, в нем нет дублирующегося кода - все вроде четко, ясно и аккуратно, но (!) второй вариант по идее должен работать быстрее, т.к. возврат из ф-ии происходит в "точке ясности" (назову это так) - т.е. если в первом варианте мы дошли до вложенного if-a и не вернули в итоге obj, то нам придется проделать весь путь обратно по стеку вложенности до единственного return null, а во втором варианте выброс происходит сразу без обратного пути
Есть первый код
var a:Boolean = true;
var b:Boolean = true;
var c:Boolean = true;
var o:Object = {};
function test ():Object {
if (a) {
if (b) {
if (c) {
return o;
}
}
}
return null;
}
его байт код такой
public function test():Object {
_as3_getlocal <0>
_as3_pushscope
_as3_getlex a
_as3_iffalse offset: 15[#11]
_as3_getlex b
_as3_iffalse offset: 9[#11]
_as3_getlex c
_as3_iffalse offset: 3[#11]
_as3_getlex o
_as3_returnvalue
#11 _as3_pushnull
_as3_returnvalue
}

Есть второй код
var a:Boolean = true;
var b:Boolean = true;
var c:Boolean = true;
var o:Object = {};
function test ():Object {
if (a) {
if (b) {
if (c) {
return o;
} else {
return null;
}
} else {
return null;
}
} else {
return null;
}
}
байт код такой
public function test():Object {
_as3_getlocal <0>
_as3_pushscope
_as3_getlex a
_as3_iffalse offset: 27[#17]
_as3_getlex b
_as3_iffalse offset: 15[#14]
_as3_getlex c
_as3_iffalse offset: 3[#11]
_as3_getlex o
_as3_returnvalue
#11 _as3_pushnull
_as3_returnvalue
_as3_jump offset: 2[#16]
#14 _as3_pushnull
_as3_returnvalue
#16 _as3_jump offset: 2[#1]
#17 _as3_pushnull
_as3_returnvalue
}
Как видим, первый код короче, а делает тоже самое.

[orcpochta]

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

Но! Если я буду писать это в конструкторе, то буду прав - там ведь интерпретация?

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

[iNils]

Если я буду писать это в конструктореА что, у нас можно вернуть в конструкторе ?)

[orcpochta]

А что, у нас можно вернуть в конструкторе ?)

блин... :yahoo:

[i.o.]

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

[orcpochta]

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

такова тяжелая доля флеш-плеера)))

[Dukobpa3]

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

var a:Object;
var b:Object;
var c:Object;
var d:Object;
if(a = <Some Operations> && b = <Some Operations> && c = <Some Operations>) {
return d = <Some Operations>
}
else return null;

Переменные а, б, ц - сохранят ваши промежуточные ваычисления ;) (да, там не "==", а "=")

[i.o.]

ничто не мешает модифицировать вот так, кстати:

if( (a = <Some Operations>) <= <To Compare>
&& (b = <Some Operations>) == <To Compare>
&& (c = <Some Operations>) >= <To Compare> )
{
return d = <Some Operations>
}

[orcpochta]

public function dispose():void
{
_elements.length = 0; //вектор или массив
_elements = null;
}


Быдлокод?

Ничего не могу с собой поделать - пытаюсь везде создать метод dispose(), даже там, где он особо не нужен.

[etc]

splice(0);

[orcpochta]

splice(0);

Вопрос-то не в том, как очистить массив, а в том, надо ли это делать в методе dispose() перед удалением объекта, этот массив содержащего?

Кстати, чем arr.length = 0 плох по сравнению со arr.splice(0)?

[etc]

Вопрос-то не в том, как очистить массив, а в том, надо ли это делать в методе dispose() перед удалением объекта, этот массив содержащего?

Кстати, чем arr.length = 0 плох по сравнению со arr.splice(0)?

dispose необязательно.
А splice по мне так надёжнее.

[Psycho Tiger]

А чем плохо создание нового массива и присвоение ссылки на него старому? (myArr=[])

[orcpochta]

А чем плохо создание нового массива и присвоение ссылки на него старому? (myArr=[])

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