Questions tagged «groovy»

Groovy是一种基于Java的“下一代”编程语言,旨在改进Java,同时增加Smalltalk,Python和Ruby的流行功能。Groovy语法是Java的超集,它使Java开发人员可以在学习Groovy时开始使用Groovy进行编码。Groovy是完全面向对象的,动态的,并且与Java无缝集成。从市场角度来看,Groovy的成功是所有人的猜测。主要竞争对手是Ruby,Scala和Closure。


5
Groovy会消失吗?[关闭]
我相信这个问题已经被问过很多次了。但是,我想再次问一下这些语言的未来。 我最初被介绍给Groovy,并真的很喜欢它。我觉得语法更简单,并且更接近Java,并且能够快速学习Grails。 然后是Scala,并且网络框架工作为Lift。我仍在学习Scala,有时发现语法很困难。 但是,我仍然想知道Groovy的未来是什么。当Groovy的作者说如果他对Scala 有所了解,他永远也不会创造出Groovy,那让我想知道是否还有未来。当然,Groovy已经走了很长一段路,如今许多大公司都在使用Grails。 如果今天要看Grails vs Lift,那么Grails无疑是赢家。更多的公司正在使用它。但是,鉴于到目前为止我所说的一切,我很想知道是否应该投资Groovy?Groovy离开了,Scala是更好的选择吗?如果宝马首席执行官说他驾驶梅赛德斯,那么人们会想知道我们为什么不也都驾驶梅赛德斯吧? (我知道这个问题是否真的很广泛并且可能是封闭的。但是我希望将其设为对其他人开放的Wiki。)
30 java  scala  groovy  grails 

