Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Нда, с дизайном языка явно что-то не так, если можно спокойно компилировать присвоение строки (в данном случае супер-объекта) в переменную, объявленную как int.
Дело в том, что int у них всегда объект, у них нет примитивов (если я не ошибаюсь).
Т.е. ему, как и любому классу можно добажить методы, свойства и т.д.
Любимый пример Groovy DSL:
5.euro + 4.dollars
Т.е. ему, как и любому классу можно добажить методы, свойства и т.д.
Любимый пример Groovy DSL:
5.euro + 4.dollars
Пусть объект, но это не отменяет того факта, что я могу присвоить int-переменной любое значение. То есть выходит, что:
int a
def a
C чего вы взяли, что int переменной можно присвоить любое значение?
Groovy Shell (1.8.6, JVM: 1.6.0_23)
Type 'help' or '\h' for help.
----------------------------------------------------------------------------
groovy:000> int a = "asdasd";
ERROR org.codehaus.groovy.runtime.typehandling.GroovyCastException:
Cannot cast object 'asdasd' with class 'java.lang.String' to class 'int'
at groovysh_evaluate.run (groovysh_evaluate:2)Ну как, вон в статье самый первый пример. Который компилируется без проблем.
Возможно на groovy 2.0 это работает иначе, но на 1.8.6 у меня не компилируется.
Не компилируется или падает в рантайме (то, что Вы показали)?
Извиняюсь, я был немного не прав. Компилируется, но падает в рантайме :(
А какая разница? Присвоить вы всё равно не можете. Разница только когда и где вам об этом сообщают.
Разница огромная — об ошибке я узнаю на этапе компиляции, или когда оно свалится у клиента
это не отменяет того факта, что я могу присвоить int-переменной любое значение.
Нет такого факта. Есть факт, что подобная ошибка может выявиться на более раннем этапе в языках с сильной или строгой статической типизацией. А в языках со слабой типизацией, пускай и со статической, это вообще не ошибка, а фича, даже выявляться нечему.
Нет такого факта. Есть факт, что подобная ошибка может выявиться на более раннем этапе в языках с сильной или строгой статической типизацией. А в языках со слабой типизацией, пускай и со статической, это вообще не ошибка, а фича, даже выявляться нечему.
Согласен, немного неправильно выразился. Это не отменяет того факта, что транслятор разрешает мне присвоить int-переменной любое значение.
Если транслятор языка с сильной типизацией не выявляет таких явных ошибок на этапе компиляции, то это недостаток транслятора, а не дизайна языка. В языках с динамической типизацией в общем случае нельзя узнать типы операндов не выполняя всей программы и транслятор этим заниматься не обязан. То есть в данном случае можно было бы сказать «в используемом трансляторе нет (опционального!) статического анализа кода на возможные ошибки типизации». Язык от этого ни лучше, ни хуже не становится.
Более того, если бы такая опция была, то где этому анализу останавливаться? Проверять только присваивания констант переменной? Константных выражений? Выражений, тип которых выводится за одну итерацию анализа типов переменных в выражении? За 100? Обходить ли все возможные ветвления и выдавать ошибку если есть она хотя бы в одной ветви? Игнорировать ли заведомо мёртвый код? А что считать заведомостью? Делать ли какие-то «предположения» о возвращаемых функциями/методами типах или их тоже анализировать? А если в языке есть средства метапрограммирования (изменения приложением собственного кода), то может это вовсе и не ошибка, а «задумка режиссёра» при реализации, например, защиты от копирования?
Вот сколько навскидку вопросов может поставить методический подход к желанию чтобы транслятор обнаруживал ошибку по сути рантайма (т. к. язык динамический) в выражении
Более того, если бы такая опция была, то где этому анализу останавливаться? Проверять только присваивания констант переменной? Константных выражений? Выражений, тип которых выводится за одну итерацию анализа типов переменных в выражении? За 100? Обходить ли все возможные ветвления и выдавать ошибку если есть она хотя бы в одной ветви? Игнорировать ли заведомо мёртвый код? А что считать заведомостью? Делать ли какие-то «предположения» о возвращаемых функциями/методами типах или их тоже анализировать? А если в языке есть средства метапрограммирования (изменения приложением собственного кода), то может это вовсе и не ошибка, а «задумка режиссёра» при реализации, например, защиты от копирования?
Вот сколько навскидку вопросов может поставить методический подход к желанию чтобы транслятор обнаруживал ошибку по сути рантайма (т. к. язык динамический) в выражении
int a = "a" А стоит ли овчинка выделки? Есть ли смысл делать такую сложную опцию в трансляторе или может лучше сделать вместо неё какую оптимизацию результата компиляции или самого процесса? А если вам нужна такая проверка, то, повторюсь, вероятно вы не тот инструмент выбрали.На этапе компиляции пропускает, в рантайме падает.
Я вот думаю — может оно его пропускает потому что можно как то к int добавить правила кастинга? Но я про такой фичер не знаю…
Да… озадачили Вы меня :)
Я вот думаю — может оно его пропускает потому что можно как то к int добавить правила кастинга? Но я про такой фичер не знаю…
Да… озадачили Вы меня :)
Вот такие моменты я ненавижу, когда ещё на этапе компиляции можно отловить потенциальную ошибку, но этого не происходит. Там хоть warning какой-нить выбрасывается?
Пост как раз про то, как избавиться от подобных проблем.
Это понятно, мне не понятно, почему нужно ставить аннотацию, чтоб компилятор показал эту ошибку. Если я вдруг забуду поставить аннотацию, такое свободно уедет в продакшн.
Я не отрицаю, возможно это фича языка, но пока никто не объяснил, что это за фича и насколько она полезна по сравнению с потенциальными ошибками.
Я не отрицаю, возможно это фича языка, но пока никто не объяснил, что это за фича и насколько она полезна по сравнению с потенциальными ошибками.
Фича простая — определение типа выражения динамическое, в рантайме. Это фича всех (известных мне) языков с динамической типизацией, собственно в этом (почти) динамическая типизация и заключается.
Возможно это просто не мой стиль. Мне понятны либо строгая типизация переменных(java, scala...), либо полное её отсутствие (javascript, lua, python...). Такое смешение сбивает с толку, как минимум меня. Хотя это дело привычки, скорее всего.
Python считается как раз языком со строгой типизацией, динамической, но строгой — нет (почти) неявных приведений типов, выражение типа
1 + "1" выдаст ошибку «unsupported operand type(s) for +: 'int' and 'str'» в рантайме. Ошибка по сути та же самая, что выдаст Groovy в случае int a = "a", просто Python изменяет тип левого операнда в присваивании, а Groovy не может, пытается изменить только значение.Дело в том, что int у них всегда объект, у них нет примитивов (если я не ошибаюсь).
Т.е. ему, как и любому классу можно добажить методы, свойства и т.д.
Любимый пример Groovy DSL:
Т.е. ему, как и любому классу можно добажить методы, свойства и т.д.
Любимый пример Groovy DSL:
5.euro + 4.dollars
То есть Idea пока не подсвечивает косяки on-fly? Подождем…
Ваша формулировка аля «улучшенная джава» – это спорно мягко говоря. Groovy – динамический язык, как вы его не маринуйте со всеми Java 7 и invokedynamic, всё равно удар по производительности неизбежен, а вы говорите «улучшенная» – в итоге всё равно возвращаетесь к тому, что хотите type safety.
Короче говоря Scala вам в руки, а Groovy – это так, игрушки.
Короче говоря Scala вам в руки, а Groovy – это так, игрушки.
В свое время вот эта статья от создателя Groovy решила мой вопрос Scala vs Groovy.
Цитата оттуда же:
I'm very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.
Цитата оттуда же:
I'm very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.
Меня привлекает в Груви, что не надо учить совершенно новый синтакс
хыхы, это эпик фейл сделать такое признание :)
Ну нужно заметить что автор сказал что «ему не пришло бы в голову начать», а не то что оно лучше. Ну и во-вторых он конечно один из основавших, есть в списке фаундеров, но вот найти код который он написал не получается, или утерян или я не знаю. На гитхабе он и не форкнул свое детище даже. А в третих, он уже в Kotlin коммитит :)
А по-моему, наоборот, хорошо, что чувак может признавать свои ошибки и не закрывать глаза на чужие успехи.
Мне он наоборот после этого признания как-то симпатичнее, как человек и инженер стал.
Мне он наоборот после этого признания как-то симпатичнее, как человек и инженер стал.
Самая большая проблема Groovy — IDE. Пока не будет нормальной поддержки автодополнения/дебага/подсветки, массы не перейдут к сожалению :(
IDEA отлично делает автодополнение, дебаг и подсветку. В своей бесплатной версии. Эклипс, кажется, тоже
а вот и нифига. Самый последний greclipse является сплошной головной болью. Автодополнение не работает в динамических типах(и не только). Дебаг работает дико и с ошибками. Я уже на говорю о conditional breakpoints и прочих плюшках.
В конце концов сильный и гибкий язык не получает распространения из-за проблем среды разработки.
В конце концов сильный и гибкий язык не получает распространения из-за проблем среды разработки.
Вот, прям щас ретвитнул:
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Groovy как лучшая Java