Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commita23bfb8

Browse files
committed
copied text about TypeCreator and TreeCreator from scaladoc comments
1 parent4d0eedf commita23bfb8

File tree

1 file changed

+43
-0
lines changed

1 file changed

+43
-0
lines changed

‎overviews/reflection/architecture.md

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,3 +5,46 @@ title: Architecture
55
partof:reflection
66
num:6
77
---
8+
9+
===TreeCreator===
10+
A mirror-aware factory for trees.
11+
12+
In the reflection API, artifacts are specific to universes and
13+
symbolic references used in artifacts (e.g.`scala.Int`) are resolved by mirrors.
14+
15+
Therefore to build a tree one needs to know a universe that the tree is going to be bound to
16+
and a mirror that is going to resolve symbolic references (e.g. to determine that`scala.Int`
17+
points to a core class`Int` from scala-library.jar).
18+
19+
`TreeCreator` implements this notion by providing a standalone tree factory.
20+
21+
This is immediately useful for reification. When the compiler reifies an expression,
22+
the end result needs to make sense in any mirror. That's because the compiler knows
23+
the universe it's reifying an expression into (specified by the target of the`reify` call),
24+
but it cannot know in advance the mirror to instantiate the result in (e.g. on JVM
25+
it doesn't know what classloader use to resolve symbolic names in the reifee).
26+
27+
Due to a typechecker restriction (no eta-expansion for dependent method types),
28+
`TreeCreator` can't have a functional type, so it's implemented as class with an apply method.
29+
30+
===TypeCreator===
31+
A mirror-aware factory for types.
32+
33+
In the reflection API, artifacts are specific to universes and
34+
symbolic references used in artifacts (e.g.`scala.Int`) are resolved by mirrors.
35+
36+
Therefore to build a type one needs to know a universe that the type is going to be bound to
37+
and a mirror that is going to resolve symbolic references (e.g. to determine that`scala.Int`
38+
points to a core class`Int` from scala-library.jar).
39+
40+
`TypeCreator` implements this notion by providing a standalone type factory.
41+
42+
This is immediately useful for type tags. When the compiler creates a type tag,
43+
the end result needs to make sense in any mirror. That's because the compiler knows
44+
the universe it's creating a type tag for (since`TypeTag` is path-dependent on a universe),
45+
but it cannot know in advance the mirror to instantiate the result in (e.g. on JVM
46+
it doesn't know what classloader use to resolve symbolic names in the type tag).
47+
48+
Due to a typechecker restriction (no eta-expansion for dependent method types),
49+
`TypeCreator` can't have a functional type, so it's implemented as class with an apply method.
50+

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp