@elidable 注释在 Scala 中有什么作用，我应该什么时候使用它?

本文介绍了@elidable 注释在 Scala 中有什么作用，我应该什么时候使用它?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我注意到在一些 Scala 库代码中，特别是 Predef，有这样的代码:

I've noticed in some of the scala library code, notably Predef, there is code like:

/** Tests an expression, throwing an `AssertionError` if false.
*  Calls to this method will not be generated if `-Xelide-below`
*  is at least `ASSERTION`.
*
*  @see elidable
*  @param p   the expression to test
*/
@elidable(ASSERTION)
def assert(assertion: Boolean) {
if (!assertion)
  throw new java.lang.AssertionError("assertion failed")
}

这个注解允许我在编译时消除代码.当我使用 -Xelide-below MAXIMUM 进行编译时，是否

This annotation allows me, at compile time, to eliminate code. When I compile with -Xelide-below MAXIMUM, does it

删除该方法及其所有调用?(如果是这样，如果另一个库希望这个方法在那里会发生什么?)，我们是否得到 NoSuchMethodError 或其他什么?
将方法留在那里，但从方法中删除所有代码，留下一个空方法?
只是删除对方法的调用，但将方法留在那里?

我可以用它来减少类的编译大小吗?所以如果我有:

Can I use it to reduce the compiled size of the class? So if I had:

class Foobar {
    // extremely expensive toString method for debugging purposes
    @elidable(FINE) def toString(): String = "xxx"
}

并使用 -Xelide-below WARNING 编译，这个类中的 toString 会完全消失吗?请注意，在此示例中，我希望从类中删除该方法，因为我不希望它被调用.

and compiled with -Xelide-below WARNING would the toString in this class disappear altogether? Note that in this example, I would want the method to be removed from the class, because I wouldn't want the possibility of it being called.

第二部分:我看到它建议这用于消除调试日志代码.鉴于大多数框架(尤其是 log4j)允许运行时设置日志记录级别，我认为这不是一个好的用例.就个人而言，我希望保留此代码.那么除了 Predef 中的 assert() 方法，@elidable 有什么好的用例?

Second part: I've seen it suggested that this be used for eliminating debugging logging code. Given that most frameworks (log4j notably) allow runtime setting of logging level, I don't think that this is a good use case. Personally, I would want this code to be kept around. So apart from the assert() methods in Predef, what is a good use case for @elidable?

简短回答

方法和对它的所有调用都会消失.这可能是用于日志记录的好主意，因为每个日志记录框架都会在调用日志记录但禁用给定级别(计算有效级别并准备参数)时引入一些开销.

Short answer

Both method and all calls to it simply disappear. This might be a good idea to use for logging since every logging framework introduces some overhead when logging is called but a given level is disabled (computing the effective level and preparing arguments).

请注意，现代日志框架试图尽可能地减少这种占用空间(例如 Logback 优化了 is*Enabled() 调用和 SLF4S 按名称传递消息以避免不必要的字符串连接).

Note that modern logging frameworks try to reduce this footprint as much as possible (e.g. Logback optimizes is*Enabled() calls and SLF4S passes message by name to avoid unnecessary string concatenations).

我的测试代码:

import scala.annotation.elidable
import scala.annotation.elidable._

class Foobar {
    info()
    warning()

    @elidable(INFO) def info() {println("INFO")}
    @elidable(WARNING) def warning() {println("WARNING")}
}

证明 -Xelide-below 800 两个语句都打印出来，而 900 只出现 "WARNING".那么引擎盖下会发生什么?

Proves that with -Xelide-below 800 both statements are printed while with 900 only "WARNING" appears. So what happens under the hood?

$ scalac -Xelide-below 800 Foobar.scala && javap -c Foobar

public class Foobar extends java.lang.Object implements scala.ScalaObject{
public void info();
//...

public void warning();
//...

public Foobar();
  Code:
   0:   aload_0
   1:   invokespecial   #26; //Method java/lang/Object."<init>":()V
   4:   aload_0
   5:   invokevirtual   #30; //Method info:()V
   8:   aload_0
   9:   invokevirtual   #32; //Method warning:()V
   12:  return
}

如您所见，这可以正常编译.但是，当使用此指令时:

As you can see this compiles normally. However when this instruction is used:

$ scalac -Xelide-below 900 Foobar.scala && javap -c Foobar

调用 info() 并且方法本身从字节码中消失:

calls to info() and the method itself disappears from the bytecode:

public class Foobar extends java.lang.Object implements scala.ScalaObject{
public void warning();
//...

public Foobar();
  Code:
   0:   aload_0
   1:   invokespecial   #23; //Method java/lang/Object."<init>":()V
   4:   aload_0
   5:   invokevirtual   #27; //Method warning:()V
   8:   return

}

我希望 NoSuchMethodError 在运行时被抛出，当从针对 Foobar 版本编译的客户端代码中调用删除的方法时，elide-below临界点 .它也闻起来像旧的 C 预处理器，因此在使用 @elidable 之前我会三思而后行.

I would expect that NoSuchMethodError is thrown at runtime when removed method is called from client code compiled against Foobar version with lower elide-below threshold . Also it smells like good old C preprocessor, and as such I would think twice before employing @elidable.

这篇关于@elidable 注释在 Scala 中有什么作用，我应该什么时候使用它?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

我应该什么时候使用它