s0rr0w

Но что происходит в случае, когда "не было var"? Есть ли в спецификации описание такого синтаксиса? А может быть это bug или extension ES3 синтаксиса? Попадет ли подобное в разряд семантических ошибок в будущих реализациях ES:

В спецификации есть описание присвоения.

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

Так как парсер обязан вернуть ссылку на объект, который он не нашел в списке переменных данной области видимости (scope chain), то он, по идее, должен все равно его создать, присвоить имя идентификатора и указать тип Undefined.

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

alert( x );

если x никогда до этого не был указан.

Вы действительно хорошо знакомы с "текущим контекстом", чтобы возражать WingedFox'у?

...

Недосмотрел, каюсь

В разделе 10.1.1 есть определение типов Function objects, в нем нет описания алгоритма создания и идентификации такой функции:

zebra = function () {};. Вы или слепы, или глупы.

Я нашел время, заглянул в спеку, и сейчас расскажу вам, как происходит создание функции zebra = function () {};

1. Для интерпретатора эта строка - выражение. Если бы было var, то это быда бы декларация переменной.

2. Выражение является простым присваиванием Simple Assignment ( = )

3. Вычисляется LeftHandSideExpression. Это PrimaryExpression. Результатом будет ссылка на объект null, чье свойство name будет равно идентификатору.

4. Вычисляется AssignmentExpression, что будет в нашем случае FunctionExpression. Интерпретатор создаст экземпляр класса Function.

5. Вызовется GetValue от 4-го пункта

6. Присвоится значение 3му пункту результат выполнения пятого

7. Будет возвращен результат выполнения выражения.

Да, выполнение выражения будет после создания функций через FunctionDeclaration.

Я ответил на этот вопрос?

AKS, ответьте мне на один вопрос

Чем отличается FunctionDeclaration от FunctionExpression?

Покажите ваши познания ECMAScript'а

Разница есть, если воспользоваться этой функцией в том же файле, где она определяется. В варианте Влада вывов е? до фактического определения невозможен, т.к. происходит создание в момент выполнения оператора присваивания.

Теоретизировать конечно хорошо, но в контексте данной задачи, особой разницы нет.

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

Она хороша тем, что

а) сразу готова к использованию и не требует доп. вычислений в отличие от getElementsByTagName

б) туда не попадут строки из вложенных таблиц, буде такие появятся

Вот, это уже больше похоже на адекватную аргументацию.

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

Касательно варианта "б" скажу так, если возникает задача сделать действительно универсальный скрипт раскраски, то rows может совсем не помочь

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

И вот при такой постановке задачи rows, даже при всех плюсах, минусом может оказаться сложность кода для восприятия, который будет все это обрабатывать.

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

В разделе 10.1.1 есть определение типов Function objects, в нем нет описания алгоритма создания и идентификации такой функции:

zebra = function () {};. Вы или слепы, или глупы.

Смелое заявление! Но весьма опрометчивое.

Итак, читаем, что же написано в пункте 10.1.1 на странице 37 документа http://www.ecma-international.org/publicat...ST/Ecma-262.pdf

Program functions are defined in source text by a FunctionDeclaration or created dynamically either

by using a FunctionExpression or by using the built-in Function object as a constructor.

Теперь идем на страницу 44 и изучаем Left-Hand-Side Expressions 11.2.5 Function Expressions

Потом идем на страницу 71 и читаем, чем отличается FunctionExpression от FunctionDeclaration.

Желательно вам пояснить мне, чем же эти два варианта отличаются, так как знающим спецификации у нас являетесь вы.

Ссылки???

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

Что такое chain scope??? В ECMAScript Language Specification нет ни одного упоминания о таком определении. Вы совершенно не понимаете то, о чем пишите!

Ах, прошу прощения, ошибся в порядке следования слов, нужно scope chain. 10.1.4 пункт той же спецификации.

По русски это звучит как "область видимости".

Я так понял, что мой вопрос успешно проигнорирован был.

Чем кардинально отличается HTMLCollection интерфейс от NodeList интерфейса? Вы "смотрите в книгу, а видите фигу"! Речь шла о разнице между rows property и методом getElementsByTagName!

Похоже вы все же невнимательно читаете спецификации. Результатом работы метода getElementsByTagName является NodeList.

Итак, читаем, что же есть NodeList Interface

The NodeList interface provides the abstraction of an ordered collection of nodes, without defining or constraining how this collection is implemented. NodeList objects in the DOM are live.

Теперь читаем, что же есть HTMLCollection

An HTMLCollection is a list of nodes. An individual node may be accessed by either ordinal index or the node's name or id attributes.

Note: Collections in the HTML DOM are assumed to be live meaning that they are automatically updated when the underlying document is changed.

Так вот, rows представляет собой HTMLCollection. Не кажутся ли странными первые два предложения у обоих описаниях. Коллекцию называют списком нод, а список - коллекцией нод?

Описание значения rows

rows of type HTMLCollection, readonly

Returns a collection of all the rows in the table, including all in THEAD, TFOOT, all TBODY elements.

Я не собираюсь Вам ничего объяснять

А вам бы стоило постараться. Ничто не красит человека так, как адекватная аргументация в споре.

1. Алгоритм создания и идентификации именованной функции описан в ECMAScript Language Specification. Не пытаясь описать своими словами вариант, который Вы считаете идентичным, просто укажите раздел спецификации, описывающий этот "нормальный" вариант.

2. Известно ли Вам мнение разработчиков JavaScript 2.0 насчет подобного синтаксиса, и будет ли подобный код поддерживаться на платформах будущего?

1. Читаем раздел 10.1.1

2. Ссылки на список разработчиков и на мнение данных разработчиков.

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

Окей, вопрос профессиональному разработчику, в какую chain scope попадут нижеследущие переменные

<script type="text/javascript">
var x = 1;
y = 1;
</script>

Любому программисту, работающему с DOM API, хорошо известна разница между rows property и методом getElementsByTagName. Утверждение, что разницы между ними не существует, - это первый признак отсутствия компетентности.

Чем кардинально отличается HTMLCollection интерфейс от NodeList интерфейса? Почему нужно брать именно HTMLCollection интерфейс для поиска нод внутри таблицы?

Может для начала стоит все же почитать спецификацию?

1.Тогда функция будет доступна с момента парсинга скрипта, а не исполнения этой строчки.

Нет особой разницы. Оба варианта нормальные.

2. Какая-то беда произошла, что var вымер?

+1 за исключением определения функции, там он не обязателен.

3. Имеет смысл бегать по .rows.

Нет особого смысла. Коллекция тоже вполне работоспособна, пока не выполнится скрипт, коллекция будет считаться статичной.

Написал небольшой скрипт, который в любой таблице поочередно меняет цвет строки: светлая, темная, светлая, темная...

Посмотрите на предмет правильности описания и возможных ошибок.

Самое первое же, что бросается в глаза, это непосредственное присваивание и сравнение имени класса.

Что будет, если таблица будет иметь два класса? А что будет, если какая-то из строк таблицы будет тоже иметь предустановленный стиль?

Еще один момент. Некоторые строки могут иметь display: none, что в итоге будет давать ошибку черезполосицы.

Как только выполнится код, идущий сразу после кода вставки - код выполнился.

Еще как видит. http://www.w3.org/TR/2000/REC-DOM-Level-2-...001113/css.html

Флэш, насколько я понял, что скрипт именно на нем построен, не умеет сохранять файлы на диск, зато хорошо умеет определять процесс закачки. Логично.

Все равно нужна серверная часть.

Только при помощи JS - нельзя. Видел реализацию на perl + JS.

Ссылка на статью - www.google.com

, т.е. процедуры создания глобальной переменной и св-ва window - это не одно и то же.

И что? В одном браузере он один, в другом - другой, а результат у всех один и тот же - переменные попадут в global scope chain. Меня меньше всего волнуют внутренние механизмы, которые происходят в недрах браузеров, хотя недавно я не без удовольствия покопался в исходниках seamonkey. Главное - результат.

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

Любая книжка по JS носит отпечаток знаний и умений автора. Вместе с этим туда же попадают непонятные и необоснованные табу. В любом языке программирования считаются глобальные переменные плохим тоном. А в JS помимо воли программиста все объекты, которые были инициализированы в теле тега script автоматом получают парентом объект window. Вопрос, насколько актуально данное табу в рамках специфики модели JS?

Что тогда? А что, если этот "любой другой скрипт может полностью удалить" (или заменить) options у этой самой ноды? Вот тогда что станет с "правильным" скриптом?

Указанный пример немного синтетический. А мой пример - вполне реальный.Я понимаю желание доказать мою некомпетентность, но не стоит это делать столь откровенным образом. Я же предупреждал, что не реагирую на неадекватщину.

"bad practice", кстати, не "bad theory", что было бы неприятно глазу практика... и даже упомянуто в в официальных доках.

Охохо. Очень может быть, что всякие "табу" в виде "bad practice" появляются в следстствие чего-либо. Нужно четко знать причину, по которой это появляется. Для меня например удивительно, какого лешего писать про то, что глобальные переменные в JS - плохо, если все что написано не внутри функции будет все равно глобальной переменной, вне зависимости от наличия var. Значит дело касается больше внутренностей фукнций, в которых можно определять глобальную переменную. Это ближе к правде. Потом вдобавок помог баг IE. Но он является багом, а не стандартным поведением. Мало того, что в IE наблюдается та же картина, что и в FF, любые переменные в теле script попадают в global scope chain. Итак, видим, что bad practice rule подкреплено багом IE, вероятность возникновения которого при нормальный условиях программирования ничножно мала. Разобравшись с данным табу можно смело сделать выводы, что не все, про что так громко кричат, опасно на самом деле. Если запугивать программеров всякими ограничениями - они перестают нормально мыслить. Нужно пояснять, что такой баг есть, как с ним бороться, и все.

Это необязательно в общем смысле, javascript создавался и для непрофессиональной (не за бабло) разработки, для энтузиастов, WEB-гиков и прочей нечисти, у них нет тормозов и ограничительной документации. Имейте их в уме, предлагая свои решения на публичном форуме, куда ходят абсолютно все, включая слепоглухонемых копипастеров.

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

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

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

Облекая слова в код - проще вести конструктивную беседу.

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

На мой взгляд, вы просто не видите этого решения.

А вы не спрашивали себя, а хочу ли я видеть данное решение? Ваше предложение для данного скрипта может и будет проще. Но в целом - неприемлемо. Все очень просто. Любой ноде любой другой скрипт может полностью удалить onclick event у ноды, заменив его на event listener. Что тогда? Поймите, если всегда думать рамками только данной задачи и только в рамках данной реализации, то мы так и не дождемся качественных программеров на рынке.

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

О, вы телепат? Не надо думать за меня. Вы думаете я ошибся в данном куске кода? Нет, я вам тогда сразу и написал, что нода, которую могут переносить и таргет эвента могут быть разными. Потому что у меня уже были преценденты с моим кодом, когда идет усложнение HTML, а JS код как раз не работает именно по этой причине - нода с данными может сильно отличаться от ноды, с которым ведется работа. У меня в библиотеке даже специальная функция есть - getParentNodeWithProperty. Чтобы не мусорить, я просто перенес часть функционала непосредственно в код.

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

Мдааа.. Знаете в чем наше отличие? Вы слишком много уделяете мелочам внимание. Мелочам, которые при правильном подходе к разработке интерфейсных решений никогда не проявятся. Поясню почему.

1. Что с var, что без var, функции попадают в global scope chain.

2. Туда же попадают идентификаторы нод в IE.

3. Ни один нормальный, адекватный, в здравом рассудке кодер не будет называть идентификатор ноды именем getElementByClassName, matchClassName и т.д. и т.п. Мало того, при нормальном подходе к разработке именование идентификаторов, имен функций и прочего должно строиться по разным правилам. Это обязательное требование к разработке.

Скажите, баг IE проявится при таком подходе? Никогда!

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

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

Опять же, вернемся к нашим синтетическим эвэнтам.

Если баг 282266 и представляет потенциальный вариант возникновения ошибки, то два других бага можно пока что вообще не рассматривать багами, так как до сих пор не принята спецификация DOM Level 3, которая, собственно и описывает правильность обработки key-events. Будем равняться на драфт? Да, и применения input type=submit в качестве переключалки таба считаю полным извращением.

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

это не только "bad practice", о которой говорится во всех мыслимых и немыслимых javascript-доках,

По-моему вы перечитали мыслимых и немыслимых док.

Общался с девелоперами Mozilla. Они не понимают, почему lambda functions являются bad practice. В упор не понимают. Смотрели на меня как на идиота. Слова разных людей - это написано в доке, значит это применимо. Да, в определенных условиях может получиться и bad practice, но их же слова: "lambda function are beautiful".

Подумайте головой, как bad practice может быть то, что описано в доках?

но и путь, который при стечении определ?нных обстоятельств может привести к трудноуловимой ошибке, пример:

Ах вот оно что. Много разных слов вокруг простого бага IE, который при нормальной разработке никогда не осуществим. Этому багу уже лет 10 наверное.

