Comments 22
Для языков с динамической типизацией естественно надо приводить типы, если они не совместимы, я склоняюсь больше к PHP/JS подходу, потому что чаще приходится сравнивать числа, а не строки, для приоритетного сравнения строк необходим метод. Опять же не помешает оператор === из PHP, хоть он и не требуется постоянно, но временами очень даже помогает, ну и опять же ручной контроль над типами, возможность принудительно сменить тип, чтобы заставить работать сравнение как надо.
Мне любопытно, а часто на боевых системах используются такие вот сравнения? Насколько важно иметь настолько проработанный алгоритм что сообщество на этом реально заморачивается?
Например при программировании в вебе все введённые пользователем в форму данные передаются как текст, в том числе и дату рождения, количество детей, ФИО, номер паспорта,…
А при валидации, уверен, будут сравниваться эти значения не с текстовыми данными.
Можно, конечно, это всё руками приводить к нужным типам. Но, безусловно, если сам язык способен правильно это делать — намного удобнее работать получается.
А при валидации, уверен, будут сравниваться эти значения не с текстовыми данными.
Можно, конечно, это всё руками приводить к нужным типам. Но, безусловно, если сам язык способен правильно это делать — намного удобнее работать получается.
На боевых машинах это сплошь и рядом, самая распространенная ошибка в коде на PHP, с которой мне приходится сталкиваться в каждом практически проекте, это сравнение с null вида
if($a != null) вместо if($a !== null).Если бы в JS сравнение
null < 1
вернуло бы FALSE, то я бы считал его в данном вопросе идеальным — я нередко сталкиваюсь с необходимостью написания кучи лишнего кода из-за того, что null воспринимается довольно часто как 0.
в JS? например:
null == null // --> true
мне это слишком непривычно. По-началу часто на это наталкивался. Сейчас уже как-то свыкся, но считаю такое поведение крайне неверным.
считаю, что если один из сравниваемых элементы — число, а другой — можно к числу привести (НО НЕ NULL!!!) — то необходимо их сравнивать как числа. И поведение PHP, в данном случае, меня не устраивает — как я понимаю, он всё приводит в таких ситуациях к строковому виду.
null < 1
вернуло бы FALSE, то я бы считал его в данном вопросе идеальным — я нередко сталкиваюсь с необходимостью написания кучи лишнего кода из-за того, что null воспринимается довольно часто как 0.
в JS? например:
null == null // --> true
мне это слишком непривычно. По-началу часто на это наталкивался. Сейчас уже как-то свыкся, но считаю такое поведение крайне неверным.
считаю, что если один из сравниваемых элементы — число, а другой — можно к числу привести (НО НЕ NULL!!!) — то необходимо их сравнивать как числа. И поведение PHP, в данном случае, меня не устраивает — как я понимаю, он всё приводит в таких ситуациях к строковому виду.
PHP приводит к числу, если один из аргументов число, т.е. PHP и JS ведут себя одинаково, разница в том, как PHP и JS к числу приводят строки.
Поставил еще галочку в пользу числового сравнения. А что с null не так, вам хотелось бы, что бы в JS null и undefined вели себя одинаково? или что, объясните вашу точку зрения подробнее
Работая с БД я привык, что NULL — это не известно что.
Соответственно, — да, я хлтел бы, чтобы JS к null при сравнении относился бы так же как к undefined;
Соответственно, — да, я хлтел бы, чтобы JS к null при сравнении относился бы так же как к undefined;
Я постоянно сталкиваюсь с программистами, которые если не в бешенстве от того, что в JS есть null & undefined, то по крайнем мере в большой растерянности и толком не понимают, когда использовать null, а когда undefined. В OS я решил избавится от такой неопределенности и оставить null, но все равно остается вопрос, какое поведение трактовать при сравнении с null, как конвертировать null в число. Примеры диаметрально разного подхода в этом направлении хорошо видны в PHP и JS.
Мне нравится позиция Lua.
Еще мне более важным видится вопрос, что считать за false. Все пустое, как в питоне, или же только ложь и nil, как в руби?
Еще мне более важным видится вопрос, что считать за false. Все пустое, как в питоне, или же только ложь и nil, как в руби?
Я извиняюсь, а в чём смысл этого языка? Да, я читал предыдущие статьи (ну, глазами пробежался), но не нашёл ничего, что решало бы проблемы того же JS, вводило дополнительные мощные фичи или хотя бы упрощало восприятие кода. Так в чём тогда посыл языка?
Я это к чему. Вы не выделяете важных концепций, а просто комбинируете фичи других языков (причём не самых лучших). В Python, например, делают упор на читабельность кода (ну и другие пункты «Дзена»), в Scala — на гибкость языка (среди прочего), в Haskell — на чистоту функций, в OCaml — на надёжность и т.д. И в каждом из этих языков решение о приведении типов принимается на основе этих концепций: Scala позволяет задавать свои implicit conversations, а OCaml запрещает даже скаладывать int и double. А вы в данном случае выбираете, чем вам есть — ложкой или вилкой — при этом ещё не определившись, что именно вы будете готовить.
Я это к чему. Вы не выделяете важных концепций, а просто комбинируете фичи других языков (причём не самых лучших). В Python, например, делают упор на читабельность кода (ну и другие пункты «Дзена»), в Scala — на гибкость языка (среди прочего), в Haskell — на чистоту функций, в OCaml — на надёжность и т.д. И в каждом из этих языков решение о приведении типов принимается на основе этих концепций: Scala позволяет задавать свои implicit conversations, а OCaml запрещает даже скаладывать int и double. А вы в данном случае выбираете, чем вам есть — ложкой или вилкой — при этом ещё не определившись, что именно вы будете готовить.
Сейчас модно делать языки компилируемые в JS: TypeScript, ObjectScript, Dart, CoffeScript и так далее.
Дело не в том, что модно, дело в том, что JavaScript начинют использовать в приложениях, для которых этот язык не был предназначен. Изначальное JS нужен был для написания небольших простых функций, проверяющих поля на заполнение, показывающих алерт и т.д. Сейчас же на нём пишут огромные приложения, генерируют отображение, используют даже там, где можно было бы обойтись простым HTML 4. У нас тут недавно случился локальный пиз*дец: провайдер с какого-то перепугу начал резать все скрипты на всех страницах. Так дошло до того, что даже в гугле страницы не открываются, потому что то, что на странице поиска выглядит как ссылка, на самом деле вызывает скрипт редиректа.
В итоге повылазила куча недостатков JavaScript-а, таких как отсутствие модульности, пляски с Context, undefined, запись в глобальные переменные и пр. Языки такие как Dart борятся с этими недостатками, и это большой плюс. Но если новый язык тупо меняет синтаксис, то толку с этого ноль.
В итоге повылазила куча недостатков JavaScript-а, таких как отсутствие модульности, пляски с Context, undefined, запись в глобальные переменные и пр. Языки такие как Dart борятся с этими недостатками, и это большой плюс. Но если новый язык тупо меняет синтаксис, то толку с этого ноль.
Здесь все просто. OS нацелен на решение следующих задач: скриптование игровой и программной логики, кросс платформенные приложения, веб и серверные технологии. Т.е. все то же что сейчас делают как минимум 3 разных языка: JS, PHP и Lua, но делать это с человеческим ООП и реально нужными программисту возможностями. Изначально язык решил сделать для себя для разработки игр под мобильники, чтобы использовать легкий JS но с ООП. Начал делать язык как раз после изучения Dart и Go (т.е. совсем новых и как бы «передовых» направлений) и осознания того, что это совсем не то, что реально нужно программисту. Сейчас OS из себя представляет мое видение того, как должен был бы выглядеть JS.
Ну ок, Java-подобное ООП хотите, это понятно. А что за «реально нужные программисту возможности»? Я ещё раз говорю: приведение типов — это следствие, а не причина. Сначала определите основные характеристики языка, который хотите получить, а потом уже в зависимости от этих характеристик решайте, что делать с приведением типов.
Характеристики — универсальный язык программирования для задач, которые я описал чуть выше. Но практика др. скриптовых языков показывает, что операторы сравнения ведут себе везде по разному, хотя цели примерно одинаковые. Поэтому и возник вопрос, какое поведение самое удачное.
На данный момент я определился с тем, что если один из аргументов — это число, но наиболее правильно делать численное сравнение, т.е. преобразовывать др. аргумент в число.
Осталось решить два вопроса:
1. как преобразовывать в число null, варианты: 0 или NaN
2. как преобразовывать в число string с невалидными символами, варианты: 0 или NaN
P.S. напомню, математические операции с NaN всегда дают NaN на выходе, а любое сравнение с NaN всегда дает false
На данный момент я определился с тем, что если один из аргументов — это число, но наиболее правильно делать численное сравнение, т.е. преобразовывать др. аргумент в число.
Осталось решить два вопроса:
1. как преобразовывать в число null, варианты: 0 или NaN
2. как преобразовывать в число string с невалидными символами, варианты: 0 или NaN
P.S. напомню, математические операции с NaN всегда дают NaN на выходе, а любое сравнение с NaN всегда дает false
Ок, я промолчу про то, что «универсальный язык» и «для задач, которые я описал выше» — понятия несовместимые. Но вы правда не понимаете разницу между целью языка и характеристиками языка? Простейший вопрос: типизация у вас в языке строгая или слабая? Если строгая, то идти по пути Lua и запрещать неявные преобразования при сравнениях. Если слабая, то идти по пути JavaScript и разрешать неявное приведение типов не только в операторах сравнения, но и везде, где это требуется. Если хочется совсем распутного программирования, то идти по пути PHP и позволять даже конвертации из строки в число. А так вы продолжаете есть суп вилкой.
Ок, спасибо за коменты и ваше мнение, каждый отзыв нашел свое место и отложился в моем сознании. В работу операторов сравнения будут внесены изменения в ближайшем обновлении.
Sign up to leave a comment.
ObjectScript, разработаем спецификацию совместно: операторы сравнения