|
锁定老帖子 主题：Scala拾趣--从Java7说开来
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-05-08
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实现。 |
| 返回顶楼 | |
|
发表时间：2008-05-08
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#怎么做的吧。 |
| 返回顶楼 | |
|
发表时间：2008-05-09
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可以有接口手动控制内存就好了 感觉现在很多问题都是内存泄露上 特别是小型系统 在小并发下，不考虑性能 效率，唯一问题就是内存泄露上 程序除了 人与 计算机的沟通外，无非是 功能，速度，稳定性 |
| 返回顶楼 | |
|
发表时间：2008-05-09
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来说做绝对是倒退，那些项目有内存泄漏是程序写的问题，大部分好的系统都没有这个问题，应该先从自己的身上找找原因。 关于get,set我只是提个建议，是针对JAVA引入property关键字。我认为annotation的方式比引入新的关键字更灵活，改动更小，更和谐。 |
| 返回顶楼 | |
|
发表时间：2008-05-09
Java核心应该保持简洁，高效就够了，
至于一些时髦的东西，各种语言都有自己的，Java怎么可能把所有其它语言的特性都加进来，这些特性就让其它运行JVM的语言来补充吧，如groovy,jruby, scala , jpython , php ,javafx等。 |
| 返回顶楼 | |
|
发表时间：2008-05-09
zbird 写道 Eastsun 写道 譬如JAVA5中的泛型。。。和鸡肋差不多。 可能实现得不太优雅，不过似乎还挺好用。 好用么。。。如果增加一次box和unbox能叫做好用的话 |
| 返回顶楼 | |
|
发表时间：2008-05-09
总的看来，Java 7将是C# 3.5的一次大抄袭而已。
|
| 返回顶楼 | |
|
发表时间：2008-05-09
ray_linn 写道 总的看来，Java 7将是C# 3.5的一次大抄袭而已。
说起“抄袭”，谁抄谁还不好说。 C#整个语言不就是模仿Java的么？ 现在这些特性还只是提议而已，最终会不会加到Java7中去还未有分晓。 除了闭包我不是太肯定需不需要加入到Java7中去，其他的特性我觉得还是不要加的为好。 保持Java的简洁优雅比加入那些乌七八糟的特性更重要，我以为。 |
| 返回顶楼 | |
|
发表时间：2008-05-09
Eastsun 写道 ray_linn 写道 总的看来，Java 7将是C# 3.5的一次大抄袭而已。
说起“抄袭”，谁抄谁还不好说。 C#整个语言不就是模仿Java的么？ 现在这些特性还只是提议而已，最终会不会加到Java7中去还未有分晓。 除了闭包我不是太肯定需不需要加入到Java7中去，其他的特性我觉得还是不要加的为好。 保持Java的简洁优雅比加入那些乌七八糟的特性更重要，我以为。 C#从1.0开始就保持了自己的创新，Java呢？从6。0开始，几乎是亦步亦趋，几乎看看C#，就可以知道下一个版本的Java大概会出现什么东西 |
| 返回顶楼 | |
|
发表时间：2008-05-09
icanfly 写道 Eastsun 写道 问题是如果需要兼容，就不太可能实现的很优雅
譬如JAVA5中的泛型。。。和鸡肋差不多。 以及将要加入的闭包，其实现方式也够呛。 这种打补丁式的改进总不会太完美。 PS：弄一个JAVA3000出来也不错，抛弃向后兼容性。 我同意，JAVA顾虑得太多，应该学学Python，要使用旧JAVA语法的用JAVA旧的版本，要使用新的语法可以用新的版本，这样不但JAVA类库中有些“鸡肋”可以踢除，本身语言简洁性也得到提高！希望JAVA语言的开发工程师们不要老停留在要兼顾以前版本的陈旧思想里了！ 严重同意，现在java的发展方向让人更迷茫 |
| 返回顶楼 | |
