Java 闭包类型、变量、数组和集合

发布于 2024-08-20 04:36:16 字数 1475 浏览 1 评论 0原文

Java 闭包规范的当前状态如何？

在提议的 Java 闭包规范中，我们是否能够创建一个数组或闭包集合？
如果是这样，这种语法可能吗？

{int x, int y =>;布尔 b}[] 比较开关 = {
  {int i, int j =>;返回 i>j}，
  {int i, int j =>;返回 j;返回 j==i}
}

布尔比较（int acase，int a，int b）{
  return ComparisonSwitch[acase].invoke(a,b);
}

普通方法会被视为非匿名闭包吗？
那么下面的语法可能吗？

公共类 Asdf
{
  公共布尔 gt(int x, int y){
    返回x>y；
  }
  公共布尔 lt(int x, int y){
    返回x布尔 b} GT = gt;
  {int x, int y =>布尔 b}[] 比较开关 = {
    gt、lt、eq
  }
}

即，闭包和方法在操作上可以互换吗？
允许使用以下语法吗？

// 声明一个以闭包类型作为参数的方法
void closurator( {String s => int a} findlen ){
  // 做任何事
}
字符串 s = "你好";
无效 useClosurator(){
  // 通过提供非匿名方法来调用该方法
  // 一个对象的
  闭包器(s.indexOf(String ss));
}

我们如何能够在接口中指定闭包类型？
我们可以执行以下操作，有效地声明对方法的最终/常量引用吗？

