Почему alert(18306744..toString(32)); выводит Hello
 

Почему alert(18306744..toString(32)); выводит Hello?
Собсно скинули вот такую конструкцию с вопросом, почему.
Гугл мне ничего не подсказал. Если не сложно подскажите.

alert(parseInt('hello', 32)) // 18306744

Потому что в системе счисления с основанием 32 последовательность символов hello соответствует числу 18306744 в десятичной системе счисления.

Спасибо за ответ.

Еще вопрос, почему toString(null) рисует мне слово null?

Ну то есть как тут понимать что из ничего берется целых 4 буквы? Это скольки-разрядная система счисления?

toString(null) не рисует null, а выбрасывает исключение, потому что null приводится к 0, а системы счисления с основанием 0 не существует

А кто тогда рисует слово null?

var some = elem.getAttribute('no_such_attr_at_all'); // null
elem.title = some; // строка "null"

это же toString() работает, или кто там рендерит проперти?

Ну да, не в аргумент, я по шаблону написал, null.toString(); тогда.

Единственное место где я задумался почему php не рендерит "NULL" это запись в БД, в допустим timestamp. Приходится вручную профтыкать. А js в какую-такую БД предназначен писать свои "null"?

Метод getAttribute возвращает null, причем тут toString вообще?

Это не будет работать, потому что null – примитив, у него нет прототипа, в котором бы был метод toString.

Он что - строку null возвращает - из 4-х букв?

Я про что пишу. Во всех нормальных языках чтобы увидеть NULL, FALSE, UNDEFINED и тп - надо специальными методами ковырять нутро переменной. В JS же х проссышь - ну пишет тебе в консоли null и пишет. А какой - увидишь только в интерфейсе.

Да в общем вопрос риторический. Понятно что падла рендерит null без спроса.

Каноничный пример

function echoit($msg) {
	echo '<br><pre>';
	if($msg)
		echo htmlents(print_r($msg, true));
	else
		var_dump($msg); // без этой штуки увидишь вместо null и false - ничего
	echo '</pre><br>';
}

Такое впечатление что JS планировался для домохозяек, которые если null не увидят, то неделю будут его искать.

Я интерфейс не рендерю, а кто рендерит - они как эти бесконечные нуллы обходят?

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

Это понятно, непонятно откуда берутся целых 4 буквы из null. Если там ничего не было, то в строке должно быть ""

В первом предложении вы объяснили как оно туда попадает.

Только не надо про то что null это особый случай, что это специально так сделано. Любой нормальный программист естественно ожидает что null в строке станет или "" или 0 - не символ, а код.

Если бы я title проверял на null, как я однажды проверял !dataset.somevar - так то я уже запомнил, что не будет там !, там будет строка из четырех букаф, мило, блин. Ну а если вы в консоли видите null - откуда уверенность что он в интерфейс не попадет? Откуда-то взялся где его вернули, вы ставляете, вместо пусто - хрень какая непонятная домохозяйкам.

Хватит воевать с языком. Примитивы в javascript преобразуются в строку как явно. Не "любой программист" ожидает, а ты ожидаешь. Так устроен js и не иначе. Хочешь пустую строку - выводи пустую строку, а не рандомную хрень.

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

Как-то не весь ява-скрипт:

var WshShell = WScript.CreateObject("WScript.Shell");
strPath = WshShell.currentDirectory;
var fso = new ActiveXObject("Scripting.FileSystemObject");

var text = ['one', 'two', null, 0, false, true, null, "0", 0];

var out_file_name=fso.BuildPath(strPath, 'test_null.txt');	
var ts = fso.CreateTextFile(out_file_name, true, true);
ts.Write(text.join("\n"));
ts.Close();

Существует поверье что при нестрогом сравнении "нет" вычисляется для: "" пустой строки, [], пустого массива, 0 - нуля, null и false (хотя false это все что !0 бинарно). Когда пофигу то ! должен работать на всем перечисленном. Когда не пофигу, тогда === пофигу.

И тут я вспомнил что в __toString() рендер не показывает true и false и захотел показать. И что вы думаете? Оказывается в php вообще нет нормальных методов приведения boolean к строке. var_export() корежит все остальное, а strval() фактически явный вызов неявной функции. В итоге true получается 1, а false == "". Полегчало когда понял что смысла нет. Идиотизм же в html, капец: autocomplete="off" novalidate="on" disabled="true" readonly вообще индикатор.

В голове твоей идиотизм)
novalidate - флаг.
disabled - тоже флаг.

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

Зашибись, попросите их сделать еще ВКЛ и ОТКЛ.

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

required остается индикатором
disabled становится параметром

