— В замыкании мы же должны использовать какую-либо переменную, объявленную вне этого замыкания.
Сошлитесь на источник, пожалуйста. Я не понимаю такого требования.
Провожу аналогию с groovy.codehaus.org/JN2515-Closures: кажется все нормально
Для себя на данный момент одним из преимуществ я вижу то, что Groovy работает в JVM (о чем было упомянуто в начале поста). По поводу производительности сложно сказать, но по моему мнению, тенденция сводится к тому, что приложения на groovy будут быстрее. Хорошей практикой является написание «критичных», в аспекте производительности частей, на Java. И, конечно, ожидаемый всеми Project Coin для JVM, который должен дать скорость динамическим языкам в jvm, сравнительную с Java.
getStaffWithCriteria — несомненно метод. И все же я настаиваю на том, что конструкция, передаваемая в качастве второго параметра этому методу — ничто иное как замыкание (closure).
Можете посмотреть на www.grails.org/Success+Stories
Еще слышал про SAP, они строят на его основе свое решение wiki.sdn.sap.com/wiki/display/Community/Composition+On+Grails.
Вообще, нравится, что он развивается довольно стремительно и уже не сравним со своими старые версиями. Очень жду, когда они пересядут на Gradle, тогда с адаптацией мультимодульных проектов будет значительно проще.
Сошлитесь на источник, пожалуйста. Я не понимаю такого требования.
Провожу аналогию с groovy.codehaus.org/JN2515-Closures: кажется все нормально
for(e in staff)чем тут «e» не переменная вне замыкания?getStaffWithCriteria— несомненно метод. И все же я настаиваю на том, что конструкция, передаваемая в качастве второго параметра этому методу — ничто иное как замыкание (closure).Еще слышал про SAP, они строят на его основе свое решение wiki.sdn.sap.com/wiki/display/Community/Composition+On+Grails.
Вообще, нравится, что он развивается довольно стремительно и уже не сравним со своими старые версиями. Очень жду, когда они пересядут на Gradle, тогда с адаптацией мультимодульных проектов будет значительно проще.