| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are too many potential optimizations unavailable to us due to the
lack of bright lines among different kinds of symbols. For instance the
difference between a TypeSymbol which represents a type alias and one
which represents an abstract type is only whether the DEFERRED flag
is set. This creates issues.
1) There are many (many) places where tests are performed on every symbol
which could be done more efficiently and (especially) more verifiably
correctly with polymorphism.
2) TypeRefs based on those symbols are also checking that flag
constantly, in perpetuity. A symbol created as an alias is never (to the
best of my knowledge) going to intentionally morph into one representing
an abstract type, nor vice versa.
3) One has no guarantees, because anyone can set or reset the DEFERRED
flag at any time.
So tackling more than one problem at once herein:
1) I created canonical symbol creation points which take the flags as
an argument, so that there can be a difference between initializing a
symbol's flags and setting/resetting them at arbitrary times.
2) I structured all the symbol creators to take arguments in the
same order, which is:
def newXXX(name: Name, ..., pos: Position = NoPosition, flags: Long = 0L)
(Where "..." is for those symbols which require something
beyond the name to create, such as a TypeSkolem's origin.)
The name is first because it's the only always required argument.
I left but deprecated the variations which take (pos, name).
3) I created subclasses of TypeRef based on the information which
should be stable from creation time onward:
- args or no args?
- abstract type, type alias, or class?
2x3 == 6 and that's how many subclasses of TypeRef there are now. So
now, for example, every TypeRef doesn't have to carry null symInfoCache
and thisInfoCache fields for the benefit of the minority which use them.
I still intend to realize the gain possible once we can evade the fields
for pre and args without losing pattern matcher efficiency.
|