Глючной это домен dhtml. Я раньше слышал об этом от грамотных людей, теперь сам столкнулся.

Из приключений еще. Вчера js меня еще нагрел в соавторстве. Код - сообщение на русском - код. И надо же мне было придумать по-быстрому имя переменной - с. После сообщения на русском не переключил и злоебучее совпадение на клаве выдало нечто \u0410 is undefined или типа того. Одновременно в консоль по ошибке высыпается responseText который тоже весь состоит из юни-кодов таких. Блеать, думаю, как это понимать - при чем тут какая-то буква из ответа сервера и почему браузер доебался. Выкосил эксепшны, записал мастера в мин-файл (иначе на строку х покажет), показывает на c.innerHTML=data.responseText. Пять минут смотрел пока не заметил что все остальные с подсвечиваются, а эта - тухлая. Оказалась - кириллица.

Предлагаю перенести русскую С на другую кнопку!

Они оба имеют булеан тип.
Не называются по-другому. Все превращается по понятной логике.
Нужно только помнить про булеан атрибуты.
Присутствие атрибута - true. Отсутствие атрибута - false.

Кажется это придумали давно. Сейчас не всех это устраивает, но уже ничего не поделаешь.

А вот атрибут spellcheck имеет значения true/false. https://blog.whatwg.org/the-road-to-...-spellchecking
Видимо все-таки идиотизм есть и в HTML )

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

Думаю тут основная причина в обратной совместимости. Хорошо когда можно все старое дерьмо бросить и начать с нуля. С HTML такое не прокатит)

Золотые слова :)

Используй линукс - тут можно осуществить твою мечту :)

Хехехе, а вот и нет. Ели ты думаешь, что написав с нуля ты избавишься от уродства, косяков, багфич и прочего легаси счастья - ты отчасти прав. Однако если ты думаешь, что новый результат будет прекрасен и не будет содержать абсолютно новых уродств, косяков и багофич - ты очень сильно заблуждаешься. Жизнь жестока.:D

Ну идеалов не бывает - это ясное дело. Как минимум потому что всем сразу не угодишь. Но как правило в новой версии исправлены ошибки предыдущих версий. К примеру PHP:
Было:

str_replace(search, replace, $str);
strpos($str, needle)

Станет:

$str->replace(search, replace);
$str->indexOf(needle);

Думаю не нужно объяснять где уродства больше.

В случае же с HTML нельзя сделать чтобы атрибуты принимали true/false - старые реализации будут неправильно интерпретировать разметку.

danik.js, увы я не шарю в пхп(если что надо на нём наговноеодить - использую гугл), но готов поспорить что в "новом" пхп говна и уродства тоже отсыпали с лихвой, просто теперь в другом месте.)

Пхп весь из этого состоит :) Но спустя 20 лет они решили, что неплохобы спеку по языку сделать :D

"увы" тут не к месту )

Кто-нить покажите ему disabled=true и disabled=false на кнопке.

Объяснимо. Собираете поиском куски говнокода отсюда и впечатление складывается.

У самого есть руки. У тебя их видимо нет, так что вот тебе:

<button disabled="false">Эта кнопка должна быть включена</button>

JS убивает что ли атрибут когда я вот так делаю

for(var name in inputs)
	err|=(inputs[name].error);
submit.disabled=err;

Внезапно задисабленая кнопка оживает если нет ни одного не нул.

Это программисты так захотели. Которые ниасилили С и cgi, и даже perl. Ну и у которых нет деняг на типа ASP. На скрипте для отправки формы теперь пишут невьебенные фреймворки, ахренеть.

Насчет косяков с атрибутами и пропертями. Вам приходилось программировать в другом DOM'е, или слаще хтмльного нет? В других документах и их моделях у вас попросту нет исходных данных, то есть как API предоставляет, то для вас и данность. Вы не знаете как там правильно называется атрибут колонтитула в ворде, не знаете какие вы могли бы профтыкать атрибуты в диапазон ячеек екзеля, можете только догадыватся как называется параметр opacity для объекта "слой" в ФШ.

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

Вот я и пишу

maxlength: elem.getAttribute('maxlength'),

потому что мне в х не стучит что оно там оказывается maxLength. Слева - мой объект в абсракции JS, как хочу так и пишу, как было то есть.

В частности в ФШ без мануала нехер делать вообще. Вы никогда не догадаетесь что Filter->Unsharp Mask... в API называется, цитата:

layer.applyUnSharpMask

Такие "соглашения" как ваш верблюд ничего не стоят и наплюют вам в морду без сожаления. Что JS для браузеров и демонстрирует.

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