ну конечно, если создать объект числа, то число будет объектом...

Destruction, и что пример должен показать? Обернул ты строку в Number обьект, во второй строке опросил конструктор у конструктора, т.е. у функции (Function обьект). В JS есть оьекты и примитивы, строки, числа, это всё примитивы. Xотя new String, new Number и т.д. это обьекты. Особенно сбивает с толку такой приём

Sardar,
а вот получается что условия типа if (a) проверяют на наличие переменной, а не на то что, она равна false, true или 0,1 ?

Innuendo,
нет, тут всё сложнее. на наличие не перемнных, а объектов.
кода

работат "правильно".

а также



Это сообщение отредактировал(а) Alx - 12.2.2006, 22:24

Наличие переменной не при чём. Всё работает по строгой логике для if (см. Ecma-262, 12.5), выражение в скобках вычисляется и приводится к типу Boolean (см. Ecma-262, 9.2). Соответственно, приведение к этому типу объекта new Boolean(false) даст true.

Существование обьекта это true, null это false, не важно состояние обьекта (в примере содержи false).

@ Sardar & Alx:

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



например...

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



Это сообщение отредактировал(а) Destruction - 13.2.2006, 11:48

regis & Destruction, Нет, это называеться autoboxing, проиходит динамически когда ты обращаешся с примитивом как с обьектом, но значение всё равно не оборачиваеться в обьект.



Обьекты почти всегда в скриптах выполнены на как хештаблицы, реже деревья. Т.е. обьект это набор пар ключь=>значение + сылка на прототип (опять же обьект). Держать хештаблицу для каждого значения весьма накладно (интересно как порешали в Ruby, где действительно всё это обьекты?), потому и существуют примитивы, что "имеют" ссылку только на прототип Number. Числа обычно храняться прямо в структуре "универсального значения", обычно в union. Фактически никаких ссылок нет, все числа при обращении с ними как с обьектами обращаються к прототипу Number.

Когда мы пишем:

Происходит следующее, по шагам:

• сложить, результат на стек
• найти поле constructor, это примитив число, значит обращаемся к нативному обьекту Number
• найти у обьекта Number (помним что это функция, т.е. обьект) поле toString, если поле это обьект-функция, то вызываем, иначе кидаем исключение

Опустил детали конкретного движка, вычисления могут быть традиционно на стеке (Java, C#), а могут быть в "регистрах" (Parrot (Perl6)). В целом видим что примитивы это всё таки очень лёгкие "существа" в отличии от полноценных обьектов. Все примитивы не мутируемы, чем и отличаються от ссылочных значений. Только строки исключение, они не мутируемы, но ссылочные, что бы не копировать их по чём зря в памяти

Надеюсь обьяснил, кончаем офтоп, по вопроссам внутренней работы JS создаём новую тему

бл... пойду умные книжки читать.. - половину ваще не понял.

Это сообщение отредактировал(а) Destruction - 13.2.2006, 15:21

Перевёл разговор про примитивы сюда - http://forum.vingrad.ru/index.php?showtopic=83710

Вот недостатки, которые сразу пришли в голову:
1. Нет статических переменных.
2. Нет ООП (фичи с prototype, this и т.д. не считаются)
3. Нет инклуда других скриптов.
4. Нет аргументов по умолчанию у функций (пляски с .arguments не веселят)

Это так, недостатки самого языка. Недостатки всей платформы (если можно так выразиться) упираются в кроссбраузерность.

ИМХО ^

что ты подразумеваешь под статичными переменными и ООП?
JavaScript даже слишком ОО...
инклуд есть, чуть-чуть изворотливый, но в общем совсем не сложный
а вот 4 дейчаствительно большой недостаток, кстати, как пример, именно вот такие недостатки я и хотел собрать, то есть не пространные, а конкретные и обидные.

Как представлю такой синтаксис в JS

Ещё бы вызов с именованными аргументами:

Да... красиво было бы
Добавлено @ 01:45
А вообще долго тащился

Кто пользовал XMLHttpRequest знает что его onreadystatechange исполняеться в отдельном треде. JS не многопоточная среда, все setTimeout, события и прочее исполняеться друг за дргугом, модальное окно alert останавливает исполнение. Раз нет многопоточности, значит нет проблем с синхронизацией, концепция проста и удобна.

В результате "второго треда" от XMLHttpRequest гармония нарушаеться, т.к. средств синхронизации нет приходиться надеяться что "основной тред" и тот что от XMLHttpRequest не возьмуться работать с одной нодой. Хотя шанс на это мал, но всё таки не приятна такая не ясность.

Настоящая трабла возникает в поведении JS обьектов, судя по всему они копируються в новый тред. Попробуйте создать обьект (назововём А), очертить closure которой будет "виден" обьект, отдать полученный closure на onreadystatechange обьекта XMLHttpRequest. В closure измените какое нибудь свойство обьекта А, сразу же убедитесь что свойство изменилось. Напишите кнопку что будет опрашивать изменяемое свойство А. Запускаем, видим что поле обьекта А изменяеться, затем жмём кнопку, удивляемся почему поле того же обьекта А не изменилось.

Обьяснение фокусу пока одно - JS обьект передаваемый в "новый тред" копируеться, обработчик события работает с копией в "новом треде", из него видим что поле изменяеться. События кнопки работают в "основном треде", замечаем что "оригинальная копия" обьекта не изменяеться.

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