Test two objects for inequality.
Test two objects for inequality.
true
if !(this == that), false otherwise.
Equivalent to x.hashCode
except for boxed numeric types and null
.
Equivalent to x.hashCode
except for boxed numeric types and null
.
For numerics, it returns a hash value which is consistent
with value equality: if two value type instances compare
as true, then ## will produce the same hash value for each
of them.
For null
returns a hashcode where null.hashCode
throws a
NullPointerException
.
a hash value consistent with ==
The expression x == that
is equivalent to if (x eq null) that eq null else x.equals(that)
.
The expression x == that
is equivalent to if (x eq null) that eq null else x.equals(that)
.
true
if the receiver object is equivalent to the argument; false
otherwise.
Cast the receiver object to be of type T0
.
Cast the receiver object to be of type T0
.
Note that the success of a cast at runtime is modulo Scala's erasure semantics.
Therefore the expression 1.asInstanceOf[String]
will throw a ClassCastException
at
runtime, while the expression List(1).asInstanceOf[List[String]]
will not.
In the latter example, because the type argument is erased as part of compilation it is
not possible to check whether the contents of the list are of the requested type.
the receiver object.
ClassCastException
if the receiver object is not an instance of the erasure of type T0
.
Create a copy of the receiver object.
Create a copy of the receiver object.
The default implementation of the clone
method is platform dependent.
a copy of the receiver object.
not specified by SLS as a member of AnyRef
Tests whether the argument (that
) is a reference to the receiver object (this
).
Tests whether the argument (that
) is a reference to the receiver object (this
).
The eq
method implements an equivalence relation on
non-null instances of AnyRef
, and has three additional properties:
x
and y
of type AnyRef
, multiple invocations of
x.eq(y)
consistently returns true
or consistently returns false
.x
of type AnyRef
, x.eq(null)
and null.eq(x)
returns false
.null.eq(null)
returns true
. When overriding the equals
or hashCode
methods, it is important to ensure that their behavior is
consistent with reference equality. Therefore, if two objects are references to each other (o1 eq o2
), they
should be equal to each other (o1 == o2
) and they should hash to the same value (o1.hashCode == o2.hashCode
).
true
if the argument is a reference to the receiver object; false
otherwise.
The equality method for reference types.
Called by the garbage collector on the receiver object when there are no more references to the object.
Called by the garbage collector on the receiver object when there are no more references to the object.
The details of when and if the finalize
method is invoked, as
well as the interaction between finalize
and non-local returns
and exceptions, are all platform dependent.
not specified by SLS as a member of AnyRef
A representation that corresponds to the dynamic class of the receiver object.
A representation that corresponds to the dynamic class of the receiver object.
The nature of the representation is platform dependent.
a representation that corresponds to the dynamic class of the receiver object.
not specified by SLS as a member of AnyRef
The hashCode method for reference types.
Test whether the dynamic type of the receiver object is T0
.
Test whether the dynamic type of the receiver object is T0
.
Note that the result of the test is modulo Scala's erasure semantics.
Therefore the expression 1.isInstanceOf[String]
will return false
, while the
expression List(1).isInstanceOf[List[String]]
will return true
.
In the latter example, because the type argument is erased as part of compilation it is
not possible to check whether the contents of the list are of the specified type.
true
if the receiver object is an instance of erasure of type T0
; false
otherwise.
Makes sense of cross-stage bindings.
Makes sense of cross-stage bindings.
Analysis of cross-stage bindings becomes convenient if we introduce the notion of metalevels. Metalevel of a tree is a number that gets incremented every time you reify something and gets decremented when you splice something. Metalevel of a symbol is equal to the metalevel of its definition.
Example 1. Consider the following snippet:
reify { val x = 2 // metalevel of symbol x is 1, because it's declared inside reify val y = reify{x} // metalevel of symbol y is 1, because it's declared inside reify // metalevel of Ident(x) is 2, because it's inside two reifies y.splice // metalevel of Ident(y) is 0, because it's inside a designator of a splice }
Cross-stage bindings are introduced when symbol.metalevel != curr_metalevel. Both bindings introduced in Example 1 are cross-stage.
Depending on what side of the inequality is greater, the following situations might occur:
1) symbol.metalevel < curr_metalevel. In this case reifier will generate a free variable that captures both the name of the symbol (to be compiled successfully) and its value (to be run successfully). For example, x in Example 1 will be reified as follows: Ident(newFreeVar("x", IntTpe, x))
2) symbol.metalevel > curr_metalevel. This leads to a metalevel breach that violates intuitive perception of splicing. As defined in macro spec, splicing takes a tree and inserts it into another tree - as simple as that. However, how exactly do we do that in the case of y.splice? In this very scenario we can use dataflow analysis and inline it, but what if y were a var, and what if it were calculated randomly at runtime?
This question has a genuinely simple answer. Sure, we cannot resolve such splices statically (i.e. during macro expansion of reify
),
but now we have runtime toolboxes, so noone stops us from picking up that reified tree and evaluating it at runtime
(in fact, this is something that Expr.splice
does transparently).
This is akin to early vs late binding dilemma. The prior is faster, plus, the latter (implemented with reflection) might not work because of visibility issues or might be not available on all platforms. But the latter still has its uses, so I'm allowing metalevel breaches, but introducing the -Xlog-runtime-evals to log them.
upd. We no longer do that. In case of a runaway splice
inside a reify
, one will get a static error.
Why? Unfortunately, the cute idea of transparently converting between static and dynamic splices has failed.
1) Runtime eval that services dynamic splices requires scala-compiler.jar, which might not be on library classpath
2) Runtime eval incurs a severe performance penalty, so it'd better to be explicit about it
As we can see, the only problem is the fact that lhs'es of splice
can be code blocks that can capture variables from the outside.
Code inside the lhs of an splice
is not reified, while the code from the enclosing reify is.
Hence some bindings become cross-stage, which is not bad per se (in fact, some cross-stage bindings have sane semantics, as in the example above). However this affects freevars, since they are delicate inter-dimensional beings that refer to both current and next planes of existence. When splicing tears the fabric of the reality apart, some freevars have to go single-dimensional to retain their sanity.
Example 2. Consider the following snippet:
reify { val x = 2 reify{x}.splice }
Since the result of the inner reify is wrapped in a splice, it won't be reified together with the other parts of the outer reify, but will be inserted into that result verbatim.
The inner reify produces an Expr[Int] that wraps Ident(freeVar("x", IntTpe, x)). However the freevar the reification points to will vanish when the compiler processes the outer reify. That's why we need to replace that freevar with a regular symbol that will point to reified x.
Example 3. Consider the following fragment:
reify { val x = 2 val y = reify{x} y.splice }
In this case the inner reify doesn't appear next to splice, so it will be reified together with x. This means that no special processing is needed here.
Example 4. Consider the following fragment:
reify { val x = 2 { val y = 2 val z = reify{reify{x + y}} z.splice }.splice }
The reasoning from Example 2 still holds here - we do need to inline the freevar that refers to x. However, we must not touch anything inside the splice'd block, because it's not getting reified.
Equivalent to !(this eq that)
.
Equivalent to !(this eq that)
.
true
if the argument is not a reference to the receiver object; false
otherwise.
Wakes up a single thread that is waiting on the receiver object's monitor.
Wakes up a single thread that is waiting on the receiver object's monitor.
not specified by SLS as a member of AnyRef
Wakes up all threads that are waiting on the receiver object's monitor.
Wakes up all threads that are waiting on the receiver object's monitor.
not specified by SLS as a member of AnyRef
Creates a String representation of this object.
Creates a String representation of this object. The default representation is platform dependent. On the java platform it is the concatenation of the class name, "@", and the object's hashcode in hexadecimal.
a String representation of the object.