2008-05-07
Scala拾趣--从Java7说开来
关键字: scala java
我们知道,关于当前正在进行中的Java7在Java社区有很多讨论。其焦点集中在要不要在Java7中引入一些新的语言特性,尤其是闭包:不仅有要不要加入闭包的争论,还有采用那种实现方式的问题。在javapolis举行的关于JAVA7语言特性投票的结果一文中列出了Java7中可能会加入的语言特性,那么我们先来看看在Scala中对于这些语言特性有何解决方式呢?
首先把闭包撇出来,因为对闭包不甚了解,所以就不多说。不过以我的看法,因为Scala本身就支持函数式编程,而Java还需要向后兼容性的考虑,所以我觉得Java7中无论以那种方式来实现闭包,也不太可能比Scala中的实现更加有效,或更加优雅。
下面我们就逐条来分析Java7中的十种语法提议:
1.Property declaration
2.Property access
这两条都是为了简化书写代码,这里用一个具体的例子来说明:
考虑一个Person类,这个类有两个属性,一个是表示姓名的forename,在JAVA7中可能的实现方式:
而使用Scala,则可以使用下列方式(参考资料:Defining a BeanProperty):
一行代码搞定!
3.Improve generics
Scala中也支持泛型,而且貌似比JAVA中的更灵活。不过其实现方式与目前的JAVA一样,都是使用擦除化。因此对于JAVA中泛型存在的一些问题,Scala中也存在(唔,至少这条提议中列出的两个问题在Scala中也同样存在。其他的我不太清楚,目前对Scala中的泛型理解尚浅)。
4.Access List and Map using []
在Scala中可以像下面一样使用Map:
可以看到,在Scala中可以通过map(key)来读取value,通过map(key) =value来写入值对...
事实上,Scala中并没有对Map提供特别的语法支持。也就是说,对任意的类,你都可以像操作Map一样。只要你在一个类a中定义了apply方法,你就可以把这个类当作一个函数来使:
a(something)
这等价于:
a.apply(something)
如果你还定义了update方法,你就可以使用
a(key) =value
这等价于
a.update(key,value)
怎么样,不赖吧?
5,10.Null-handling and chaining
之所以有这两个提议,是由于在Java中存在null以及void类型的方法。在Java中,很多方法会返回一个null表示没有得到预期的结果或结果为空。事实上大部分情况这样做是不恰当的,这时抛出一个异常或返回一个表示“空”的对象(比如字符串“”,或空的List)可能更合理。而且这样造成的后果是对于很多方法调用后需要对其结果是否为null进行判断。
幸运的是,Scala中没有这些问题。
第一:在Scala中没有void,也就是说每个方法都会返回一个实实在在的对象(Java中的void在Scala中有一个对应的类Unit)。
第二:对于标准的Scala程序,null不应该出现。相对应的Scala中有个Option类来处理这种返回结果为“空”的情形。
这里我也不细说了,有兴趣的可以参看opensdp同学的 用Scala语言中的 Option 对象来处理 null-like 返回值。
6.Extension methods
这个有点像Ruby中的“open class”,就是允许在不修改原有代码的情况下给已有的类添加新的方法。
由于JAVA是静态类型语言,并且不允许两个名字完全一样的类的存在,所以在这一点的实现肯定会有很多限制,不可能做到像Ruby那样。目前有两种解决方案:
example:
import static java.util.Collections.sort;
…
List<String> list = …;
list.sort();
"Declaration-Site Extension Methods"
example:
package java.util;
interface List<E> … {
…
void sort() import static java.util.Collections.sort;
…
}
第一种实现可以看成是static import的一种扩展;第二种实现同样用到了static import,并且需要修改已有代码。
总之,这两种方案看起来都不甚优雅,甚至可以说丑陋。其意义也不大,并且对代码的可读性会造成一定的影响。
那么我们来看看Scala中能够如何解决这个问题。Scala中有一个功能很强大的机制:隐式类型转换。这个机制威力巨大,用处远不止Extension methods,这里我只举个例子说明如何解决Extension methods,有兴趣的可以参看fakechris同学写的scala学习笔记(5) -- implicit type
在Ruby中,我们可以通过如下方式向String类中添加print_self方法:
然后我们就可以对普通的String调用print_self方法:
那么Scala中怎末实现这个呢?很简单:
并且在类StringTest可见的范围内,这个方法都是有效的。(参考资料:Getting Over Java)
7.String switch
在Scala中没有switch关键词,但是有另一个强大得多的机制(不过,也复杂得多):Pattern match。实现String switch功能,那只不过是小菜一根。
8.Typedef
唔,对于这个功能...但是Scala中恰好就有这样一个关键词type,typedef就是这个关键词的作用之一:
9.Multi-catch
这里我们又可以来感受一下Scala中Pattern match的威力了:
结论:可以看到,目前在JAVA中想方设法想要加入的语言特性,在Scala中要么是根本不需要的东西,要么是以一种更加优雅的方式实现了。但同时,在学习Scala的过程中,一方面感受到Scala语法所带来的巨大便利与威力,另一方面其语法比起JAVA来复杂了许多。譬如在Java中粗略来说有interface,abstract class与普通的class。而Scala中除了普通的class与abstract class还有case class,sealed class,trait,object这些类型的类。更不用说Scala中那些函数式有关的语法了。
因此,可能有人会有疑问:有着这么复杂语法的语言有存在的必要吗?会不会成为下一个C++(恐龙)呢?Daniel Spiewak 在他的博客Is Scala Really the Next C++?中也提出了这个问题,他的答案是否定的。主要的理由是:C++由于兼容的目的背上了C这个沉重的包袱,由于C的影响,很多语言特性不能很好的实现;而Scala不同,Scala与Java在源代码上是不兼容的,因此Scala可以更加自由的发挥。
我比较赞同这个观点,同时觉得Java7不应该添加太多的东西进去了。虽然现在Java代码相对其他新式语言来说显得啰嗦,但是Java简单,这就是它最大的优点。如果Java即要考虑向后兼容性,又想把新的特性一股脑加进去,到后来只可能走向C++的老路。这些新的特性应该由JVM上的其他语言来实现,比如Groovy,比如Scala。你觉得呢?
PS:根据达尔文的理论,生物的进化包括遗传与变异。而目前的JAVA是只“遗传”不“变异”,这对于语言的进化也是很不好的。
首先把闭包撇出来,因为对闭包不甚了解,所以就不多说。不过以我的看法,因为Scala本身就支持函数式编程,而Java还需要向后兼容性的考虑,所以我觉得Java7中无论以那种方式来实现闭包,也不太可能比Scala中的实现更加有效,或更加优雅。
下面我们就逐条来分析Java7中的十种语法提议:
1.Property declaration
2.Property access
这两条都是为了简化书写代码,这里用一个具体的例子来说明:
考虑一个Person类,这个类有两个属性,一个是表示姓名的forename,在JAVA7中可能的实现方式:
public class Person {
public property String forename;
public property int age;
}
而使用Scala,则可以使用下列方式(参考资料:Defining a BeanProperty):
class Person(@BeanProperty var forename:String,@BeanProperty var age:Int)
一行代码搞定!
3.Improve generics
Scala中也支持泛型,而且貌似比JAVA中的更灵活。不过其实现方式与目前的JAVA一样,都是使用擦除化。因此对于JAVA中泛型存在的一些问题,Scala中也存在(唔,至少这条提议中列出的两个问题在Scala中也同样存在。其他的我不太清楚,目前对Scala中的泛型理解尚浅)。
4.Access List and Map using []
在Scala中可以像下面一样使用Map:
import scala.collection.mutable.HashMap
object MapAccess extends Application{
var map =new HashMap[Int,String]
map(0) ="Zero"
map += 1 -> "One"
map += 2 -> "Two"
var value =map(2)
println(value)
}
可以看到,在Scala中可以通过map(key)来读取value,通过map(key) =value来写入值对...
事实上,Scala中并没有对Map提供特别的语法支持。也就是说,对任意的类,你都可以像操作Map一样。只要你在一个类a中定义了apply方法,你就可以把这个类当作一个函数来使:
a(something)
这等价于:
a.apply(something)
如果你还定义了update方法,你就可以使用
a(key) =value
这等价于
a.update(key,value)
怎么样,不赖吧?
5,10.Null-handling and chaining
之所以有这两个提议,是由于在Java中存在null以及void类型的方法。在Java中,很多方法会返回一个null表示没有得到预期的结果或结果为空。事实上大部分情况这样做是不恰当的,这时抛出一个异常或返回一个表示“空”的对象(比如字符串“”,或空的List)可能更合理。而且这样造成的后果是对于很多方法调用后需要对其结果是否为null进行判断。
幸运的是,Scala中没有这些问题。
第一:在Scala中没有void,也就是说每个方法都会返回一个实实在在的对象(Java中的void在Scala中有一个对应的类Unit)。
第二:对于标准的Scala程序,null不应该出现。相对应的Scala中有个Option类来处理这种返回结果为“空”的情形。
这里我也不细说了,有兴趣的可以参看opensdp同学的 用Scala语言中的 Option 对象来处理 null-like 返回值。
6.Extension methods
这个有点像Ruby中的“open class”,就是允许在不修改原有代码的情况下给已有的类添加新的方法。
由于JAVA是静态类型语言,并且不允许两个名字完全一样的类的存在,所以在这一点的实现肯定会有很多限制,不可能做到像Ruby那样。目前有两种解决方案:
Neal Gafter的提议 写道
example:
import static java.util.Collections.sort;
…
List<String> list = …;
list.sort();
Peter Ahé's 的提议 写道
"Declaration-Site Extension Methods"
example:
package java.util;
interface List<E> … {
…
void sort() import static java.util.Collections.sort;
…
}
第一种实现可以看成是static import的一种扩展;第二种实现同样用到了static import,并且需要修改已有代码。
总之,这两种方案看起来都不甚优雅,甚至可以说丑陋。其意义也不大,并且对代码的可读性会造成一定的影响。
那么我们来看看Scala中能够如何解决这个问题。Scala中有一个功能很强大的机制:隐式类型转换。这个机制威力巨大,用处远不止Extension methods,这里我只举个例子说明如何解决Extension methods,有兴趣的可以参看fakechris同学写的scala学习笔记(5) -- implicit type
在Ruby中,我们可以通过如下方式向String类中添加print_self方法:
class String
def print_self
puts self
end
end
然后我们就可以对普通的String调用print_self方法:
"Daniel Spiewak".print_self # prints my name
那么Scala中怎末实现这个呢?很简单:
object StringTest extends Application{
"Eastsun".printSelf //对String调用printSelf方法
implicit def stringWrapper(s:String) =new {
def printSelf = println(s)
}
}
并且在类StringTest可见的范围内,这个方法都是有效的。(参考资料:Getting Over Java)
7.String switch
在Scala中没有switch关键词,但是有另一个强大得多的机制(不过,也复杂得多):Pattern match。实现String switch功能,那只不过是小菜一根。
object MatchTest extends Application{
test("hello")
def test(obj:Any):Unit = obj match{
case 1|2|3|4 => println("A integer between 1 and 4")
case "hello" => println("Hi")
case _ => println("something else")
}
}
8.Typedef
唔,对于这个功能...但是Scala中恰好就有这样一个关键词type,typedef就是这个关键词的作用之一:
import scala.collection.mutable.HashMap
object TypeTest extends Application{
type ISMap =HashMap[Int,String]
var map =new ISMap
map(1) ="One"
}
9.Multi-catch
这里我们又可以来感受一下Scala中Pattern match的威力了:
import java.io.IOException
object ExceptionCatch extends Application{
exceptionCatch(ioexceptionThrow)
def ioexceptionThrow():Unit = throw new IOException
def exceptionCatch(func:()=>Unit) =
try{
func()
}catch{
case _:IllegalArgumentException|_:IllegalStateException => println("RuntimeException")
case _:IOException => println("IOException")
case _ => println("Something else")
}
}
结论:可以看到,目前在JAVA中想方设法想要加入的语言特性,在Scala中要么是根本不需要的东西,要么是以一种更加优雅的方式实现了。但同时,在学习Scala的过程中,一方面感受到Scala语法所带来的巨大便利与威力,另一方面其语法比起JAVA来复杂了许多。譬如在Java中粗略来说有interface,abstract class与普通的class。而Scala中除了普通的class与abstract class还有case class,sealed class,trait,object这些类型的类。更不用说Scala中那些函数式有关的语法了。
因此,可能有人会有疑问:有着这么复杂语法的语言有存在的必要吗?会不会成为下一个C++(恐龙)呢?Daniel Spiewak 在他的博客Is Scala Really the Next C++?中也提出了这个问题,他的答案是否定的。主要的理由是:C++由于兼容的目的背上了C这个沉重的包袱,由于C的影响,很多语言特性不能很好的实现;而Scala不同,Scala与Java在源代码上是不兼容的,因此Scala可以更加自由的发挥。
我比较赞同这个观点,同时觉得Java7不应该添加太多的东西进去了。虽然现在Java代码相对其他新式语言来说显得啰嗦,但是Java简单,这就是它最大的优点。如果Java即要考虑向后兼容性,又想把新的特性一股脑加进去,到后来只可能走向C++的老路。这些新的特性应该由JVM上的其他语言来实现,比如Groovy,比如Scala。你觉得呢?
PS:根据达尔文的理论,生物的进化包括遗传与变异。而目前的JAVA是只“遗传”不“变异”,这对于语言的进化也是很不好的。
评论
groovyzhou
2008-06-16
泡 泡 写道
icanfly 写道
Eastsun 写道
问题是如果需要兼容,就不太可能实现的很优雅
譬如JAVA5中的泛型。。。和鸡肋差不多。
以及将要加入的闭包,其实现方式也够呛。
这种打补丁式的改进总不会太完美。
PS:弄一个JAVA3000出来也不错,抛弃向后兼容性。
譬如JAVA5中的泛型。。。和鸡肋差不多。
以及将要加入的闭包,其实现方式也够呛。
这种打补丁式的改进总不会太完美。
PS:弄一个JAVA3000出来也不错,抛弃向后兼容性。
我同意,JAVA顾虑得太多,应该学学Python,要使用旧JAVA语法的用JAVA旧的版本,要使用新的语法可以用新的版本,这样不但JAVA类库中有些“鸡肋”可以踢除,本身语言简洁性也得到提高!希望JAVA语言的开发工程师们不要老停留在要兼顾以前版本的陈旧思想里了!
那么庞大的开源类库,谁去转成新版本,不向下兼容导致的问题更多
开源类库有很多是半死不活的, 如果没有人维护, 即使java保持兼容性, 这些类库最终也是会被用户抛弃
如果用的人多, 自然有人会转过来
python3000在python社区里面并没有引起多大的反对声音
java并没有兼容c和c++, 不照样是流行起来了
兼容性根本不是问题
groovyzhou
2008-06-16
Eastsun 写道
ray_linn 写道
总的看来,Java 7将是C# 3.5的一次大抄袭而已。
说起“抄袭”,谁抄谁还不好说。
C#整个语言不就是模仿Java的么?
现在这些特性还只是提议而已,最终会不会加到Java7中去还未有分晓。
除了闭包我不是太肯定需不需要加入到Java7中去,其他的特性我觉得还是不要加的为好。
保持Java的简洁优雅比加入那些乌七八糟的特性更重要,我以为。
我觉得提议都不该,提议的人多了,sun公司头脑一发热就加进去了
应该向c学习,几十年不变
要么就学习python,勇敢的破坏向后兼容
ray_linn
2008-05-13
Eastsun 写道
avaj 写道
这典型的就是java.io包,这里头的烦琐到接近委琐的状态
==============
同意这句话。
==============
同意这句话。
保留意见
我觉得Java很多API从设计上来说还是蛮不错的。
比如IO,Swing etc.
给使用者提供了很大的灵活性。
但使用起来确实不那么方便,也容易把新手搞晕~
M$的东西偏向与傻瓜式,上手容易。
但灵活性估计就没那么好了,一切都在M$的掌控中,你只能跟着他转。
Java.io的复杂在thinking in java中有颇有诟病。
灵活性必须要在用必要的方面。比如对Micirosoft提供Data Provider的灵活性。至于替换一个XML dom,则大大值得考虑。
我从来没觉得Microsoft的东西是傻瓜式,这种所谓的傻瓜式只是对初级程序员而言,(当然大部分从业者都是初级程序员吧?),牛人照样能写出I4O(Indexed Linq)这样的东西。从某种意义上,Microsoft推出Linq to Collection这种东西,使得C#更接近自然语言。
Eastsun
2008-05-13
avaj 写道
这典型的就是java.io包,这里头的烦琐到接近委琐的状态
==============
同意这句话。
==============
同意这句话。
保留意见
我觉得Java很多API从设计上来说还是蛮不错的。
比如IO,Swing etc.
给使用者提供了很大的灵活性。
但使用起来确实不那么方便,也容易把新手搞晕~
M$的东西偏向与傻瓜式,上手容易。
但灵活性估计就没那么好了,一切都在M$的掌控中,你只能跟着他转。
avaj
2008-05-13
这典型的就是java.io包,这里头的烦琐到接近委琐的状态
==============
同意这句话。
==============
同意这句话。
ray_linn
2008-05-13
hax 写道
用Factory和Builder能提供灵活性,比如使用其他的XML DOM实现。M$的习惯一向是只此一家,别无分店,所以直接new就可以了。当然,我也认为java的XML可以简化,但是这不是什么大不了的问题。
XPath那个你冤枉Java了。Java的API是遵循W3C DOM Level 3 XPath的。如果你要骂,应该骂W3C去,嘿嘿。还有,骂之前请注意了,W3C的API允许对XPath表达式进行重用(当然也可以不重用),而MS的selectNodes方法虽然方便,但是没法重用XPath。还有返回值上的类型有限定。XPath其实可以返回并非节点和节点集类型的。所以MS的API是不严谨的。
你得承认,对于大部分状况下,MS的方案更简单,更容易。
拿XmlDocument来说,如果真有替换XML DOM API的必要性,Microsoft也会采用别的方案来实现更换XML dom,可能比如更换DomProvider(在MS的DataReader中就是如此)。
此外就拿XmlDocument的Load动作来说。
doc.Load("http://www.w3c.org/some.xml");
doc.Load("C:\W3C\some.xml");
doc.Load("\\w3c\\some.xml");
Microsoft接替了java程序员大部分的工作,使得程序员可以专注于当前的问题(要加载某一个xml文件),而不需要象Java一样,还要关注要如何加载。。。
我的重点不是在于它的烦琐,而是在于,Sun缺乏一种更简单,更明白的表达方式,这导致的Sun的语法象绕口令,而MS的语法则接近自然语言。另外Microsoft淘汰SAX,而采用Pull的方式,也是出于直观的考虑。
这典型的就是java.io包,这里头的烦琐到接近委琐的状态。
sniperking
2008-05-13
同意,太灵活了,反而会使学习成本加大,看别人的代码会更难理解
一行搞定一个功能看起来不错,可以让别人看你写的代码就麻烦了
一行搞定一个功能看起来不错,可以让别人看你写的代码就麻烦了
warren
2008-05-13
对其他语言了解不多,只熟悉点Java和Ruby.对于Java这个规范语言来说,我的感觉就是这些特性让Java变得越来越乱.大概看了一下Defining a BeanProperty,整体感觉既不像Java又不像Ruby,有点不伦不类,这种结合使得没了Java的严谨和Ruby的简洁,总体感觉就是乱.
deeprising
2008-05-13
Java应该保持简洁~~
hax
2008-05-12
ray_linn 写道
DocumentBuilderFactory domfac=DocumentBuilderFactory.newInstance();
try {
DocumentBuilder dombuilder=domfac.newDocumentBuilder();
InputStream is=new FileInputStream("bin/library.xml");
Document doc=dombuilder.parse(is);
这几句,应该只要一两句
XmlDocument doc=new XmlDocumnet(). doc.load(path)//为了增加/取消validation
DocumentBuilderFactory,DocumentBuilder 都是多余的垃圾类。再比如XPath
XPath xpath = XPathFactory.newInstance().newXPath();
String expression = "/widgets/widget";
InputSource inputSource = new InputSource("widgets.xml");
NodeSet nodes = (NodeSet) xpath.evaluate(expression, inputSource, XPathConstants.NODESET);
和
XmlDocument = new XmlDocument();
doc.Load("widgets.xml");
NodeList nodes=doc.DocumentElement.SelectNodes("/widgets/widget");
.net的写法象英文一样自然,Java的写法则古怪得很,(我估计还得查一下evaluate的API含义)。
用Factory和Builder能提供灵活性,比如使用其他的XML DOM实现。M$的习惯一向是只此一家,别无分店,所以直接new就可以了。当然,我也认为java的XML可以简化,但是这不是什么大不了的问题。
XPath那个你冤枉Java了。Java的API是遵循W3C DOM Level 3 XPath的。如果你要骂,应该骂W3C去,嘿嘿。还有,骂之前请注意了,W3C的API允许对XPath表达式进行重用(当然也可以不重用),而MS的selectNodes方法虽然方便,但是没法重用XPath。还有返回值上的类型有限定。XPath其实可以返回并非节点和节点集类型的。所以MS的API是不严谨的。
aninfeel
2008-05-11
Map在java里怎么说也是个普通的类,怎么能在编译器上为它设计特别的语法呢?哪天发现其它语言的File简单,是不是也要为为File加个特殊语法?然后发现其它实现也要简化,就再为它设计特殊语法?
aws
2008-05-10
OPTIMUS.PRIME 写道
Eastsun 写道
1.Property declaration
2.Property access
这两条都是为了简化书写代码,这里用一个具体的例子来说明:
考虑一个Person类,这个类有两个属性,一个是表示姓名的forename,在JAVA7中可能的实现方式:
public class Person {
public property String forename;
public property int age;
}
而使用Scala,则可以使用下列方式(参考资料:Defining a BeanProperty):
class Person(@BeanProperty var forename:String,@BeanProperty var age:Int)
一行代码搞定!
哦,你把两行代码写在一行里面就是“一行代码搞定”了?
Eastsun 写道
4.Access List and Map using []
在Scala中可以像下面一样使用Map:
import scala.collection.mutable.HashMap
object MapAccess extends Application{
var map =new HashMap[Int,String]
map(0) ="Zero"
map += 1 -> "One"
map += 2 -> "Two"
var value =map(2)
println(value)
}
可以看到,在Scala中可以通过map(key)来读取value,通过map(key) =value来写入值对...
事实上,Scala中并没有对Map提供特别的语法支持。也就是说,对任意的类,你都可以像操作Map一样。只要你在一个类a中定义了apply方法,你就可以把这个类当作一个函数来使:
a(something)
这等价于:
a.apply(something)
如果你还定义了update方法,你就可以使用
a(key) =value
这等价于
a.update(key,value)
怎么样,不赖吧?
这就“不赖”,你品味也太低了吧。Java设计之初就放弃的运算符重载罢了。而且这种莫名其妙的语法比C++的重载难看不知道多少,好端端的operator()叫什么“apply”,好端端的operator[]=叫什么“update”,命名欲爆发了?
引用
5,10.Null-handling and chaining
之所以有这两个提议,是由于在Java中存在null以及void类型的方法。在Java中,很多方法会返回一个null表示没有得到预期的结果或结果为空。事实上大部分情况这样做是不恰当的,这时抛出一个异常或返回一个表示“空”的对象(比如字符串“”,或空的List)可能更合理。而且这样造成的后果是对于很多方法调用后需要对其结果是否为null进行判断。
幸运的是,Scala中没有这些问题。
第一:在Scala中没有void,也就是说每个方法都会返回一个实实在在的对象(Java中的void在Scala中有一个对应的类Unit)。
第二:对于标准的Scala程序,null不应该出现。相对应的Scala中有个Option类来处理这种返回结果为“空”的情形。
这里我也不细说了,有兴趣的可以参看opensdp同学的 用Scala语言中的 Option 对象来处理 null-like 返回值。
嗯嗯,Scala没void或NULL,但有个专门的NULL对象。真高级呀,不过到头来还是得判断程序返回了正常的对象还是这个高级的NULL对象。
顺便说一句,有个设计模式叫NULL Object模式。另外这个所谓的“高级特色”在C++中属于常识(事实上复制构造器、赋值操作符重载之类的事情很是烦倒了一批人,以至于Java上手就把所有东西当用指针来handle)
引用
6.Extension methods
莫名其妙的东西,暂不加评论。
引用
8.Typedef
唔,对于这个功能...但是Scala中恰好就有这样一个关键词type,typedef就是这个关键词的作用之一:
import scala.collection.mutable.HashMap
object TypeTest extends Application{
type ISMap =HashMap[Int,String]
var map =new ISMap
map(1) ="One"
}
又是C++就有的几百年前的玩意。Java扔了这个怪物Scala又拾起来当卖点。
引用
9.Multi-catch
这里我们又可以来感受一下Scala中Pattern match的威力了:
import java.io.IOException
object ExceptionCatch extends Application{
exceptionCatch(ioexceptionThrow)
def ioexceptionThrow():Unit = throw new IOException
def exceptionCatch(func:()=>Unit) =
try{
func()
}catch{
case _:IllegalArgumentException|_:IllegalStateException => println("RuntimeException")
case _:IOException => println("IOException")
case _ => println("Something else")
}
}
Multi-catch也算是新功能?多写几次catch不是一样么?
“因为case只要4个字符,catch有5个字符,用Scala可以少写几个字符耶!!!”
Puke...
引用
结论:可以看到,目前在JAVA中想方设法想要加入的语言特性,在Scala中要么是根本不需要的东西,要么是以一种更加优雅的方式实现了。但同时,在学习Scala的过程中,一方面感受到Scala语法所带来的巨大便利与威力,另一方面其语法比起JAVA来复杂了许多。譬如在Java中粗略来说有interface,abstract class与普通的class。而Scala中除了普通的class与abstract class还有case class,sealed class,trait,object这些类型的类。更不用说Scala中那些函数式有关的语法了。
一堆无用的语法糖衣罢了。
引用
而Scala不同,Scala与Java在源代码上是不兼容的
很好,死得更快。
这帖还精华?再puke...
這种的所謂改進無非就是把簡單明瞭的東西複雜化
aws
2008-05-10
little06 写道
Norther 写道
pancras 写道
Norther 写道
pancras 写道
Norther 写道
个人觉得property那部分,可以用annotation,比引入新的关键字和谐的多,可以在编译期做些手脚,根据annotation生成get,set方法,例如
同时也可以对"="和"."符号做特殊处理,例如
class Student{
@Property //代表可以get 和set
private String name;
@Setter //代表可以set
private Integer age;
//省略get set方法
}
同时也可以对"="和"."符号做特殊处理,例如
student.information.content = "hahaha";//会编译成student.getInformation().setContent("hahaha");
student.age = 19;//会被编译成student.setAge(19);
如果这这样了 和直接把属性的访问级别放成public有什么不同? 如果要在set方法中对值进行过滤又如何实现。
典型的滥用annotation。
当然有不同,这个机制没有这么蠢,如果你提供了属性相应的set方法,它就不生成,就用你的,这也可以在set里进行过滤,只是在编译的时候做点手脚,对虚拟机没有影响,真是灰常灰常的简单和灵活。
另外我不明白这怎么算滥用了,就加入两个annotation,就叫滥用了?宁可引入关键字去滥用关键字?那什么不是滥用?
为了用而用,不是滥用么?何况你这样做根本没有什么实际意义,如果有,能明确表示出来么?你所谓的灵活是什么?分明就是强行把能通过公开访问的东西使用你的annotation实现。
怎么是为了用而用?我实在不明白,麻烦你再好好解释一下,这样做可以减少大量无意义的代码,方便程序的可读性,这是参照RUBY的,只不过利用编译手段,不用去改虚拟机,编译出来的代码,和private字段且提供了GET,SET方法的字节码是一样的,这样并不是把FIELD改成public的,你根本没有仔细看我的回帖,我说的很明白,如果你的get或者set有自己的逻辑,自己就写个get或者set方法,编译器编译时判断你已经提供了set方法就不生成了,难道这不是灵活吗?我们写的get,set方法80%的情况是没有逻辑的,就是简单的访问或者设置,这样的重复劳动完全可以省略的,去看看RUBY或者C#怎么做的吧。
简单的问题复杂化
觉得java可以有接口手动控制内存就好了
感觉现在很多问题都是内存泄露上
特别是小型系统
在小并发下,不考虑性能 效率,唯一问题就是内存泄露上
程序除了 人与 计算机的沟通外,无非是 功能,速度,稳定性
那還用java幹嗎?
我不會直接回去用C++
williamy
2008-05-09
if you do need to type more lines , it maters ?
no ,i don't care ,but i'm still wanna more functional apis ,hopes it has the power as c /c ++
no ,i don't care ,but i'm still wanna more functional apis ,hopes it has the power as c /c ++
ray_linn
2008-05-09
Eastsun 写道
1.同样希望
2.貌似Java7中会加入NIO2,丢弃旧有暂时还不太可能(向后兼容性是个包袱)
3.。
4.同样不太可能,不过现在的用着还不错
5.JAVA 的XML API貌似还可以吧
Java XML的问题是烦琐,名字取得也有点不着调。与.net三步之类必能处理xml比,还是烦琐。 Web service则更差。。(.net大部分都是在method上加一个attribute就完了)。
DocumentBuilderFactory domfac=DocumentBuilderFactory.newInstance();
try {
DocumentBuilder dombuilder=domfac.newDocumentBuilder();
InputStream is=new FileInputStream("bin/library.xml");
Document doc=dombuilder.parse(is);
这几句,应该只要一两句
XmlDocument doc=new XmlDocumnet(). doc.load(path)//为了增加/取消validation
DocumentBuilderFactory,DocumentBuilder 都是多余的垃圾类。再比如XPath
XPath xpath = XPathFactory.newInstance().newXPath();
String expression = "/widgets/widget";
InputSource inputSource = new InputSource("widgets.xml");
NodeSet nodes = (NodeSet) xpath.evaluate(expression, inputSource, XPathConstants.NODESET);
和
XmlDocument = new XmlDocument();
doc.Load("widgets.xml");
NodeList nodes=doc.DocumentElement.SelectNodes("/widgets/widget");
.net的写法象英文一样自然,Java的写法则古怪得很,(我估计还得查一下evaluate的API含义)。
Eastsun
2008-05-09
ray_linn 写道
我希望的java 7.0。
1。彻底修改generic,放弃擦除法改用.net的膨胀法。
2。丢弃部分IO的类,使之简单化。
3。改进jar的签名,使之具有版本签名,避免classpath load进同一个jar的不同版本造成错误,应该加入assembly的强签名。(我在eclipse被这个搞得烦死了)。
4。清理java.util,把collection独立出来。
5。提供简单实用的XML API,支持DOM/Pull/push三种方式,以及xml-object的序列化方法。(这个可能有了)以及简单的web service支持。
1。彻底修改generic,放弃擦除法改用.net的膨胀法。
2。丢弃部分IO的类,使之简单化。
3。改进jar的签名,使之具有版本签名,避免classpath load进同一个jar的不同版本造成错误,应该加入assembly的强签名。(我在eclipse被这个搞得烦死了)。
4。清理java.util,把collection独立出来。
5。提供简单实用的XML API,支持DOM/Pull/push三种方式,以及xml-object的序列化方法。(这个可能有了)以及简单的web service支持。
1.同样希望
2.貌似Java7中会加入NIO2,丢弃旧有暂时还不太可能(向后兼容性是个包袱)
3.。
4.同样不太可能,不过现在的用着还不错
5.JAVA 的XML API貌似还可以吧
ray_linn
2008-05-09
我希望的java 7.0。
1。彻底修改generic,放弃擦除法改用.net的膨胀法。
2。丢弃部分IO的类,使之简单化。
3。改进jar的签名,使之具有版本签名,避免classpath load进同一个jar的不同版本造成错误,应该加入assembly的强签名。(我在eclipse被这个搞得烦死了)。
4。清理java.util,把collection独立出来。
5。提供简单实用的XML API,支持DOM/Pull/push三种方式,以及xml-object的序列化方法。(这个可能有了)以及简单的web service支持。
1。彻底修改generic,放弃擦除法改用.net的膨胀法。
2。丢弃部分IO的类,使之简单化。
3。改进jar的签名,使之具有版本签名,避免classpath load进同一个jar的不同版本造成错误,应该加入assembly的强签名。(我在eclipse被这个搞得烦死了)。
4。清理java.util,把collection独立出来。
5。提供简单实用的XML API,支持DOM/Pull/push三种方式,以及xml-object的序列化方法。(这个可能有了)以及简单的web service支持。
ray_linn
2008-05-09
Eastsun 写道
ray_linn 写道
C#从1.0开始就保持了自己的创新,Java呢?从6。0开始,几乎是亦步亦趋,几乎看看C#,就可以知道下一个版本的Java大概会出现什么东西
举几个例子说说?
我不太了解C#,所以也不清楚Java6.0哪儿抄了C#的。
PS:貌似C#3.0较C#1.0有很大改进,我很是好奇C#是怎末做到向后兼容的?或者C#没有向后兼容性?
应该说是5.0,我把java 1.3升级到java 4.0,当成升级到6。0了。
java 5.0:
for/in循环 = C# 1.0的 foreach
annotation = C# 1.0的 attribute (这点相信是C#对Java的最大贡献,否则JCP那帮人估计还在吵架)
enum =C#1.0的enum
autoboxing/unboxing..
可变参数... C# 1.0都有。
java 6.0更象是一个5.0 patch,语法上改善很少,大部分是API的补强。唯一亮点是支持javascript,不过有啥用我没想出来。
java 7.0里语法亮点在C# 3.0里都有,缺少的是LINQ。
C# 3.0里的很多特点,比如静态方法、var类型,get/set都是在compiler上动手脚的,C# 3.0基于2.0的FX,你可以叫他sugar (.net 3.5=.net 2.0+WPF+WCF..)
.net 1.0与.net 2.0最大的区别是Generic,Microsoft将Generic安排到独立的名称空间去,system.collection.generic,你要用generic,你就得用2.0,因此继续保持后向兼容。
Eastsun
2008-05-09
ray_linn 写道
C#从1.0开始就保持了自己的创新,Java呢?从6。0开始,几乎是亦步亦趋,几乎看看C#,就可以知道下一个版本的Java大概会出现什么东西
举几个例子说说?
我不太了解C#,所以也不清楚Java6.0哪儿抄了C#的。
PS:貌似C#3.0较C#1.0有很大改进,我很是好奇C#是怎末做到向后兼容的?或者C#没有向后兼容性?
wdlfellow
2008-05-09
icanfly 写道
Eastsun 写道
问题是如果需要兼容,就不太可能实现的很优雅
譬如JAVA5中的泛型。。。和鸡肋差不多。
以及将要加入的闭包,其实现方式也够呛。
这种打补丁式的改进总不会太完美。
PS:弄一个JAVA3000出来也不错,抛弃向后兼容性。
譬如JAVA5中的泛型。。。和鸡肋差不多。
以及将要加入的闭包,其实现方式也够呛。
这种打补丁式的改进总不会太完美。
PS:弄一个JAVA3000出来也不错,抛弃向后兼容性。
我同意,JAVA顾虑得太多,应该学学Python,要使用旧JAVA语法的用JAVA旧的版本,要使用新的语法可以用新的版本,这样不但JAVA类库中有些“鸡肋”可以踢除,本身语言简洁性也得到提高!希望JAVA语言的开发工程师们不要老停留在要兼顾以前版本的陈旧思想里了!
严重同意,现在java的发展方向让人更迷茫
发表评论
提醒: 该博客已发表在公共论坛,博客所有留言会成为论坛回贴,留言请注意遵守论坛发贴规则
- 浏览: 71127 次
- 性别:

- 来自: 天津

- 详细资料
搜索本博客
我的相册
businessblacksteel1.png
共 60 张
共 60 张
最新评论
-
澄清:Java中只有按值传递 ...
这个没什么好争论的吧,不管你传的是什么,传过去的都只是一个副本而已,这个副本作为 ...
-- by rxgp02a -
澄清:Java中只有按值传递 ...
在传递引用的时候其实是复制了一份引用传进去的.A a=new A();test( ...
-- by xiao0556 -
澄清:Java中只有按值传递 ...
引用到底是什么?Java这些概念的东西,最头痛了,看C++时候,什么都很轻松,但 ...
-- by williamy -
澄清:Java中只有按值传递 ...
Java中的String、Integer等类型都是不可变类型,所以把这样的人传入 ...
-- by MarkDong -
澄清:Java中只有按值传递 ...
MarkDong 写道楼主把C++的例子理解错误了,那个swap(Type& a ...
-- by welcomyou






评论排行榜