s0rr0w

И что должен вернуть код alert( x = 1 );

В спецификации есть описание присвоения. Переменной присваивается результат какого-то выражения, либо другая переменная, либо результат выполнения функции и т.п. Так как парсер обязан вернуть ссылку на объект, который он не нашел в списке переменных данной области видимости (scope chain), то он, по идее, должен все равно его создать, присвоить имя идентификатора и указать тип Undefined. Вот есть вопрос на размышление, что должен вернуть код alert( x ); если x никогда до этого не был указан.

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

Я нашел время, заглянул в спеку, и сейчас расскажу вам, как происходит создание функции 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'а

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

Смелое заявление! Но весьма опрометчивое. Итак, читаем, что же написано в пункте 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 уже в текущем документе. Увы, но в документе я этого не обнаружил. Ах, прошу прощения, ошибся в порядке следования слов, нужно scope chain. 10.1.4 пункт той же спецификации. По русски это звучит как "область видимости". Я так понял, что мой вопрос успешно проигнорирован был. Похоже вы все же невнимательно читаете спецификации. Результатом работы метода 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. Читаем раздел 10.1.1 2. Ссылки на список разработчиков и на мнение данных разработчиков. Окей, вопрос профессиональному разработчику, в какую chain scope попадут нижеследущие переменные <script type="text/javascript"> var x = 1; y = 1; </script> Чем кардинально отличается HTMLCollection интерфейс от NodeList интерфейса? Почему нужно брать именно HTMLCollection интерфейс для поиска нод внутри таблицы? Может для начала стоит все же почитать спецификацию?

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

Самое первое же, что бросается в глаза, это непосредственное присваивание и сравнение имени класса. Что будет, если таблица будет иметь два класса? А что будет, если какая-то из строк таблицы будет тоже иметь предустановленный стиль? Еще один момент. Некоторые строки могут иметь display: none, что в итоге будет давать ошибку черезполосицы.

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

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

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

Только при помощи JS - нельзя. Видел реализацию на perl + JS. Ссылка на статью - www.google.com

И что? В одном браузере он один, в другом - другой, а результат у всех один и тот же - переменные попадут в global scope chain. Меня меньше всего волнуют внутренние механизмы, которые происходят в недрах браузеров, хотя недавно я не без удовольствия покопался в исходниках seamonkey. Главное - результат. Любая книжка по JS носит отпечаток знаний и умений автора. Вместе с этим туда же попадают непонятные и необоснованные табу. В любом языке программирования считаются глобальные переменные плохим тоном. А в JS помимо воли программиста все объекты, которые были инициализированы в теле тега script автоматом получают парентом объект window. Вопрос, насколько актуально данное табу в рамках специфики модели JS? Указанный пример немного синтетический. А мой пример - вполне реальный.Я понимаю желание доказать мою некомпетентность, но не стоит это делать столь откровенным образом. Я же предупреждал, что не реагирую на неадекватщину.

Охохо. Очень может быть, что всякие "табу" в виде "bad practice" появляются в следстствие чего-либо. Нужно четко знать причину, по которой это появляется. Для меня например удивительно, какого лешего писать про то, что глобальные переменные в JS - плохо, если все что написано не внутри функции будет все равно глобальной переменной, вне зависимости от наличия var. Значит дело касается больше внутренностей фукнций, в которых можно определять глобальную переменную. Это ближе к правде. Потом вдобавок помог баг IE. Но он является багом, а не стандартным поведением. Мало того, что в IE наблюдается та же картина, что и в FF, любые переменные в теле script попадают в global scope chain. Итак, видим, что bad practice rule подкреплено багом IE, вероятность возникновения которого при нормальный условиях программирования ничножно мала. Разобравшись с данным табу можно смело сделать выводы, что не все, про что так громко кричат, опасно на самом деле. Если запугивать программеров всякими ограничениями - они перестают нормально мыслить. Нужно пояснять, что такой баг есть, как с ним бороться, и все. Чем больше людей набьют свои собственные шишки, тем больше будет качественного кода. Проще научить человека пониманию ошибки реализации того или иного браузера, проще научить, что надо делать, чтобы ошибки не возникало, чем запрещать ему думать даже в эту сторону, так как кто-то там сказал, что это нельзя, что это непрофессионально. Вы боитесь негативного отношения к себе? Зря, любые обсуждения на форумах рождают многогранное отношение к происходящему. Я прошу супер-пупер код, чтобы понять ход мыслей человека. Или подтверждение своих же слов. Мало того, на реальных примерах куда проще узнавать что-то новое для себя. Облекая слова в код - проще вести конструктивную беседу. По поводу библиотек - я всегда к ним отношусь со скептицизмом. К авторам библиотек отношусь с уважением. Народ что-то сделал, это уже достойно почитания. А вы не спрашивали себя, а хочу ли я видеть данное решение? Ваше предложение для данного скрипта может и будет проще. Но в целом - неприемлемо. Все очень просто. Любой ноде любой другой скрипт может полностью удалить onclick event у ноды, заменив его на event listener. Что тогда? Поймите, если всегда думать рамками только данной задачи и только в рамках данной реализации, то мы так и не дождемся качественных программеров на рынке. О, вы телепат? Не надо думать за меня. Вы думаете я ошибся в данном куске кода? Нет, я вам тогда сразу и написал, что нода, которую могут переносить и таргет эвента могут быть разными. Потому что у меня уже были преценденты с моим кодом, когда идет усложнение HTML, а JS код как раз не работает именно по этой причине - нода с данными может сильно отличаться от ноды, с которым ведется работа. У меня в библиотеке даже специальная функция есть - getParentNodeWithProperty. Чтобы не мусорить, я просто перенес часть функционала непосредственно в код.

