8000 progress · pathikrit/scala.github.com@2476e68 · GitHub
[go: up one dir, main page]
Skip to content

Commit 2476e68

Browse files
heathermillerheathermiller
committed
progress
1 parent 2ec9f76 commit 2476e68

File tree

3 files changed

+87
-8
lines changed

3 files changed

+87
-8
lines changed

‎overviews/reflection/annotations-and-others.md

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -6,8 +6,6 @@ partof: reflection
66
num: 5
77
---
88

9-
Coming soon!
10-
119
## Annotations
1210
## Constants
1311
## FlagSets

‎overviews/reflection/overview.md

Lines changed: 73 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -7,14 +7,81 @@ num: 1
77
outof: 6
88
---
99

10-
## Scala Reflection
10+
**Eugene Burmako, Heather Miller**
1111

12-
And what it provides over Java reflection.
12+
*Reflection* is the ability of a program to inspect, and possibly even modify
13+
itself at runtime. It has a long history across object-oriented, functional,
14+
and logic programming paradigms, with each paradigm evolving its own,
15+
sometimes markedly different, *status quo* for reflection. While more
16+
functional programming languages like Lisp/Scheme have focused primarily on
17+
reification to enable tasks like dynamic interpretation, object-oriented
18+
programming languages like Java have focused primarily on runtime reflection to
19+
enable tasks like the inspection and/or invocation of class members at runtime.
1320

14-
## Macros
21+
Three principal use cases of reflection across languages and paradigms are:
1522

16-
Relation between Scala Reflection and macros
23+
1. **Runtime Reflection**. The ability to inspect and invoke runtime types and their members.
24+
2. **Compile-time Reflection**. The ability to access and manipulate abstract syntax trees at compile time.
25+
3. **Reification**. The generation of abstract syntax trees at runtime in the case of (1), or at compile time in the case of (2).
1726

18-
## Environment (subsection title TBD)
27+
Until 2.10, Scala has not had any reflection capabilities of its own. Instead,
28+
one could use Java reflection which provided a very limited subset of runtime
29+
reflection capabilities from point (1) above. Many Scala-specific types are
30+
simply unrecoverable under standalone Java reflection; including info about
31+
runtime existential, higher-kinded, path-dependent and abstract types. In
32+
addition to these Scala-specific types, Java reflection is also unable to
33+
recover runtime type info of Java types that are generic at compile-time; a
34+
restriction that carried through to runtime reflection on generic types in
35+
Scala.
1936

20-
Some high-level picture of how to think about reflection- which inevitably involves universes and mirrors.
37+
In 2.10, Scala Reflection was introduced not only to address the shortcomings
38+
of Java's runtime reflection on Scala-specific and generic types, but to also
39+
add a more powerful toolbox of general reflective capabilities to Scala. Along
40+
with full-featured runtime reflection for Scala types and generics (1), 2.10 also
41+
ships with compile-time reflection capabilities, in the form of
42+
[Scala Macros]({{site.baseurl }}/overviews/macros.html) (2), as well as the
43+
ability to *reify* Scala expressions into Scala abstract syntax trees (3).
44+
45+
## Runtime Reflection
46+
In Scala runtime reflection, you can get types. Whereas in Java, you can only get classes.
47+
`isAsssignableFrom` - is B a subclass of A (you can do basic subtyping checks with Java)
48+
`getType` returns a `Class` object
49+
^ is this a valid point to make still?
50+
51+
- Get around erasure with Scala reflection.
52+
53+
#### Classes vs Types
54+
55+
Why are types more powerful than classes
56+
^ is this a valid or worthwhile point to make?
57+
58+
Java's type system is so simple that a class is essentially a type- the only exception is when you have generic types. This use case isn't fully supported by Java reflection.
59+
60+
In Scala, one can create an array of a generic type in Scala but not in Java- it uses reflection (i.e. ClassTags) only internally.
61+
62+
If you use Java reflection, you get a view that's restricted to what can be represented in a Java `Class` instance.
63+
For example, I can't find the self type of a trait that I'm examining using Java reflection.
64+
65+
### Some Examples
66+
67+
What is meant by runtime reflection. Examples.
68+
Some of the typical things that you can do with Scala reflection. This should also list things that aren't possible to do in Java.
69+
70+
## Compile-time Reflection
71+
72+
Macros. Brief intro.
73+
Reflection is the window to *Metaprogramming*, the ability for programs to modify themselves at runtime. Scala macros are an example of this.
74+
75+
### Some Examples
76+
77+
## Preliminaries
78+
### Universes
79+
### Mirrors
80+
81+
## TypeTags/ClassTags Generic Arrays
82+
83+
def m[T: TypeTag](x: T): Unit = {
84+
...
85+
}
86+
87+
This is a use of reflection because you're explicitly requesting to get runtime type information for T.

‎overviews/reflection/symbols-trees-types.md

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,8 +5,22 @@ title: Symbols, Trees, and Types
55
partof: reflection
66
num: 3
77
---
8+
9+
Scala reflection can be thought of in two ways.
10+
11+
Scala reflection does three things:
12+
13+
First, we differentiate what
14+
15+
Scala has been missing its own reflection for some time. Scala Reflection offers
16+
What can be done with `Symbol`s, `Tree`s, and `Type`s.
17+
818
## Symbols
919

20+
Symbols can be thought of as the heart of . While those with might find the concept of Symbols to , those without experience with compiler development might be intimidated.
21+
22+
Symbols have a number of things- they contain a name (`Name`), a type (`Type`), an owner (the `Symbol` of what is enclosing `this` `Symbol`), some flags, etc. It's also important to remember that `Symbol`s are mutable.
23+
1024
## Trees
1125

1226
## Types

0 commit comments

Comments
 (0)
0