Смотрю Groovy. Волосы встают дыбом. Как же разработку такого кода держать в таких рамках, чтобы приложение работало.
Например




То есть мы просто что-то, что по нашему замыслу должно быть коллекцией, назвали def collection.
А если другой программист туда передаст int? Или он должен догадаться по названию?
Я мог бы назвать параметр например def vasya. И как тогда должен пользователь метода догадываться,что именно передавать как параметр.

Кстати, если я делаю def list = new ModifyList(3), то ничего не падает.
Спокойно отрабатывается код и печатает []
Если такое будет внутри сложной системы, то как же отловить такую ошибку?
Получается, что например я написал код и назвал параметр collection, а другой член команды
должен был по названию догадаться, что это коллекция и передавать туда именно ее, а не int.
Но если он не догадается об этом или случайно передаст туда int, то билд все равно соберется и будет тихо работать неправильно.
Никаких сообщений об ошибке не будет даже в runtime. Будет падать где-то дальше, где ожидается например непустой List, а приходит пустой.
Но понять почему падает будет сложно.


Далее


.
Тут я передаю closure в метод, а в методе уже происходит




То есть closure должен знать как обработать каждый элемент из этого this[i].
Если я выполняю умножение в этом closure, то я предполагаю, что там цифры.
То есть я должен передать известные мне аргументы, и передать что с ними делать
Например тут я передаю closure, который выполняет над String то что есть для String - конкатенацию.



А тут я вызываю в closure то, что можно сделать с int - ну и передаю соответственно int.




Тут вроде я контролирую ситуацию.
Но при этом я должен знать, что будет делать метод modify(closure) в классе ModifyList с этим closure? То есть я должен знать внутреннее устройство метода прежде чем передать туда closure? И общая функциональность получается в результате сложения функциональности метода и функциональности передаваемого closure,
Как тут контролировать это смешение моего кода в closure, который я передаю в метод, и собственно кода в самом методе?
Хорошо если код в методе просто пробегает коллекцию и делает манипуляции, задаваемые closure, над каждым элементом.
Но наверное ж это просто частный случай?

В чем тут философия? Как это понимать?

А что значит в последней версии она есть? Ее ж вроде всегда можно было использовать? Или есть какой то механизм, чтобы team lead например разрешил только строгую типизацию?

Ну а как управлять проектом, где каждый может написать def vasya? Получается что все должны быть в команде
гипер-профессионалы и очень наблюдательные. Компилятор и IDE тут не поможет же.
Вот и соберется себе билд спокойно, но работать не будет и ошибки будет кидать далеко в другом месте от того, где кто-то кто не выспался в тот день в этот метод вместо коллекции передавал просто int.
Как же с этим бороться? Или это язык для тех кто пишет в одиночку и знает, для чего он ввел этот параметр def value и что он там дальше с ним делает.

Petro123я за строгую типизацию. При любой ошибке и полном ребилде, компилятор поймает любую (почти ))) ) ошибку.
Эта ситуация напоминает JS в "обозревателях интернета". Поэтому пром.системы на нём не пишут.

В одном из топиков человек написал что именно банковские системы и строятся на Grails. Вот и пойми. Тут видимо только супер профессионалы должны работать.

По поводу http://groovy.codehaus.org/gapi/groovy/transform/CompileStatic.html
Это видимо в последней версии? Должен и последний Grails быть уже на этой версии Groovy?