Комментарии 106
вот собственно вторая часть, жду материал для «работы над ошибками», я не мастер JS, но вместе думаю, у нас получится нормальный набор заметок. Еще хотел бы услышать предложения, опять же я не мастер писать статьи, хотелось бы услышать конструктивную критику
А где первая часть?
> ypeof( [] ) // 'object' — да, массив он назовет обьектом (как их различить будет дальше),
не нашёл…
не нашёл…
«дальше планируются… поподробней разберемся с объектами»
вообще у массива конструктор — Array
[].constructor === Array
вообще у массива конструктор — Array
[].constructor === Array
Array в каждом фрейме свой.
массив, созданный в одном фрейме не пройдёт эту проверку в другом.
массив, созданный в одном фрейме не пройдёт эту проверку в другом.
я не знал, посмотрю как избавиться от этого
да, Вы правы, где переменную взяли там и массив надо смотреть
habrahabr.ru/blogs/javascript/55799/#comment_1496675
с прикладной точки зрения, с .concat'ом тоже можно не заморачивать, хоть по спеке объекты могут иметь в качестве [[Class]] любое значение, я не знаю, какая из реализаций на это пойдёт; поэтому проверки с toString'ом Object.prototype'а должно хватить
этот способ тоже не работает при условии что переменная из другого фрейма, надо тоже проверять Array того фрейма где взяли переменную
Пара замечаний:
1. В массив можно записывать значения по строковому ключу, как и в объект по индексу.
2. Массив от объекта отличается наличием свойства length, причём элементы, записаные в массив по строковому ключу не считаются, отличить массив от объекта можно следующим образом
3. Стандартный for each перебирает только те элементы, которые были явно записаны в массив/объект
1. В массив можно записывать значения по строковому ключу, как и в объект по индексу.
2. Массив от объекта отличается наличием свойства length, причём элементы, записаные в массив по строковому ключу не считаются, отличить массив от объекта можно следующим образом
objOrArr.length === undefined //true для объекта
3. Стандартный for each перебирает только те элементы, которые были явно записаны в массив/объект
var arr = [];
var i = 0;
arr["somekey"] = "some data";
arr[34] = "some other data";
for each (value in arr) {
i++;
}
//здесь i == 2
А что у объекта не может быть свойства length?
var objOrArr = {length: 10};
Массив это и есть объект, так же как и функция.
var objOrArr = {length: 10};
Массив это и есть объект, так же как и функция.
> arr[«somekey»] = «some data»;
только стоит помнить, что ключи-не-индексы массива (числа, приведённые к строе) не воздействуют на .length
только стоит помнить, что ключи-не-индексы массива (числа, приведённые к строе) не воздействуют на .length
в массив неправильно писать значения с текстовым ключем, вообще можно все, но есть какие-то правила, вообще можно и из обьекта сделать массив, и из массива обьект, но смысл?
3… и унаследованные от прототипа
Вы написаил:
var obj = {}; // с помощью JSON
Если мне не изменяет память, такая конструкция называется object literal.
var obj = {}; // с помощью JSON
Если мне не изменяет память, такая конструкция называется object literal.
> удаление переменных:
>… или удалить с помощью оператора delete ( delete someVar; )
Развод и профанация. НЕЛЬЗЯ удалить переменную с помощью delete. Автор, учи матчасть!
>… или удалить с помощью оператора delete ( delete someVar; )
Развод и профанация. НЕЛЬЗЯ удалить переменную с помощью delete. Автор, учи матчасть!
Смотря, в каком контексте ;) О переменных.
Неформатированный поток сумбурных мыслей.
на самом деле это не так просто писать структурированно, понятно и информативно, возможно в дальнейшем и у меня будет получаться доходчиво объяснять то что хочу сказать
Для начала можете научиться начинать предложения с заглавной буквы и заканчивать точкой.
Вы знаете, у меня такое ощущение, что то, о чем вы думали, называется справочником по JS для начинающих. Мой начальник написал такой справочник, только «я не мастер JS» — эт не про него. Цель написания не очень понятна. Поставил себя на место нуба, которому надо быстро найти интересующее решение задачи — я считаю, у него ничего не получится. Вы хотите обсудить с хабрасообществом основы JS? Думаю, не лучшее занятие; )
Попробуйте агрегировать все мысли и замечания к данному топику, да собрать все это в понятную и готовую для использования статью — может, что и получится.
Попробуйте агрегировать все мысли и замечания к данному топику, да собрать все это в понятную и готовую для использования статью — может, что и получится.
> Вы хотите обсудить с хабрасообществом основы JS? Думаю, не лучшее занятие; )
почему?
почему?
В этом есть что-либо нового? Того, что не написано на тысячах сайтов про введение в JS?
Да нет, «новое/одно и тоже на разных сайтах» — понятие относительное. Ну захотел человек писать, пусть пишет, кто-то из новичков может только Хабр и читает — почитают заодно (а в комментариях, помимо своего мнения, уже определит, насколько этот материал был полезен). Фишка в том, что, если кто-то достигает какого-то уровня, ему новичковые статьи начинают казаться ерундой, которую не нужно никогда писать (потому что он это уже где-то выучил и знает;)) и он, почему-то, считает долгом это всегда отметить. Только вот загвоздка в том, что это очень и очень относительно. Статьи, которые Вам покажутся не ерундой, кому-то другому могут показаться «уже известными». По-Вашему, он должен Вам это сказать? По сути, если начать придираться, 90% статей на Хабре — может подпасть по гриф «ерунда, которая уже писалась на тысячах сайтов и быстро нагугливается», и что? ;)
Пусть новички пишут; в этом процессе, они сами обучаются.
Пусть новички пишут; в этом процессе, они сами обучаются.
«Поставил себя на место нуба, которому надо быстро найти интересующее решение задачи»
я ведь не могу описать все задачи которые могут попасться на пути человека, но и без знания того что я написал сложно будет людям справиться с возникшими задачами, да, мануалы есть в инете, я больше пишу для того чтоб меня поправили, я ведь тоже ошибаюсь и не знаю многого, когда тебя носом тычут проще запомнить что-то
я ведь не могу описать все задачи которые могут попасться на пути человека, но и без знания того что я написал сложно будет людям справиться с возникшими задачами, да, мануалы есть в инете, я больше пишу для того чтоб меня поправили, я ведь тоже ошибаюсь и не знаю многого, когда тебя носом тычут проще запомнить что-то
а я вот считаю что как раз отличная статья. и что приятно легким и понятным языком рассказыввается как раз об основах. О ряде вещей, которые многие т.н. «программисты» и понятия не имеют…
Позвольте поинтересоваться, что за программисты такие, что не имеют понятия об основах?
Вы много веб-студий видели, а фрилансеров? Не знаю как на росийском рынке, я наблюдаю только украинский, но где то около половины из тех кто что-то пишет для веба, имеют образование и опыт в лучшем случае программистов, неимеющих понятия об основах, но пытающихся что-то писать. Это в лучшем… Хорошо еще если они пытаются учится и разбиратся.
Возможно я не свсме корерктно назвала этих людей программистами, но тем не менее.
Возможно я не свсме корерктно назвала этих людей программистами, но тем не менее.
Так. О веб-студиях и фрилансерах не понял. Видел и тех и других, что с ними не так?
Допустим, под рукой оказался фрилансер-недоучка. Плохая работа — непринятая работа, фрилансер останется голодным. Вопрос в стороне, котрая отвечает за прием работы.
Я сам не управляющий, я обычный исполнитель. Везде, где работал были отличные ребята. То, что продукт получался кривой — это проблема с менеджерами, как показывает опыт при умелом руководстве получается качественный продукт.
Допустим, под рукой оказался фрилансер-недоучка. Плохая работа — непринятая работа, фрилансер останется голодным. Вопрос в стороне, котрая отвечает за прием работы.
Я сам не управляющий, я обычный исполнитель. Везде, где работал были отличные ребята. То, что продукт получался кривой — это проблема с менеджерами, как показывает опыт при умелом руководстве получается качественный продукт.
> То, что продукт получался кривой — это проблема с менеджерами
:) «ну вот, вы видели, сейчас всё и решается, это не креативщикам не хватает идей, просто хорошие идеи идут на помойку...» (С) 99F
В хорошей системе, исполнитель всегда вправе предложить более удобную реализацию идеи, если менеджер — не баран, он её рассмотрит. Поэтому, исполнители тоже играют важную роль в системе.
:) «ну вот, вы видели, сейчас всё и решается, это не креативщикам не хватает идей, просто хорошие идеи идут на помойку...» (С) 99F
В хорошей системе, исполнитель всегда вправе предложить более удобную реализацию идеи, если менеджер — не баран, он её рассмотрит. Поэтому, исполнители тоже играют важную роль в системе.
Естетственно исполнители также важны, как и управленцы. Только вот был очевидцем, когда очень талантливого человека из нашей команды уволили якобы за непродуктивность работы. Объективно он был жертвой отсутствия правильно поставленного ТЗ и хоть сколько-нибудь умеющего управлять менеджера.
Иметь хороший инструмент мало. Нужно уметь им управлять.
Иметь хороший инструмент мало. Нужно уметь им управлять.
А что делать если:
1. Принимающая сторона не в состоянии оценить продукт.
2. В компании вообще нет грамотных специалистов. А те кто есть считают себя самыми крутыми и т.д.?
я не говорю что _все_студии и _все_ фрилансеры идиоты. Я говорю что очень много некачественного продукта написанного кривыми руками хорошие продавцы парят за большие деньги покупателям. А потом этот продукт попатает к другим программистам, те смотрят и говорят — ребят, извините, но это же кашмар какойто, что бы с этим что-то сделать, нужно попросту все переделывать.
Это если утрируя.
1. Принимающая сторона не в состоянии оценить продукт.
2. В компании вообще нет грамотных специалистов. А те кто есть считают себя самыми крутыми и т.д.?
я не говорю что _все_студии и _все_ фрилансеры идиоты. Я говорю что очень много некачественного продукта написанного кривыми руками хорошие продавцы парят за большие деньги покупателям. А потом этот продукт попатает к другим программистам, те смотрят и говорят — ребят, извините, но это же кашмар какойто, что бы с этим что-то сделать, нужно попросту все переделывать.
Это если утрируя.
А что делать если:
1. Принимающая сторона не в состоянии оценить продукт.
2. В компании вообще нет грамотных специалистов. А те кто есть считают себя самыми крутыми и т.д.?
В таком случае стоит обратиться в консалтинговую компанию. Не зря же их придумали. Ну или если по-простому — то нанять надежного человека на должность консультанта, за разовую работу допустим платить хорошие деньги, чтобы не получалось себе дороже в итоге.
Рынок будет наводнен настолько некачественными предложениями, насколько их смогут протолкнуть продавцы.
те кто начинают изучать, я например долго думал что сравнив NaN с NaN я все же могу получить true, или не знал что в разных фреймах разные конструкторы… такие мелочи можно встретить только в каментариях, а при незнании на них напороться очень неприятно
Эффективней прочитать хорошо зарекомендовавшие себя книги, нежели пытаться вылавливать отрывки из тех же книг в комментариях и создавать свой собственный опус. Мое мнение.
посоветуйте пожалуйста хорошо зарекомендовавшей себя литературы в которой описываются мелочи типа тех что я выше привел, буду очень благодарен, в основном на прилавках одни справочники и пособия для начинающих не лучших качеств
Javascript: (Definitive Guide) — все основы есть, определенно рекомендуется к прочтению;
Learning Javascript — хорошая, стоит прочитать;
Professional Javascript for Web Developers — не читал, но собираюсь, по отзывам достойная,
Pro Javascript Techniques — первая половина обязательна к прочтению, учит стилю языка, во второй половине много по практическому применению;
Pro Javascript Design Patterns — лишним не будет;
ну и естетсвенно стандарт языка.
Лично я на дух не воспринимаю русские переводы книг, поэтому от себя рекомендую читать на английском в оригинальной терминологии.
Надеюсь, найдете для себя что-то интересное в этих книгах: )
Learning Javascript — хорошая, стоит прочитать;
Professional Javascript for Web Developers — не читал, но собираюсь, по отзывам достойная,
Pro Javascript Techniques — первая половина обязательна к прочтению, учит стилю языка, во второй половине много по практическому применению;
Pro Javascript Design Patterns — лишним не будет;
ну и естетсвенно стандарт языка.
Лично я на дух не воспринимаю русские переводы книг, поэтому от себя рекомендую читать на английском в оригинальной терминологии.
Надеюсь, найдете для себя что-то интересное в этих книгах: )
Вообще, чего это я, вот мнение большинства.
Почему в типах данных нет undefined и null? function — тоже object, хотя typeof и возвращает другое.
И вообще тему поведения typeof можно было раскрыть получше.
typeof undefined — undefined
typeof null — object
typeof function — function
И вообще тему поведения typeof можно было раскрыть получше.
typeof undefined — undefined
typeof null — object
typeof function — function
потому что undefined и null скорее значения чем типы данных
Что за бред? Извините, но Вы говорите полную чушь. undefined и null такие же типы данных как и остальные, ecma хоть бы чтоли почитали перед тем как статьи бежать писать.
Процитирую специально для Вас, раз вы не в курсе:
8.1 The Undefined Type
The Undefined type has exactly one value, called undefined. Any variable that has not been assigned a value has the value undefined.
8.2 The Null Type
The Null type has exactly one value, called null.
Т.е. эти типы данных имеют только одно значение, которое и называется также. А вот что Вы скрываете под каким-то мифическим словом «значения» понятно наверное только Вам.
8.1 The Undefined Type
The Undefined type has exactly one value, called undefined. Any variable that has not been assigned a value has the value undefined.
8.2 The Null Type
The Null type has exactly one value, called null.
Т.е. эти типы данных имеют только одно значение, которое и называется также. А вот что Вы скрываете под каким-то мифическим словом «значения» понятно наверное только Вам.
В Javascript ведь нет типов как таковых, все вычисляется по значению
Лучше сказать, Javascript — слаботипизированный язык, поскольку типы, всё же, есть ;)
Ну сходу — parseInt(), parseFloat(), toString() — не, не метод преобразования типов?
ну да, эти функции меняют значение переменной на нужное, я не говори что типов совершенно нет, их «как таковых» нет, какое значение у переменной такого она «считается» типа… опять же при значении у переменной значения null она отнюдь не типа null, это обьект, да и массив типом то сложно назвать, это тоже обьект, да и функция — хеш, тот же обьект, поэтому я разделяю типы условно
Вы правы — как нам с малых лет изветсно, все в JS является объектами: ) Типы есть вне зависимости от нашего восприятия их, другое дело, что на них далеко не все внимание обращают.
> все в JS является объектами
не всё, есть ещё и примитивы
не всё, есть ещё и примитивы
чем примитивы — не объекты?
С какой точки зрения? формального языка или реализаций? если реализаций — это дело десятое, как они имплементируют сущности. А вообще, примитивы не могут иметь пропертей.
A primitive value is a datum that is represented directly at the lowest level of the language implementation.
An object is a member of the type Object. It is an unordered collection of properties each of which contains a primitive value, object, or function
как примитив в JS имеет свойства?:) типа «qwe».length а вот у чисел их нет… я интуитивно догадываюсь что в числах "." играет роль разделителя целых и дробных частей, но все же, почему в строках добавили объектную возможность еси это примитив?
> почему в строках добавили объектную возможность еси это примитив?
На самом деле, доступ к свойствам вызывает (см. пункт 5 алгоритма) ToObject. Поэтому каждый раз, когда когда осуществляется доступ к свойству в примитиве, создаётся объект-wrapper, и, после отработки свойства/метода, удаляется.
На самом деле, доступ к свойствам вызывает (см. пункт 5 алгоритма) ToObject. Поэтому каждый раз, когда когда осуществляется доступ к свойству в примитиве, создаётся объект-wrapper, и, после отработки свойства/метода, удаляется.
> а вот у чисел их нет
(1).toString() // «0»
Схематично:
1 -> ToObject(1) -> new Number(1) -> .toString()
У остальных примитивов так же.
(1).toString() // «0»
Схематично:
1 -> ToObject(1) -> new Number(1) -> .toString()
У остальных примитивов так же.
Ничем не объекты :)
Простой пример:
var a = 5; // a примитив
a.t = 3;
alert(a.t);
Что выдаст alert?
Undefined. Почему? Потому что а — примитив. Во второй строке он был сковертирован в объект, которому назначили свойство. В третьей строке этот примитив был опять сконвертирован в объект, у которого спросили несуществующее свойство.
Если бы а был объект alert бы выдал 3.
«Знание некоторых принципов освобождает от знания некоторых фактов»©
Простой пример:
var a = 5; // a примитив
a.t = 3;
alert(a.t);
Что выдаст alert?
Undefined. Почему? Потому что а — примитив. Во второй строке он был сковертирован в объект, которому назначили свойство. В третьей строке этот примитив был опять сконвертирован в объект, у которого спросили несуществующее свойство.
Если бы а был объект alert бы выдал 3.
«Знание некоторых принципов освобождает от знания некоторых фактов»©
для тебя наверно является дикостью возможность осознать, что объект вовсе не обязательно должен являться хэш-таблицей?
во второй строке примитивный объект создал комплексный объект. он всегда так делает, когда к нему обращаются как к хэш-таблице, коей он не является.
во второй строке примитивный объект создал комплексный объект. он всегда так делает, когда к нему обращаются как к хэш-таблице, коей он не является.
> примитивный объект создал комплексный объект
Обособленных определений может быть тысячи, для себя можно понимать, представлять тоже как угодно (главное, чтоб это помогало найти путь к правильному пониманию). А формальные определения — есть формальные определения, там всё чётко и (если всё формальный язык описан корректно) — недвусмысленно.
var a = 10;
Примитив? Примитив.
Однако, если обособленно начать придумывать/додумывать, и, как следствие, называть «примитивным объектом», в виду того, что, во-первых, «а» станет свойством, у которых могут быть внутренние атрибуты (например, как здесь — {DontDelete}), т.е. можно представить «а», как объект с со свойством: a.DontDelete = true; но только так, можно ещё тысячу определений придумать (если видишь в этом смысл — пожалуйста).
ps: да и, ничего там примитив не создавал, движок создаёт объект и ставит ему в [[value]] значение примитива.
Обособленных определений может быть тысячи, для себя можно понимать, представлять тоже как угодно (главное, чтоб это помогало найти путь к правильному пониманию). А формальные определения — есть формальные определения, там всё чётко и (если всё формальный язык описан корректно) — недвусмысленно.
var a = 10;
Примитив? Примитив.
Однако, если обособленно начать придумывать/додумывать, и, как следствие, называть «примитивным объектом», в виду того, что, во-первых, «а» станет свойством, у которых могут быть внутренние атрибуты (например, как здесь — {DontDelete}), т.е. можно представить «а», как объект с со свойством: a.DontDelete = true; но только так, можно ещё тысячу определений придумать (если видишь в этом смысл — пожалуйста).
ps: да и, ничего там примитив не создавал, движок создаёт объект и ставит ему в [[value]] значение примитива.
функции тоже ничего не делают — просто движок интерпретирует их байткод.
переменные, кстати, — тоже объекты, ибо поддерживают интерфейсы «создать», «удалить», «сохранить» и «получить», при этом хранят в себе не только «основное значение», но и всякие флаги. а также они являются неявными параметрами замкнутых на них функций.
переменные, кстати, — тоже объекты, ибо поддерживают интерфейсы «создать», «удалить», «сохранить» и «получить», при этом хранят в себе не только «основное значение», но и всякие флаги. а также они являются неявными параметрами замкнутых на них функций.
важно понимать разницу между «объекты из ооп» и «экземпляры одноимённого встроенного класса».
а то потом рождаются определения в духе «объект — это экземпляр класса» о_0
а то потом рождаются определения в духе «объект — это экземпляр класса» о_0
переменные, кстати, — тоже объекты, ибо поддерживают интерфейсы «создать», «удалить», «сохранить» и «получить», при этом хранят в себе не только «основное значение», но и всякие флаги. а также они являются неявными параметрами замкнутых на них функций.
Ну так я и повторю — умозрительно, и догадками — можно хоть как это видеть (см. пример с a.DontDelete). Реализации здесь не имеют значения (вообще), там это может быть представленно любыми структурами. Стандарт разделяет примитивы и объекты. При этом, додуманные «интерфейсы» aka «создать», «удалить» и т.д. — это тоже, лишь додумки (не важно, верные или нет в реализациях, поскольку, снова повторю, реализации — дело десятое). Чтобы это не было додумками, надо: во-первых — чтобы формальное описание это подтверждало (а это уже не так) + проанализировать исходники всех реализаций (возможно, там все сущности будут комплексными, а, может, и нет — например, хранится примитивное значение и + какая-нить таблица атрибутов примитивов, тогда при a.DontDelete уже не будет казаться, что «а» — комплексная структура).
Ещё раз:
A primitive value is a datum that is represented directly at the lowest level of the language implementation.
Всё остальное (конкретика реализации) — это мелочи, там это может быть хоть хэш-таблица, обёрнутая в хэш-таблицу, по-барабану.
> переменные, кстати, — тоже объекты
переменные, естественно, могут быть объектами.
Объектами: var a = new Number(1),
или примитивами: var a = 1;
переменные, естественно, могут быть объектами.
Объектами: var a = new Number(1),
или примитивами: var a = 1;
dsCode всё правильно написал. Если хотите называть примитивы примитивными объектами, флаг вам в руки — только запутаете себя и других.
а вас не путает, что typeof null === 'object'?
а typeof вообще вычисляется согласно захардкоженной таблице ;)
знание внутренней реализации мешает тебе сопоставлять факты…
null — это объектная ссылка указывающая на априори недоступную область памяти.
это примитив, так как не может динамически менять своего состояния, но в то же время и специальный объект, ничего не умеющий и ничего не занимающий в памяти.
вот и получается, что в яваскрипте объекты — это ссылки. обычно эти ссылки указывают на хэш-таблицы, но есть и ссылки указывающие в никуда.
тебе нравится такое определение объекта на основе реализации закреплённой в спецификации? мне — не очень.
null — это объектная ссылка указывающая на априори недоступную область памяти.
это примитив, так как не может динамически менять своего состояния, но в то же время и специальный объект, ничего не умеющий и ничего не занимающий в памяти.
вот и получается, что в яваскрипте объекты — это ссылки. обычно эти ссылки указывают на хэш-таблицы, но есть и ссылки указывающие в никуда.
тебе нравится такое определение объекта на основе реализации закреплённой в спецификации? мне — не очень.
» null — это объектная ссылка указывающая на априори недоступную область памяти.
null — это примитивное значение типа null. Такое же как «1» или «false».
» но в то же время и специальный объект, ничего не умеющий и ничего не занимающий в памяти.
Откуда такая уверенность, что null ничего не занимает в памяти?
Null Value
The null value is a primitive value that represents the null, empty, or non-existent reference.
Согласно спецификации null не объект, а примитив. Typeof врёт.
null — это примитивное значение типа null. Такое же как «1» или «false».
» но в то же время и специальный объект, ничего не умеющий и ничего не занимающий в памяти.
Откуда такая уверенность, что null ничего не занимает в памяти?
Null Value
The null value is a primitive value that represents the null, empty, or non-existent reference.
Согласно спецификации null не объект, а примитив. Typeof врёт.
Точно так же как и то что typeof function(){} == «function». Я просто знаю, что typeof нагло врёт в этих двух случаях.
ссылка на функцию и объектная ссылка — это две разные сущности. какой бы бред про [[Call]] ни был написан в спецификации…
Ну вот мы пришли к тому, что в спецификации написан бред.
Я, к сожалению, не могу обсуждать вашу модель языка, я не телепат. Я могу только говорить про то, что написано в спецификации.
Null — примитив
Функция — объект
В чём по-вашему разница между функцией и обёктом?
Я, к сожалению, не могу обсуждать вашу модель языка, я не телепат. Я могу только говорить про то, что написано в спецификации.
Null — примитив
Функция — объект
В чём по-вашему разница между функцией и обёктом?
вот именно, что бред. а вы его в упор не видите.
в одном месте написано, что это объект, в другом — что нет.
в одном месте написано, что это объект, в другом — что нет.
Ничего подобного. Приведите мне цитату, где написано, что null это объект.
> typeof value === 'object'
типом значения является «объект»
типом значения является «объект»
Это ваш вольный перевод метода typeof.
typeof function(){} === «function»
В Javascript нет такого типа как function.
Вот что делает typeof:
Return a string determined by Type(Result(4)) according to the following table:
Undefined — «undefined»
Null — «object» (!!!)
Boolean — «boolean»
Number — «number»
String — «string»
Object (native and doesn’t implement [[Call]]) — «object»
Object (native and implements [[Call]]) — «function» (!!!)
Почему typeof такая ненадёжная я не знаю, но она такая.
Вот и всё. Тема закрыта.
typeof function(){} === «function»
В Javascript нет такого типа как function.
Вот что делает typeof:
Return a string determined by Type(Result(4)) according to the following table:
Undefined — «undefined»
Null — «object» (!!!)
Boolean — «boolean»
Number — «number»
String — «string»
Object (native and doesn’t implement [[Call]]) — «object»
Object (native and implements [[Call]]) — «function» (!!!)
Почему typeof такая ненадёжная я не знаю, но она такая.
Вот и всё. Тема закрыта.
> Это ваш вольный перевод метода typeof.
это семантика этого _унарного оператора_
она едина для всех языков.
> В Javascript нет такого типа как function.
ru.wikipedia.org/wiki/%D0%A2%D0%B8%D0%BF_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
это семантика этого _унарного оператора_
она едина для всех языков.
> В Javascript нет такого типа как function.
ru.wikipedia.org/wiki/%D0%A2%D0%B8%D0%BF_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
Читайте спецификацию.
развивайте способность к аналитическому мышлению.
Если существует свойство со значением типа 'Undefined', то typeof скажет 'undefined'. Если свойство не существует вообще в природе, то typeof тоже скажет 'undefined'.
Аналитический мыслитель может выбрать одно из двух — или верить typeof, а значит несуществующее свойство существует и у него есть значение, а у того тип… или 'typeof' просто не надо переводить буквально, он показывает не тип, а плюс-минус-тип-а-то-и-не-тип-вовсе…
Аналитический мыслитель может выбрать одно из двух — или верить typeof, а значит несуществующее свойство существует и у него есть значение, а у того тип… или 'typeof' просто не надо переводить буквально, он показывает не тип, а плюс-минус-тип-а-то-и-не-тип-вовсе…
typeof ничего не знает о свойствах. всё, что справа от него вычисляется как выражение. когда мы делаем запрос к объекту «дай мне значение по такому-то ключу» — он возвращает undefined независимо от того есть у него такой ключ (но значение «неопределено») или нет. в typeof приходит уже само значение undefined.
нет типов переменных, но есть типа значений…
> For( key in obj )
опечатка, for — с маленькой буквы, JS — регистрозависимый.
> или удалить с помощью оператора delete ( delete someVar; )
ну и о delete, уже отметили выше: всем var'ам ставится внутренне свойство {DontDelete}, означающее, что их нельзя удалить посредством delete (исключение составляет лишь контекст eval).
опечатка, for — с маленькой буквы, JS — регистрозависимый.
> или удалить с помощью оператора delete ( delete someVar; )
ну и о delete, уже отметили выше: всем var'ам ставится внутренне свойство {DontDelete}, означающее, что их нельзя удалить посредством delete (исключение составляет лишь контекст eval).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Javascript от а и до… II