Introduce abstract class FunctionReference, which is supposed to be a
superclass for all anonymous classes generated for function references. Each
anonymous subclass will have statically-generated symbol info, which will be
used by reflection to locate the symbol
It has its arity precomputed, as opposed to the future KFunctionImpl inheriting
from FunctionImpl, for which the computation of arity can take some time and so
it shouldn't be passed in the constructor and saved as a field
It's need to add synthetic argument (of type that user can't use)
to constructors with default arguments to avoid clashing with
real user's constructor having the same set of parameters
and additional int's arguments.
Reflection will be distributed in a separate jar and not in kotlin-runtime.jar
for two primary reasons:
- Reflection implementation at the moment takes almost 2Mb
- Separate libraries for separate features is a technique encouraged by Maven,
and it's inconvenient to make it different in the compiler distribution
The former name clashes with java.lang.IllegalAccessException and proved to be
inconvenient because it should always be qualified in the source.
Also use java.lang exception's message as kotlin.reflect exception's message
Generate K*Function as a supertype for a function reference instead of
K*FunctionImpl; this will allow one binary library to be used with or without
reflection
Introduce an abstract factory class ReflectionFactory which is responsible for creating
reflection objects (KClass, KProperty, ...). The meaningful implementation is
located in "reflection.jvm" where KClassImpl/KPropertyImpl/... are accessible
and can be instantiated. The default implementation will be used in the lite
runtime with no reflection and will return nulls / throw exceptions there.
Put all functions, calls to which are generated by JVM back-end, in one place:
the class named Reflection which contains only static methods. Previously these
functions were scattered across different files in module "reflection.jvm".
The code using reflection may now be compiled against either runtime, but
reflection features will work if and only if reflection is accessible at
runtime
This is not something that needs to be intrinsified. Note that compiler
optimizations are still possible and the fact whether 'indices' is a member or
an extension is irrelevant to the optimizer
Alexander Udalov