Ну если вам это не нужно, то действительно, смысл это изучать?)).
Но если вдруг интересно, могу вкратце объяснить. Это модель RGB, т.е. три компонента — красный, зелёный, синий (Red, Green, Blue).
Каждый имеет значение от 0 до 255, а в HEX — это от 00 до FF.
Соответственно:
255,255,255 = FF FF FF (белый)
0,0,0 = 00 00 00 (чёрный)
Вот как-то так. Основные цвета понятны: ff0000 — красный; 00ff00 — зелёный, 0000ff — синий, также полезно знать их смеси: ffff00 — жёлтый (отсутствие синего), ff00ff — розовый (красный + синий; отсутствие зелёного), 00ffff — ярко-голубой (зелёный + синий; отсутствие красного).
Да, собственно, это вся теория. Надеюсь, шестнадцатиричные числа объяснять не нужно :D
Остальные цвета — это их смеси.
К примеру, E8 2D 0C — много красного, почти нет зелёного, ещё меньше синего => это красный, но немного другого оттенка.
Ну и можно ещё засветлять-затемнять.
К FF0000 прибавим немножко чёрного — будет EE0000 (более тёмный красный) или, например, AA0000 (ещё более).
Немножко белого — будет FF1111, например, или FF5555.
> Во-первых, это позволило нам обойти подводные камни, связанных с тем, как this работает в JavaScript. К примеру, больше нет путанницы с тем, что jQuery переопределяет this на объект который итерирует.
Мне кажется, нужно знать инструмент, с которым работаешь — будь то jQuery или сам JavaScript).
Просто вполне разбираюсь в подобных вещах, а однажды даже подбирал цвета в hex для сайта сам, в уме, т.к. фотошоп / любой colorpicker было лень открывать, а про rgba почему-то забыл :). Это был незабываемый опыт)).
> Допустим, что дизайнер скинул нам 5 цветов и скорее всего в HEX-формате: #FF0000, #E82C0C, #FF530D, #E80C7A, #FF0DFF. Что говорят нам эти буквы и цифры? Да ничего — это больше понятно монитору, нежели человеку.
Ну кому как). Первый — красный, понятно, это основы. Остальные… на глаз:
E82D0C — красный, но чуть другой оттенок
FF530D — оранжевый, как-то так. Или красный с оранжевым оттенком.
E80C7A — фиолетовый, причём красного больше чем синего.
FF0DFF — розовый.
> TypeError: Object test has no method 'isCyrrilic'
Естественно, поскольку вы добавили метод в класс, а не в его прототип. А свойства к экземплярам класса переходят именно из прототипа.
Итак, сначала. Я предложил, чтобы библиотека касалась прототипов (да и вообще встроенных объектов, если уж на то пошло) лишь по запросу разработчика. Мы используем функцию Sugar.usePrototypes(), которая переносит все нужные функции в прототипы. Если это нам удобно.
Если нет — не используем, а юзаем функции из самого объекта Sugar.
> загадили методами сам объект String
ну это уже субъективно. Лично мне абсолютно не мешает расширение встроенных объектов, если это не создаёт проблем (как с array.prototype и for..in).
> Обходить массив при помощи цикла for..in тоже возможно, но это не считается хорошей практикой. Если вы решили использовать этот подход, всегда применяйте метод hasOwnProperty, чтобы проверять, принадлежат ли свойства непосредственно объекту (см. последний пример в раскрывашке выше).
Кроме прочего, кстати, у массива могут быть свои свойства. Ну вот примерно так:
var arr = [1,2,3];
arr.foo = 20;
И это свойство также будет включено при for..in, причём hasOwnProperty от него не спасёт. Так что нужно за этим внимательно следить, и, если такие свойства не нужны, вообще не использовать for..in для массивов.
А вообще очень интересен этот давний спор про прототипы… Почему никто не делает так вот?)
String.isCyrrilic; // function()…
String.prototype.isCyrillic; // undefined
Sugar.usePrototypes();
String.prototype.isCyrillic; // function()…
То есть, мы подключаем библиотеку, и сами выбираем, использовать ли прототипы.
А ещё есть RightJS, у которого, если мне память не изменяет, 2 разных версии — с прототипами и без.
Я знаю одну мморпг, где количество определённых предметов каким-то образом ограничено, а шанс выпадения нехило зависит от количества таких предметов на руках.
Кстати говоря, для Kinect-а тоже была библиотека, переносящая его в JS (правда, насколько помню, онли хром / сафари, причём не все ОС… правда, это было 3 года назад). DepthJS. github.com/doug/depthjs
Берём случайным образом.
Вероятность, что она из 2 группы — 8/11.
> если разработчик зачем-то использует for..in для массива
— акцент на слове «зачем-то»).
Ну некоторые и массивы с true/false сравнивают. А потом кричат, какой js плохой.
Ну мало ли )). Я с вами недостаточно знаком, чтобы делать выводы об этом). По умолчанию — нет.
Но если вдруг интересно, могу вкратце объяснить. Это модель RGB, т.е. три компонента — красный, зелёный, синий (Red, Green, Blue).
Каждый имеет значение от 0 до 255, а в HEX — это от 00 до FF.
Соответственно:
255,255,255 = FF FF FF (белый)
0,0,0 = 00 00 00 (чёрный)
Вот как-то так. Основные цвета понятны: ff0000 — красный; 00ff00 — зелёный, 0000ff — синий, также полезно знать их смеси: ffff00 — жёлтый (отсутствие синего), ff00ff — розовый (красный + синий; отсутствие зелёного), 00ffff — ярко-голубой (зелёный + синий; отсутствие красного).
Да, собственно, это вся теория. Надеюсь, шестнадцатиричные числа объяснять не нужно :D
Остальные цвета — это их смеси.
К примеру, E8 2D 0C — много красного, почти нет зелёного, ещё меньше синего => это красный, но немного другого оттенка.
Ну и можно ещё засветлять-затемнять.
К FF0000 прибавим немножко чёрного — будет EE0000 (более тёмный красный) или, например, AA0000 (ещё более).
Немножко белого — будет FF1111, например, или FF5555.
Да вот и всё).
Мне кажется, нужно знать инструмент, с которым работаешь — будь то jQuery или сам JavaScript).
Ну кому как). Первый — красный, понятно, это основы. Остальные… на глаз:
E82D0C — красный, но чуть другой оттенок
FF530D — оранжевый, как-то так. Или красный с оранжевым оттенком.
E80C7A — фиолетовый, причём красного больше чем синего.
FF0DFF — розовый.
> TypeError: Object test has no method 'isCyrrilic'
Естественно, поскольку вы добавили метод в класс, а не в его прототип. А свойства к экземплярам класса переходят именно из прототипа.
Итак, сначала. Я предложил, чтобы библиотека касалась прототипов (да и вообще встроенных объектов, если уж на то пошло) лишь по запросу разработчика. Мы используем функцию Sugar.usePrototypes(), которая переносит все нужные функции в прототипы. Если это нам удобно.
Если нет — не используем, а юзаем функции из самого объекта Sugar.
> загадили методами сам объект String
ну это уже субъективно. Лично мне абсолютно не мешает расширение встроенных объектов, если это не создаёт проблем (как с array.prototype и for..in).
var arr = [1,2,3];
for(var key in arr){
console.log(key);
}
=> 1, 2, 3, 'randomElement', 'last'
Т.е. если разработчик зачем-то использует for..in для массива, да ещё и не озаботился hasOwnProperty добавить, то он получает проблемы.
Кроме прочего, кстати, у массива могут быть свои свойства. Ну вот примерно так:
var arr = [1,2,3];
arr.foo = 20;
И это свойство также будет включено при for..in, причём hasOwnProperty от него не спасёт. Так что нужно за этим внимательно следить, и, если такие свойства не нужны, вообще не использовать for..in для массивов.
А вообще очень интересен этот давний спор про прототипы… Почему никто не делает так вот?)
String.isCyrrilic; // function()…
String.prototype.isCyrillic; // undefined
Sugar.usePrototypes();
String.prototype.isCyrillic; // function()…
То есть, мы подключаем библиотеку, и сами выбираем, использовать ли прототипы.
А ещё есть RightJS, у которого, если мне память не изменяет, 2 разных версии — с прототипами и без.
P.S. извиняюсь за отсутствие тега source ).
и функция должна возвращать число, иначе она void, а не int.
ЗЫ: я не Сишник, я как раз на JS, и с вами в общем-то согласен, но всё же)
github.com/doug/depthjs
anonymizer.ru
2ip.ru/anonim
и т.п.
Можно, я не буду деанонимизироваться?)
Претензий к вам, если вы про это, никаких не имею.
Мое имхо.