Не надо видеть, надо просто знать! За столько лет практической работы вам бы стоило давно уяснить, что "synthetic events" по определению бажные, и если нет в них острой необходимости, то шли бы они лесом. Это аксиома.

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

За три года использования диспатчей не было ни одного бага в багтрекинге, связанного с его работоспособностью. Это сотни инсталляций продукта. Ах да, для вас это табу, я забыл.

Мне вот интересно, никаких книжек вы не читали, а уже утверждаете, что

- блоки try-catch при тотальном отсутствии проверок и контроля за скриптом - признак непрофессионализма;

Получается, что это ваше личное мнение. С удовольствием его проигнорирую как и многие остальные.

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

Ну почему же не мне судить? Очень могу даже вполне судить. Ситуация как раз вполне рабочая, дали задание, его надо решить. Решить эффективно и в полном объеме. Ход мыслей вполне себе понятный, как бы вы решали, на основании каких методов.

p.s. что конкретно вам нужно пояснить ЕЩ??

Похоже у вас тоже проблема с внимательностью.

- "неявное заведение переменных" - прямая дорога к багам IE (и частично к багам Opera);

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

- инлайн обработчики элементарно вызываются без бажных и непопулярных dispatchEvent и т.п.;

Опять красивые слова, но доказательства бажности диспатчЭвента я не увидел.

- блоки try-catch при тотальном отсутствии проверок и контроля за скриптом - признак непрофессионализма;

И в какой это книжке написано? Там не ваше авторство случайно?

От zeroglif'а я не дождался ни одного пояснения

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

Вы ответьте сначала на вопросы, которые я задавал. Желательно в виде примеров, чтобы доказать свои слова. Процитировать или сами из моих постов вопросы найдете?

И расскажите мне, где же я вру. С цитатами из моих постов.

А кто отрицает? Я уже несколько раз написал, что мой вариант - это НАКОЛЕНОЧНОЕ РЕШЕНИЕ.

А вы другие писать умеете? Почему сразу не написали? Потому что мы не из тех, кто пишет сразу нормально?

Код мной был написан с нуля. За исключением некоторых функций.

Стыдно должно было быть за то, что "раструбили" о том, что ваш скрипт 100%-ый во всех отношениях, а оказалось все далеко не так. Оказалось, что полно детских ошибок.

Ай-я-яй как нехорошо. Когда читаете посты, внимательно их читайте. Я написал не про то, что мой скрипт 100%-ый во всех отношениях, а то, что задание выполнено на 100%. Т.е. я выполнил оба условия, которые ставились в задаче. А вы, многоуважаемый "профессионал", даже не потрудились внимательно прочитать задание. А теперь доказываете мне то, чего я не говорил. Внимательнее надо быть.

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

Еще раз повторю, профессионал это не тот, кто умеет писать без ошибок (кстати, а что есть ошибка?), а тот, кто умеет задачу решить наилучшим образом и на все 100%, а не только часть.

И правильно, что стыдно!

Хотя я не знаю, как там у Вас с совестью...

Стыдно? Отнюдь! Мне не стыдно чего-то не знать. Или чего-то не уметь. И за свои ошибки не стыдно.

Если я скажу, что это Copy/Paste, вам станет от этого лучше? Я думаю, что это будет еще один виток флейма, направленного на то, чтобы доказать мне, что я не знаю JS.

Данный спор с вашей с Zeroglif'ом стороны идет на уровне мелочей. Вы не видите целого, вы смотрите в первую очередь на мелочи. Я же смотрю на общие вещи, которые куда более полезные, чем присутствие того же ключа i в регекспе. Исправить одну букву в коде просто. А вот исправить костность мышления - не очень.

От zeroglif'а я не дождался ни одного пояснения, ни одной строчки кода. Соответственно и отношение к его словам соответствующее - теоретик.

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

Так что, если вы вернетесь к началу разговора, то поймете о чем именно я сказал в своем посте под номером 8.

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

Остальное все- мертвый груз.

Это не дотошность. Для меня построчное чтение кода - это единственная возможность определить уровень профессионализма писавшего.

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

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

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

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

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

С какой целью регвыр модифицирован таким образом, чтобы поиск совпадения был регистронезависимым?

Вашу бы дотошность да в другое бы русло. Это серьезно влияет на работоспособность скрипта?

Вы бы лучше подумали над тем, как улучшить масштабируемость вашего скрипта.