а тут уже недостаток знаний с твоей стороны, js не виноват что ты его неправильно используешь
Документированы не "причуды" а способы автоматического преобразования типов данных. За это удобство (динамический тип переменной) нужно платить знанием преобразования переменных. Лучшая книга ИМХО Дэвид Флэнаган - " Подробное руководство по JavaScript "
['10','10','10','10','10'].map((val)=>parseInt(val))
// [10, 10, 10, 10, 10]
Параметры в колбек кто передавать будет?!
помню спросил как-то на форуме что-то связанное с обработкой событий в js. Мне тут же сказали имя библиотеки для node.js для управления событиями. Но стоило немного подумать и погуглить, как я таки обошёлся средствами стандартного js+jquery. Думается, часто библиотеки тащат тупо от лени
Я пробовал полтора года назад и мне сильно понравилось. Возможно сейчас есть что-то более крутое.
Объясните мне, пожалуйста. В почти каждом примере установке просят ввести команду npm install -*.*
Тот же CoffeeScript для установки требует ноду и ввести эти строки. Понятно, что устанавливаем ноду, вводим в её консольку npm install , а дальше?
Есть какая-то стандартизированная среда? Какие-то стандартные несколько шагов, которые приведут меня в ту среду, где я могу просто написать npm install -*.* и юзать то, что только что установил?
Может я неправильно понимаю, объясните хоть немножечко, хотя бы в какую сторону думать.
Нусъ.
npm - менеджер пакетов идущий в составе Node.js, в основном ему без разницы где работать (лучше естественно дистриб с линуксом), главное, чтобы нода стояла, сообственно.
Чтобы заюзать свой "npm i <packet> -S" (i - алиас install, -S добавить введённый пакет в package.json) обычно в файле конфига (того или иного приложения) юзается requre(<packet>) для подключения. Например, очень популярны автосборщики js + es6 (babel) + live templates и "корневым" пакетом для этой сборки будет являться webpack. Описываете конфиг для вебпака, пишете буквально в пару строк конфигурации и подключаемые модули (requre(<packet>)) - вуаля, смотрим на работу, никакой сложности.
Например, поднятие веб-сервера с помощью npm выглядит вот так (https://www.npmjs.com/package/http-server):
mkdir project && cd project
npm init (инициализация приложения, тыкаете далее > далее > далее..., в директории появляется package.json)
npm i http-server -D (устанавливаете пакет веб сервера с сохранением в dev зависимости)
http-server (запуск сервера)
всё, дальше конфигурите, подключаете модули и так далее
Вам для js или для nodejs? Я не очень хорошо разбираюсь в js, но для фронтальной части всё работает примерно вот так:
1. Скачиваем библиотеку (например npm install jquery)
2. Подключаем её в html страничке (<script src="/path/to/jquery/jquery.min.js"></script>)
3. Используем в своих скриптах функционал из подключенной библиотеки
Кофе скрпит работает вот таким образом:
1. Пишем код на кофескрипт
2. Через консольную утилиту преобразовываем кофе в js
3. Подключаем файлы, которые получились на выходе
npm это всего-лишь утилита, которая позволяет работать с удаленными репозиториями и устанавливать библиотеки, чтобы вы не ходили вручную скачивать необходимые для вас библиотеки.
Имхо, чтобы нормально пользоваться nodejs или ruby on rails, нужно хорошенько изучить команды терминала. На сервере без этих знаний делать нечего (или юзать PHP)
Кофе - не JS. Если адепты будут затирать обратное - разворачивай и шли.
Он компилируется в JS, но не JS
Реакт посмотри, мб понравится
Кому как больше нравится, у кого какие предрассудки по поводу памяти и захламлённости интерфейса. Устроился на работу после универа по специальности - прогером. До этого в школе с 7 класса прогал на С++, в универе начали пихать сначала паскаль, потом php, потом c#
Кстати, C# очень вкусный, но от него быстро отвыкаешь, начав пользоваться JS'ом.
Так вот, как человек, который испытал многие прелести жизни, я не стал юзать либы и ходить налево, а просто начал гуглить и искать, как юзать JS. Читенький, красивенький.
Был момент, когда пара коллег говорили: ууу, ты юзаешь голый JS? Мы тут не поможем.
Другие коллеги говорили, что так меньше памяти жрётся (сомневаюсь), ну а я понял, что сначала изучаем JS, потом приходит лень и начинаешь подключать либы, сначала в мою жизнь пришел lodash, потом angular, но jQuerry до сих пор не брал, потому что и тааак сойдет.
Всё приходит с опытом, как считаете? :)
Если программировать для себя, то писать можно что угодно и как угодно, лишь бы самому нравилось. Однако, когда вы работаете с клиентом/руководителем время дорого и собственные хотелки уходят на второй план. Здесь просто быстрее (и, соответственно, дешевле) взять готовое и уже проверенное другими людьми решение. И дело тут не в лени, а в оптимизации труда (не путать с оптимизацией кода). Поэтому фреймворки и либы и пользуются популярностью.
Второй момент - работа в команде. Если вы используете либу, то куда выше вероятность, что ваш коллега быстрее разберется с вашим кодом, т.к. уже работал с этой либой на другом проекте. Если каждый будет писать велосипед, то начнется карнавал велосипедов, и в итоге проект захламлен, в такой проект куда сложнее и неприятнее вникать.
Отвечая на ваш вопрос: считаю, что с опытом как раз должно приходить умение и желание в первую очередь работать с готовыми решениями.
ну раз у вас jquery гораздо позже lodash и angular появляется, то опыт у вас должно быть так себе. Когда появился jquery, не было ни angular ни lodash ни node.
Тому шо изобретения велосипедов давно не в моде. Конечно можно строчить все что угодно на ваниле. А потом ты поймешь, что часто прибегаешь к одним и тем же функциями. И ты напишешь свою библиотеку.....
А меня недавно PHP просто жесть как выбесил.
1. wat????
$id = 'root'; // данное поле может содержать строку root или же число беззнаковое целое от
//нуля и выше(передается как тип string, для этого и нужно преобразование)
return (int)$id === 0;
Результат: true // потому-что строка без чисел при приведении к числу превращается в 0.
//Почему нельзя кидать исключение, я не понимаю
2. wat?????
function testFunc(string $var = '') {}
testFunc(123); // выполнится без ошибок, потому-что почему-то должны быть еще и какие-то
//флаги по поводу строгости проверки типов
Работаю с этим языком больше 2-х лет и он мне очень нравится и меня бесят индивиды, которые не видят явной проблемы и просто дрочат на свой любимый яп.
О какой динамической типизации идет речь в данных примерах? О том, что в функцию, которая явно запрашивает строку может попасть число? Это по вашему оправдание динамической типизации? А если я скажу, что могу поставить параметр строгой типизации (в сеттингах языка) в истину и все заработает, как надо, то что вы после этого скажете? Это неявное поведение, которое может привести в будущем к ошибке, которую сложно найти!
А в первом случае привидение строки к числу. Какая же это динамическая типизация? Это неявное поведение! Вот если бы при преобразовании строки без чисел к числу возвращало false, тогда можно было бы сослаться на динамическую типизацию и я был бы рад такому поведению функции, а тут просто "не баг, а фича."
Если вы знаете эти особенности языка, то почему просто не добавить проверку?
is_int
is_string
и т. д.
по первому примеру не могу понять почему вы приведение к int критикуете
вы приводили к int php и вернул int
Приведение строки, которая не содержит чисел к числу должно вернуть 0? По мне оно должно вернуть null, false или Exception.
Я сделал проверку is_numeric как писал ниже в соседней ветке, но такое поведение преобразования (имею ввиду (int)) меня очень не устраивает.
Пример:
$strWithNum = '0';
$strWithoutNum = 'string';
(int)$strWithNum; // 0
(int)$strWithoutNum; // 0
По вашему это нормально?
если бы делало Exception то " 5 "+4 вызывало бы Exception
ладно null или false ничего бы не сломали.
Но в php все преобразования
int
bool
float
object
string
выдают свой формат
например
(string) array(1,2,3) === 'array'
Нет, нет. Смотрите, если строка содержит числа, тогда я не против, пускай преобразовывает, но если в строке чисел нет, тогда не вижу смысла отдавать 0.
Конкретно к int я с вами согласен смысла нет.
но как я и писал выше
в php все приведения типов выдают то во что приводишь
если с этой точки смотреть то поведение вполне явное.
О какой динамической типизации идет речь в данных примерах? О том, что в функцию, которая явно запрашивает строку может попасть число?
Явно запрашивает строку ?! Серьезно ?! По-моему там идет установка значения по-умолчанию.
А если я скажу, что могу поставить параметр строгой типизации (в сеттингах языка) в истину и все заработает, как надо,
Что заработает как надо ? Возможность включения динамической типизации появилось только в 7 версии, до этого все работали нормально и учитывали динамическую типизацию языка.
Это неявное поведение, которое может привести в будущем к ошибке, которую сложно найти!
Это не неявное поведение, это динамическая типизация. Берите версию 7, объявляйте типы и не мучайте других своими надуманными проблемами. А если вам нужна проверка типа, то есть функции, is_int() например. Берите и пользуйтесь.
Вот если бы при преобразовании строки без чисел к числу возвращало false, тогда можно было бы сослаться на динамическую типизацию
А вот в PHP так. Почему false, почему не null ? Что вы будете делать с false при сложении строки и числа ?
Короче, не дурите голову, у вас какие-то, высосанные из пальца, проблемы.
Явно запрашивает строку ?! Серьезно ?! По-моему там идет установка значения по-умолчанию.
function testFunc(string $var = '') {}
Что обозначает слово string?
Что заработает как надо ? Возможность включения динамической типизации появилось только в 7 версии, до этого все работали нормально и учитывали динамическую типизацию языка.
declare(strict_types=1);
Выкинет исключение, если вы в функцию testFunc будете пытаться засунуть число. А это значит что поведение неявное и если я указываю, что там должна быть ебаная строка, то там должна быть ебаная строка всегда, иначе нахера об этом блять вообще писать? Мне и комментариев в таком случае хватит.
Это не неявное поведение, это динамическая типизация. Берите версию 7, объявляйте типы и не мучайте других своими надуманными проблемами. А если вам нужна проверка типа, то есть функции, is_int() например. Берите и пользуйтесь.
Я и работаю в 7 версии, что теперь?
А вот в PHP так. Почему false, почему не null ? Что вы будете делать с false при сложении строки и числа ?
Я не говнокодер и не буду складывать строку до тех пор, пока не буду знать что лежит в данной строке и пока не преобразую всё так, как надо.
Пардон, не заметил string в функции.
При установке PHP версии 7 режим строгой типизации включен по умолчанию, если вы свой код с обьвленной проверкой типов перенесете в 5.6, то он не будет работать, в чем проблема ?
Режим ебаной строки появидлся тольков 7 версии языка, раньше такого не было. Чувствуете ? Чувствуете, как вы несете хуету ?
Я не говнокодер и не буду складывать строку до тех пор, пока не буду знать что лежит в данной строке и пока не преобразую всё так, как надо.
В отличии от других языков с динамической типизацией, у PHP "+" используется для сложения чисел, а не строк, по этому если вы складываете число + строка, то происходит приведение типов. И что ж вы прикажете делать с false ? А с null ? Которые получатся, если последовать вашему совету ?
Причем тут версия 5.6 если я все примеры выполняю в 7 версии? Объявляю тип принимаемого значения как строку, передаю туда число и все выполняется без ошибок. Это нормально?
Я могу отловить исключение и обработать его, а могу взять значение и проверить его на null/false и обработать эту ситуацию, вам это так сложно?
Еще раз, для автора и особо тугих личностей:
var_dump((int)"qwe");
>> int(0) Всегда вернет инт, какой-бы скалярный тип туда не засунули. Логично ? Я думаю вполне. Схуяли, если следовать такой логике, должен возвращаться FALSE или NULL, нужно спросить у того, кто такое предлагает.
var_dump((bool)"qwe");
>> bool(true) Та же песня.
var_dump((string)"qwe");
>> string(3) "qwe" Не поверите.
var_dump((object)"qwe");
object(stdClass)#1 (1) {
["scalar"]=>
string(3) "qwe"
} Тут добавляется возможность работы с обьектами и массивами.
var_dump((array)"qwe");
array(1) {
[0]=>
string(3) "qwe"
} И тут.
Еще раз, адептам, с надуманными проблемами - учите мат часть и не выебывайтесь.
1. У тебя изначально строка не число. mb_strlen тебе в помощь. Это уже ошибка с твоей строны. Если у тебя строка, то и работой со строкой.
2. А что не так? PHP позволяет прозрачно преобразовывать в строку и обратно. 123 твои воспринялись как строка и все.
Ставь седьмой РНР, там уже построже с типами переменных.
1. Причем тут вообще длина строки? Вы пример смотрели хоть?
P.S. Я уже решил данную проблему через добавление условия is_numeric.
2. Эм, я явно указал в функции, что принимаю строку, такое возможно только с 7 версии, так-что это неоднозначное поведение, что он по умолчанию преобразовывает число в строку.
1. Тупанул. Все равно, ты работаешь с строкой, а потом вставляешь туда число. Так делать нельзя. У РНР типизация динамическая, надо помнить об этом. А чтобы косяков небыло, не используй переменную так как ты используешь.
Вообще объясни зачем ты так делаешь?
2. Повторюсь у РНР динамическая типизация. Надо помнить об этом и не будет проблем.
1. Сейчас посмотрел код проекта и понял что описывал немного не то.
В общем, когда ко мне обращаются в апи, чтобы люди не присылали невалидные идентификатор, а присылали только нужные числа.
Правила валидации данных ид у меня различаются для 0 и для всех других значений.
В связи с этим приходится брать параметр (строку из урл) и узнавать ноль это или нет.
Вот и представьте себе, как я беру параметр на преобразование и хочу узнать 0 это или нет, передаю туда строку и что я вижу? Всё хорошо говорит мне пхп, не фолс, не нулл, а число 0.
Как-то так. Описывать почему именно так очень долго)
2. Если я пишу, что мне в данном месте нужен массив и я передаю туда строку, тогда будет фатал эрор, так понятно? А почему если я пишу что там нужна строка и передаю туда число, то всё нормально? Это неявное поведение!
1. Не понимаю. id принимает числа или строки? Если строки, то зачем ты делаешь так (int) string === 0 ? Проще string === '0' же. Если id принимает числа. то зачем ты туда строку вставляешь? Если же идентификатор это число, то сделай root числов, к примеру 1.
В общем не понимаю. У тебя одна переменная то число то строка.
2. Да. В РНР число перевести в строку не сложно и обратное тоже(там по сути это и так одно и тоже). Поэтому забили хер на такое. Надо помнить и не допускать таких ситуаций.
Не понимаю. id принимает числа или строки?
GET api/v1/0/categories
GET api/v1/1/categories
GET api/v1/test/categories
$id является первым аргументом // 0,1,test
Должен быть числом, но некоторые могут прислать строку и я должен на это сделать соответствующую реакцию.
Если строки, то зачем ты делаешь так (int) string === 0 ? Проще string === '0' же.
Да, вы правы и так можно сделать, но я хочу сделать по человечески и приводить числа к числам.
Если id должно быть числом, то работай как с числом, делай проверку на строку и вызывай ексепшен. Для этого юзай is_string.
чувак, в php 7 добавили type hints
так что твой пример просто вброс. И если ты реально написал код в примере 1, то у меня плохие для тебя новости...
Какие же новости? Я пишу на PHP ежедневно. Пользуюсь только версиями 7.0 и 5.6. Расскажи мне чего я не знаю.
$str1 = '0';
$str2 = 'is string';
(int)$str1; // 0
(int)$str2; // 0
//$str1 === 0;
//$str2 === 0;
Научился слову вброс, но не знаешь как его использовать.
С твоим примером на 7ке выдает "Fatal error</b>: Uncaught TypeError: Argument 1 passed to testFunc() must be of the type string". Так что да - вброс
отъебись, а
http://sandbox.onlinephpfunctions.com/code/f2df1c062196c7919...
Ты блять говоришь про первый пример и приводишь мне аргументы про второй, ну ахуеть ты умный.
За тупость свою сиди в игноре.
а я себе и не стреляю в ногу. с чего вы взяли? просто использую языки с динамической типизацией в которых нет неявного приведения типов.
и минусы какие странные. как будто я на больную мозоль наступил. если задел, то извините. думал использование яп на которым выстрелить в ногу ещё проще на с++ закаляет характер а не расшатывает нервы.
Думаю, минуса потому, что многие восприняли сарказм в вашем комментарий как: "Да ладно, кто в своём уме будет писать на js, если в нём вот такая фигня творится?"
В то же время приведённые "проблемы" являются примерами сферического быдлокода в вакууме. Если программист пытается "сложить" заведомо разнотипные переменные, полагаясь на неявные преобразования и при этом рассчитывает на какой-то вменяемый и стабильный результат, то это повод усомниться в его квалификации, с каким бы языком программирования он ни работал. Если же типы переменных заранее неизвестны, то любой адекватный разработчик прежде, чем проводить с ними какие-то действия, предварительно проводит их проверку и/или приведение к нужному ему типу.
Ps Но это не относится к ССЗБ и которые так пишут.
Спроси у разработчиков всяких фреймворков. Они более грамотно расскажут.
Меня больше бесит конкатенация строк. Ну почему надо было брать "+" для этого?
Вот в PHP это . и проблем нет.
Мало пишу JS, не могу четко сформулировать все претензии.
Как вы программируете когда у вас "не всегда понятно что в переменной"?
Это как доктор делающий операцию "не всегда знающий какая болезнь у пациента".
Это как автомобилист заливающий в бак "не всегда понятно что".
Это как девушка кладущая в рот "не всегда понятно что".
Можно продолжить список...
Значит:
У вас есть проблемы с именованием (семантикой);
У вас нет нормальной IDE;
У языка есть неявное приведение типа и отсутствие прямого декларирования типа переменной (да, это про JS).
Третья проблема делает первую ещё острее.
И если у вас всё равно возникают проблемы, вам следует приводить типы руками.
Если не уверены, что лежит в переменной, то программист из вас не очень вас может спасти приведение типов.
Да это понятно. Но все равно, выбрать + в качестве знака конкатенации это было плохое решение.
Это широко распространённое решение, используемое в том числе в таких языках как c++, java, python, ruby, go, pascal - это из тех, что вспомнились. У конкатенации через точку в php ноги растут из perl'а, больше нигде такого не припомню.
Ой, а в js если это плавает как утка и крякает как утка то это утка, то кому какая разница что на самом деле это бобер, не так?
Поэтому читать такие посты, где js изображают эдаким шитым уродцем, мне довольно забавно. Скорее, они отражают не синтаксис и функциональность языка, а компетентность автора этих комиксов.