2
什么时候在Groovy中使用def?
我现在在Groovy中开发了一段时间,我想知道应该多久使用一次动态投射def?我的一位同事认为我们应该一直使用它,因为它以某种我不了解的方式对Groovy有所帮助。 当前,当声明方法的返回类型和参数时,我想刻意指出应该放入和吐出哪些对象(出于代码可读性,我来自Java背景对我来说很有意义)示例: String doSomething(String something){ //code } // vs def doSomething(def somthing){ //code } // vs def doSomething(somthing){ // code } 所以我想我的问题是,仅是何时使用的偏好,def还是一直使用它的真正优势?(我添加了最后一个示例,因为我认为它适合作为Groovy的可行选项的问题)

3
什么时候在Groovy中编写显式的return语句?
目前,我正在研究Groovy / Grails项目(这是我的新手),我想知道return在Groovy方法中省略关键字是否是一种好习惯。据我所知,您必须显式插入关键字(即用于保护子句),那么在其他地方也应该使用该关键字吗?在我看来,附加return关键字可提高可读性。还是只需要习惯一下?您对该主题有何经验? 一些例子: def foo(boolean bar) { // Not consistent if (bar) { return positiveBar() } negativeBar() } def foo2() { // Special Grails example def entitiy = new Entity(foo: 'Foo', bar: 'Bar') entity.save flush: true // Looks strange to me this way entity }

4
使不依赖实例字段的方法变为静态吗?
最近,我开始在Groovy中为Java项目的集成测试框架进行编程。我将Intellij IDEA与Groovy插件一起使用,我很惊讶地看到所有非静态方法并且不依赖于任何实例字段,这是一个警告。但是,在Java中,这不是问题(至少从IDE的角度来看)。 是否将所有不依赖于任何实例字段的方法都转换为静态函数?如果为true,这是特定于Groovy还是通常可用于OOP?又为什么呢

4
groovy是否将部分应用程序称为“ currying”?
Groovy有一个称为“ currying”的概念。这是他们的Wiki中的一个示例: def divide = { a, b -> a / b } def halver = divide.rcurry(2) assert halver(8) == 4 我对这里发生的事情的理解是,右边的参数divide绑定到了值2。这似乎是部分应用的一种形式。 术语currying通常用于将包含一系列参数的函数转换为仅包含一个参数并返回另一个函数的函数。例如,以下是curryHaskell 中的函数类型: curry :: ((a, b) -> c) -> (a -> (b -> c)) 对于谁没有用过Haskell的人a,b并且c都是通用的参数。 curry接受一个带有两个参数的函数,然后返回一个函数,该函数接受a并返回一个b到的函数c。我为该类型添加了额外的一对括号,以使其更加清楚。 我是否误解了groovy示例中发生的事情,还是只是误命名了部分应用程序?或实际上是两者兼而有之:也就是说,将其转换divide为咖喱函数,然后部分地应用于2此新函数。

1
Groovy是否遵循Tennent的通信原理?
这是对Tennent的通信原理的有趣讨论,以及Neal Gafter的简短描述: 该原理规定,将表达式或语句包装在闭包中然后立即调用时,其含义应与包装在闭包中之前的含义相同。在将代码包装在闭包中时,语义上的任何更改都可能是该语言的缺陷。 Groovy语言是否遵循此原则?

1
“语法醋”是什么意思
我正在阅读《Groovy in Action,第二版》,并在一个脚注中找到了以下内容: Java将“语法醋”浇在这样的结构上,以阻止程序员使用它。 该术语syntax vinegar在这里意味着什么? 我之前从未听说过这个词,并在DuckDuckGo和Google上进行了搜索,但找不到含义。但是它已在多个地方使用。如果有人可以澄清该术语的含义以及它在编程语言中的应用,那就太好了。希望这构成一个有效的问题。找不到其他我可以问这个的stackexchange网站。
12 java  syntax  groovy 

5
Grails框架中的陷阱[已关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 使用Grails框架有哪些最大的问题/陷阱?我现在正在学习框架,我真的很喜欢它,但是我需要知道在使用它时可能遇到的主要问题以及如何避免它们。

1
Groovy中的特性,继承和接口,何时使用?
我正在学习groovy,我刚刚了解了2.3中添加的新功能,即Traits的添加。现在对我来说,特质似乎可以让您完成超类和接口可以做的所有事情。 在Groovy中添加特性会否使继承和接口过时? 如果不是,那么使用这些机制的最佳时间是什么?

4
currying或部分应用有什么特别之处?
我每天都在阅读有关函数式编程的文章,并尝试尽可能地应用一些实践。但是我不明白在currying或部分应用程序中有什么独特之处。 以以下Groovy代码为例: def mul = { a, b -> a * b } def tripler1 = mul.curry(3) def tripler2 = { mul(3, it) } 我不了解tripler1和之间的区别tripler2。他们不是都一样吗?在纯或部分功能的语言(例如Groovy,Scala,Haskell等)中支持“ currying”。但是,我可以通过简单地创建另一个命名或匿名方法来做相同的事情(left-curry,right-curry,n-curry或部分应用程序)函数或闭包将tripler2大多数语言(甚至C)中的参数转发到原始函数(如) 我在这里想念什么吗?在某些地方可以在Grails应用程序中使用currying和Partial应用程序,但是我很犹豫这样做,因为我在问自己“那有什么不同?” 请赐教。 编辑:你们是说部分应用程序/ currying比创建/调用将默认参数转发到原始函数的另一个函数更有效吗?

5
在基于JVM的语言中是否有明确的领导者?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 这些项目的当前状态如何,有一个(或两个)以明确的领导者身份出现吗? 为了证明我提出这个问题的动机,请回想几年。原型和jQuery与MooTools等其他竞争者并肩生存。快速发展到今天,人们普遍认为jQuery是最好的通用JavaScript库。 在过去的几年中,这些基于JVM的语言发生了类似的事情吗?某些语言是否陷入失修和遗弃?从我阅读的内容来看,Scala似乎已经做好了成为备受喜爱的准备,但是话又说回来,我所阅读的几乎所有内容都已经有好几年了。 我做了更多的研究-我的想法是通过使用Google趋势来查看多年来的搜索量。似乎Jython和JRuby的兴趣相对较小,而Groovy的音量在减小,而Scala的音量是恒定的(在最坏的情况下)或在微小的(最好)在增加。这是准确的评估吗? 是的,我指的是JVM上的非Java语言,例如Jython,JRuby,Groovy,Scala,Clojure等。
9 java  scala  jvm  groovy  jruby 
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.