Мдааа.. Знаете в чем наше отличие? Вы слишком много уделяете мелочам внимание. Мелочам, которые при правильном подходе к разработке интерфейсных решений никогда не проявятся. Поясню почему. 1. Что с var, что без var, функции попадают в global scope chain. 2. Туда же попадают идентификаторы нод в IE. 3. Ни один нормальный, адекватный, в здравом рассудке кодер не будет называть идентификатор ноды именем getElementByClassName, matchClassName и т.д. и т.п. Мало того, при нормальном подходе к разработке именование идентификаторов, имен функций и прочего должно строиться по разным правилам. Это обязательное требование к разработке. Скажите, баг IE проявится при таком подходе? Никогда! Ах какие высокие слова. Чтобы бороться с безграмотностью недостаточно говорить с умным видом разные слова. Нужно аргументированно доказывать свою точку зрения, используя ссылки, примеры кода, указания на нормальные источники, а не бред псевдо-гуру, которые иногда делают совершенно неправильные выводы из очевидных вещей. Именно поэтому я всегда требовал от вас закрепления своих слов примерами. Но вы это успешно игнорировали в некоторых случаях. Опять же, вернемся к нашим синтетическим эвэнтам. Если баг 282266 и представляет потенциальный вариант возникновения ошибки, то два других бага можно пока что вообще не рассматривать багами, так как до сих пор не принята спецификация DOM Level 3, которая, собственно и описывает правильность обработки key-events. Будем равняться на драфт? Да, и применения input type=submit в качестве переключалки таба считаю полным извращением. А я вижу, что вы так и не поняли, почему парентов надо сканировать на наличие нужного свойства. Все больше и больше убеждаюсь, что мне совершенно неинтересна будет ваша реализация табулятора.

По-моему вы перечитали мыслимых и немыслимых док. Общался с девелоперами Mozilla. Они не понимают, почему lambda functions являются bad practice. В упор не понимают. Смотрели на меня как на идиота. Слова разных людей - это написано в доке, значит это применимо. Да, в определенных условиях может получиться и bad practice, но их же слова: "lambda function are beautiful". Подумайте головой, как bad practice может быть то, что описано в доках? Ах вот оно что. Много разных слов вокруг простого бага IE, который при нормальной разработке никогда не осуществим. Этому багу уже лет 10 наверное. Спасибо, посмеялся. Как и девелоперы Mozilla. Опять же, свелось все к простому - это есть в документации, этому посвящен ни один раздел, это можно использовать без ограничений. Ограничения только в вашей голове. И вы вбили себе это на уровне каких-то аксиом. За три года использования диспатчей не было ни одного бага в багтрекинге, связанного с его работоспособностью. Это сотни инсталляций продукта. Ах да, для вас это табу, я забыл. Мне вот интересно, никаких книжек вы не читали, а уже утверждаете, что - блоки try-catch при тотальном отсутствии проверок и контроля за скриптом - признак непрофессионализма; Получается, что это ваше личное мнение. С удовольствием его проигнорирую как и многие остальные.

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

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

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

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

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

Стыдно? Отнюдь! Мне не стыдно чего-то не знать. Или чего-то не уметь. И за свои ошибки не стыдно. Если я скажу, что это Copy/Paste, вам станет от этого лучше? Я думаю, что это будет еще один виток флейма, направленного на то, чтобы доказать мне, что я не знаю JS. Данный спор с вашей с Zeroglif'ом стороны идет на уровне мелочей. Вы не видите целого, вы смотрите в первую очередь на мелочи. Я же смотрю на общие вещи, которые куда более полезные, чем присутствие того же ключа i в регекспе. Исправить одну букву в коде просто. А вот исправить костность мышления - не очень. От zeroglif'а я не дождался ни одного пояснения, ни одной строчки кода. Соответственно и отношение к его словам соответствующее - теоретик. А качество вашей работы я увидел. Может и написано без ошибок, зато одна сплошная ошибка с практической точки зрения. Мало того, что вы не внимательно прочитали задание, но еще и реализовали его в лоб. Мои ошибки просто исправить ( но я это не буду делать по некоторым причинам ), ваши ошибки в алгоритмике вы не сможете исправить быстро, потому что вы привыкли так мыслить, такими категориями. Так что, если вы вернетесь к началу разговора, то поймете о чем именно я сказал в своем посте под номером 8. Спасибо я могу сказать, только за одну вещь - за изменения в требованиях к именам переменных. Остальное все- мертвый груз.

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