接口关闭
{
  公开课 Asdf
  {
    静态公共布尔 gt(int x, int y){
      返回x>y；
    }
    静态公共布尔 lt(int x, int y){
      返回x布尔 b}[] 比较开关 = {
    Asdf.gt、Asdf.lt、Asdf.eq
  };
}

既然闭包会访问代码空间，就像反射一样，那么使用闭包会降低程序的性能吗？如果不是，是否意味着借用“封闭技术”的进步可以加速反思？

插入新问题：实际上，闭包代码会是代码空间的一部分还是变量堆中，因为我预测闭包代码很容易被垃圾收集擦除，对吗？

我可以要求您关注问题的要点，而不是示例代码中的任何语法错误/拼写错误/缺少关键字。如有任何拼写错误/错误，请为我纠正。谢谢。

原文

What is the current state of spec for Java closure?

In the proposed Java closure spec, would we be able to
create an array or collection of closures?
If so, would this syntax be possible?

{int x, int y => boolean b}[] comparisonSwitch = {
  {int i, int j => return i>j},
  {int i, int j => return j<i},
  {int i, int j => return j==i}
}

boolean compare(int acase, int a, int b){
  return comparisonSwitch[acase].invoke(a,b);
}

Would normal methods be considered as non-anonymous closures?
So would the following syntax be possible?

public class Asdf
{
  public boolean gt(int x, int y){
    return x>y;
  }
  public boolean lt(int x, int y){
    return x<y;
  }
  public boolean eq(int x, int y){
    return x==y;
  }

  {int x, int y => boolean b} GT = gt;
  {int x, int y => boolean b}[] comparisonSwitch = {
    gt, lt, eq
  }
}

i.e., are closures and methods interchangeble operationally?
Would the following syntax be allowed?

// declare a method that has a closure type as an argument
void closurator( {String s => int a} findlen ){
  // do whatever
}
String s = "hello";
void useClosurator(){
  // invoke the method by supplying a non-anonymous method
  // of an object
  closurator(s.indexOf(String ss));
}

How would we be able to specify a closure type in an interface?
Could we do the following, effectively declaring final/constant reference to methods.

interface Closuration
{
  public class Asdf
  {
    static public boolean gt(int x, int y){
      return x>y;
    }
    static public boolean lt(int x, int y){
      return x<y;
    }
    static public boolean eq(int x, int y){
      return x==y;
    }
  }

  {int x, int y => boolean b}[] comparisonSwitch = {
    Asdf.gt, Asdf.lt, Asdf.eq
  };
}

Since closures would access code space, just as reflection would, would use of closure slow down the performance of a programme? If not, would it mean, that reflection would be sped up by borrowing advances made in "closure technology"?

Inserted new question:
Actually, would closure code be part of code space or in the variable heap, because I am predicting that closure code would be susceptible to be wiped off by garbage collection, right?

May I request you to focus on the gist of the questions, not on any syntax errors/typos/missing keywords in the example code. Any typos/errors, please correct them for me. Thank you.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一影成城 2024-08-27 04:36:16

您询问的是 JDK7 闭包工作，因此对 javac.info 的引用不相关。该网站是关于现已完成的 openjdk 闭包项目，该项目展示了如何向 Java 添加透明闭包 - 满足 Tennent 对应原则意义上的透明度，并在 < a href="http://gafter.blogspot.com/2007/01/definition-of-closures.html" rel="nofollow noreferrer">我的博客。

JKD7 的工作是在 openjdk lambda 项目下组织的。该规范正在快速发展，因此任何答案都是暂定的。正如 Tom Hawtin 指出的那样，这是最新的草案规范。

在回答您的具体问题之前，值得注意的是 Java 对于变量和方法有单独的命名空间。因此，调用方法和调用函数类型的变量（用 C# 的说法是委托）之间可能存在一些语法区别。同样，您不可能像引用字段那样仅通过命名来引用方法。

回答您的问题：

这不是函数类型的建议语法。抛开这个问题不谈，您想知道拥有函数类型数组是否合法。当前的规范草案表明答案是肯定的，但已知的实现策略将导致类型系统中出现漏洞，除非以某种方式不允许“函数类型数组”。规范草案小心翼翼地避免讨论实施策略。可以通过更改虚拟机规范来解决这些问题。如果我必须猜测，我怀疑你问题的答案将是“否”。但是，您可以使用 java.util.List 而不是数组来实现相同的效果。鉴于单独的项目Coin正在考虑添加Collection 文字和 List 的索引操作，在语法上可能同样方便。
您想知道是否将通过命名方法来创建函数值表达式。因为（以及其他原因）方法和变量出现在 Java 中的不同名称空间中，所以答案可能是否定的。但是，该规范可能会使用特定语法进行扩展，以要求将方法名称视为函数值表达式。请参阅文档 Closures for Java (v0.6a ) 是一种可以考虑的方法，使用 Stephen Colebourne 提出的语法。这还没有出现在 lambda 项目的任何草案中。
参见(2)的答复。
参见(2)的答复。
您关心的是性能。简而言之，不太可能使用任何导致闭包调用比方法昂贵得多的技术来实现闭包。出于性能原因不需要更改虚拟机，尽管出于其他原因更改虚拟机可能是个好主意（请参阅问题 1 的答案）。请参阅闭包项目主页，获取 BGGA 原型的指针，这是一个更雄心勃勃的闭包规范，运行于库存jdk5/jdk6，您可以衡量其性能。

You're asking about the JDK7 closures work, so references to javac.info are not relevant. That site is about the now-completed openjdk closures project, which showed how to add transparent closures to Java - transparency in the sense of satisfying Tennent's Correspondence Principle and described roughly in my blog.

The effort for JKD7 is organized under the openjdk lambda project. The specification is undergoing rapid evolution, so any answers are tentative. As Tom Hawtin pointed out, here is the latest draft spec.

Before answering your specific questions, it is worth observing that Java has separate namespaces for variables and methods. Consequently, there is likely to be some syntactic distinction between invoking a method and invoking a variable of function type (in C# parlance, a delegate). Similarly, it is unlikely you will be able to refer to a method by just naming it, as you would to refer to a field.

To answer your questions:

That is not the proposed syntax for a function type. Setting that issue aside, you're wondering if it will be legal to have an array of function type. The current draft specification suggests that the answer is yes, but the known implementation strategies would result in a hole in the type system unless "array of function type" is somehow disallowed. The draft specification carefully avoids discussing implementation strategies. It is possible that VM spec changes could be made to address these issues. If I had to guess, I suspect the answer to your question will be "no". However, you would be able to achieve the same effect using java.util.List instead of an array. Given that the separate project Coin is considering adding Collection literals and indexing operations for List, it is likely to be just as syntactically convenient.
You're wondering if you will be create a function-valued expression by naming a method. Because (among other reasons) methods and variables appear in different namespaces in Java, the answer is probably no. However, it is possible that the specification will be extended with a specific syntax for asking that a method name be treated as a function-valued expression. See the section Method References in the document Closures for Java (v0.6a) for one way that might be considered, using a syntax proposed by Stephen Colebourne. This is not yet in any draft of project lambda.
See answer to (2).
See answer to (2).
You're concerned about performance. In short, it is unlikely that closures would be implemented with any techniques that cause them to be much more expensive to invoke than a method. No VM changes are required for performance reasons, though they might be a good idea for other reasons (see answer to 1). See the Closures Project homepage for a pointer to a prototype of BGGA, a more ambitious closures specification, which runs on stock jdk5/jdk6, and whose performance you can measure.