|
锁定老帖子 主题：Scala拾趣--从Java7说开来
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-05-09
ray_linn 写道 C#从1.0开始就保持了自己的创新，Java呢？从6。0开始，几乎是亦步亦趋，几乎看看C#，就可以知道下一个版本的Java大概会出现什么东西 举几个例子说说？ 我不太了解Ｃ＃，所以也不清楚Ｊａｖａ６.０哪儿抄了Ｃ＃的。 ＰＳ：貌似Ｃ＃３.０较Ｃ＃１.０有很大改进，我很是好奇Ｃ＃是怎末做到向后兼容的？或者Ｃ＃没有向后兼容性？ |
| 返回顶楼 | |
|
发表时间：2008-05-09
Eastsun 写道 ray_linn 写道 C#从1.0开始就保持了自己的创新，Java呢？从6。0开始，几乎是亦步亦趋，几乎看看C#，就可以知道下一个版本的Java大概会出现什么东西 举几个例子说说？ 我不太了解Ｃ＃，所以也不清楚Ｊａｖａ６.０哪儿抄了Ｃ＃的。 ＰＳ：貌似Ｃ＃３.０较Ｃ＃１.０有很大改进，我很是好奇Ｃ＃是怎末做到向后兼容的？或者Ｃ＃没有向后兼容性？ 应该说是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，因此继续保持后向兼容。 |
| 返回顶楼 | |
|
发表时间：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支持。 |
| 返回顶楼 | |
|
发表时间：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.同样希望 2.貌似Java7中会加入NIO2，丢弃旧有暂时还不太可能（向后兼容性是个包袱） 3.。 4.同样不太可能，不过现在的用着还不错 5.JAVA 的XML API貌似还可以吧 |
| 返回顶楼 | |
|
发表时间：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含义）。 |
| 返回顶楼 | |
|
发表时间：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 ++ |
| 返回顶楼 | |
|
发表时间：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++ |
| 返回顶楼 | |
|
发表时间：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... 這种的所謂改進無非就是把簡單明瞭的東西複雜化 |
| 返回顶楼 | |
|
发表时间：2008-05-11
Map在java里怎么说也是个普通的类，怎么能在编译器上为它设计特别的语法呢？哪天发现其它语言的File简单，是不是也要为为File加个特殊语法？然后发现其它实现也要简化，就再为它设计特殊语法？
|
| 返回顶楼 | |
|
发表时间：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是不严谨的。 |
| 返回顶楼 | |
