elizarov


Блог Романа Елизарова


Previous Entry Share Next Entry
По следам JavaOne: Что ждать от Java 7 (Часть 3: Pluggable Type Systems)
elizarov
В докладе про Upcoming Java Programming-Language Changes есть упоминание про JSR 308: Annotations on Java Types. Вкратце, идея состоит в том, чтобы разрешить указывать аннотации во всех местах Java кода где есть упоминание типа данных (включая определения локальных переменных, фактические и формальные параметры типов, операторы приведения типов и т.п.). Это позволяет создавать свои собственные системы типов путем расширения существующих типов данных аннотациями. Вместе со специализированной версий компилятора javac, реализующего эти расширения, авторы JSR 308 предлагают т.н. "checkers framework", позволяющий писать дополнения к компилятору для проверки ваших собственных аннотаций. Предлагаются готовые решения для проверки кода на предмет соответствия Nullable/NonNull, Readonly/Mutable/..., Interned. То есть, операция @NonNull String s = compute() будет приводить к ошибке компиляции, если тип результата метода compute не аннотирован как @NonNull.

Использование этого механизма ограничено лишь вашей фантазией и требованиями создаваемых вами приложений. Предположим что вы пишете код, который рассчитывает расстояния, скорости, времена и т.п., храня их в переменных типа double. Код сложный для отладки и вы рискуете запутаться в единицах изменениях. Вам нужны гарантии, что километры не складываются с секундами и т.п.. Вы можете создать подходящую систему типов, проаннотировать все ваши double переменные, и написать checker, чтобы убедиться в корректности вашей программы. Можно добиться того, что при наличии в вашей программе @Kilometers double a и @Seconds double b, выражение a + b давало бы ошибку компиляции.

Если вам приходится использовать Венгерскую нотацию для того, чтобы отличать типы данных вашего приложения, как это, например, описал Джоел Сполски на примере безопасных и небезопасных строк в Web приложениях, то теперь у вас появляется возможность переложить еще один кусочек работы по проверке вашего кода на компилятор, введя систему типов для вашего конкретного приложения.

Концептуальная сторона такого подхода к разработке приложений и языков описана в замечательной работе Pluggable Type Systems, автором которой является Gilad Bracha. Для общего ознакомления можно посмотреть его слайды. Рассматривая достоинства и недостатки языков со строгой типизацией по сравнению с динамическими языками, он призывает к созданию языков, семантика выполнения которых не зависит ни от какой системы типов, но позволяющих подключать любые системы типов, которые нужны программисту в той или иной предметной области.
Tags:

  • 1
аннотации - самое полезное что было введено в Java с момента её появления, без всего остального прожить было бы беспроблемно.. но похоже креатив прет и они перегнут палку, не стоит заботиться о разработчиках настолько, что не давать им возможность на ошибку..

Это не способ не дать разработчикам допустить ошибку, и его нельзя использовать в действительно security-sensitive местах (так как его можно обойти). Это способ для тех, что использует инструменты типа инспекций в IntelliJ IDEA, FindBugs или jlint для поиска потенциальных ошибок в коде и хочет находить таким образом еще большее число ошибок.

Более того, механизм pluggable types полностью опционален, то есть, если не хочешь или не нужно, то и не используй. Так же как и аннотации, он не добавляет нагрузку тем, кто их не использует, но расширяет возможности там, где это действительно необходимо.

Спасибо за информациюю. Ужас кошмарный, на самом деле. Семантическая польза имеется, но синтаксис приводит в ужас. Лучше бы сделали простейший typedef, было бы гораздо больше пользы imho. @Kilometers double? Лучше просто kilometers. @NonNull Map<@NonNull String, @Nullable ? extends PropertyValue>? Лучше просто PropertyMap.

Очень рекомендую прочитать статью Gilad-а... Реально Pluggable Type Systems заработают в полную силу только когда программисты откажутся от ascii-based редакторов. Если семантика языка не зависит от типов (в Java она зависит от типов, но не зависит от аннотаций), то по умолчанию IDE не должен показывать типы (аннотации) вообще. Более того, большая часть типов (аннотаций) должна выводиться автоматически через type-inferrence. В отличие от языков типа Haskell, этот type-inferrence будет опциональным и не будет накладывать ограничение на сложность системы типов (для многих интересных систем типов доказана неразрешимость задачи о type-inferrence).

Программист смотрит и работает только с семантической частью кода ("что код делает?"), а к типам (аннотациям) обращается только по необходимости и только чтобы посмотреть на интересующий его в данный момент аспект кода (может ли эта переменная быть null? может ли меняться? какими локами защищена? какая физическая размерность у чисел типа double? и т.п.).

Статью прочитал. (И что?)
Отказ от текста это очень философский вопрос, я полагаю. Разве в ближайшем будущем можно ожидать мэйнстримовый переход на другое представление кода? Мне ведь чисто с практической точки зрения интересно. Джава и так синтаксически пышная, и чем дальше тем больше. Длинные конструкции меня, как Винни-Пуха, расстраивают.

Но вот например если Идея будет как-то схлопывать аннотации, уже будет лучше.


Но вот например если Идея будет как-то схлопывать аннотации, уже будет лучше.
Во! Я думаю, we are almost there. Так что конкретный синтаксис не супер важен. При правильном использовании и в обычном текстовом редакторе можно будет во всем разобраться.


только когда программисты откажутся от ascii-based редакторов.
Никогда не откажутся, IMHO. Потому что возможность что-то быстро поправить тем, что есть под руку (вплоть до vi over satellite link with 2s latency) важна гораздо бОльшему числу людей, чем кажется на первый взгляд.

И ещё одна урезанная версия contract programming...

Использование этого механизма ограничено лишь вашей фантазией и требованиями создаваемых вами приложений.

Основная проблема - ограничение полёта идиотизма.

PS: Кста, долго думал, где последний раз видел closures, оказалось Perl.

И ещё одна урезанная версия contract programming...

Наоборот, расширенная версия! С помощью аннотаций и pluggable types можно [по определению] сделать contract programming по любой системе, смоделировав любой другой contract programming язык (или все их одновременно в одном куске кода). И в дополнение к этому намного больше других вещей, недоступных contract programming языкам. Например, приведенные мной контроль за единицами измерений и за безопасными/небезопасными строками.

Наоборот, расширенная версия!

"Вы знаете, что бывает, когда водитель трамваев начинает искать новых путей" (С)


А вы водитель трамвая??? :) Для водителей трамвая открою секрет, программизм значительно(!!!) более гибкое ремесло. Так что меняйте професию ;)

  • 1
?

Log in

No account? Create an account