blob: d67d075c8b56844259650df91d35771084437166 [file] [log] [blame]
todo
----
"compiled" LangueSpecificMiddleEnd
move to m2t.common
compiler / registry of handlers for different kinds of resources (including classes and byte code (?)); classes need way to express/serialize their fdc!!! --> rethink fdc concept?
--> via extension point (with a static "priority" getter to allow ordering)? Compiled first?
JavaBeansType: Interfaces als Supertypen
Profiler
Protected Region Resolver
Classic
complete syslib: toUpper etc., List.sortBy(closure)
static properties; enums
kommentieren
dead code elimination?
syslib-Funktion: allFunctions (List<Type>) --> auch Funktionen ohne Parameter zur Laufzeit
finden (oder built-in? --> syslib-Aufruf verlässt den Scope)
Function-Match (z.B. &myFunc (String, Foo) --> spät binden! --> dynamisch durchgereichter Kram
wird gematcht
Currying
Properties über getter/setter abbilden (z.B. im mm keine property mehr)?
Eigene Properties definieren (d.h. generische Map dafür an jedem Objekt)?
"final" (auch als Hint für Optimierung --> wird nicht durch dynamische Exytensions
erweitert --> Tail Recursion geht nur dort)
Initialisierung der Functions mit FunctionDefContext: Nicht zwingend eager
in voller Tiefe, sondern lazy beim ersten Einstieg in eine neue CompilationUnit
zusätzlich zu statisch unterschiedenem this / Collection-Sonderfall außerdem
den generischen Fall --> aber nur dann (Ref-Typ "Object"), wenn es statisch
nicht entscheidbar ist. --> volle Rückwärtskompatibilität
Debugger: ein Source-Primitive kann aus mehreren Runtime-Primitives bestehen - in der RT
markieren, wo neuer Source-Primitive beginnt? Oder einfach Mapping in Rückrichtung
und vergleichen?
tail recursion
replace/add von Extensions im dynamischen Scope
Unterstützung
-------------
UML und EMF testen
Decisions
---------
Overwriting / hiding of functions is only posible for functions without guards (to avoid
the necessity of comparing guards for equality)
IteratorType is now handled via the Java type system
Only one global type system to avoid ambiguities when objects are passed from one compilation unit to another
Collection.remove, Collection.removeAll return a boolean instead of the collection now, same as the JDK implementations
many collection operations (e.g. "flatten") retain the collection type now instead of always returning a list
renamed "flatten" to "flattenedCopy"
removed Collection.forAll (--> duplicate for notExists) and List.sortBy (very special functionality)
JET support: JET templates are treated just like any other Java Bean
Ideen für die Zukunft
---------------------
"async" -Keyword --> Ausnutzung von Multicore???
statisch behandeln
----------------
hasThis etc. im FunctionDefContext statisch handeln?
"this"-Mehrdeutigkeit (welche Reihenfolge?)
Collection-Resolution-Mehrdeutigkeit
done
----
Interface ExecutionContextAware für Java-Extensions
cached
PolymorphicResolver
int / long: gnädig bei Java-Extensions
double / float: gnädig bei Java-Extensions
Array / List
optimierter String --> an Schnittstellen ggf. konvertieren
optimierter String --> hierarchische Dirty-Propagation nach oben
JavaBeansTypesystem
Konzept für FunctionType - braucht der Parametertypen!?
metaType etc.
EMF-Typesystem
setExecutionContext bei ExecutionContextAware nicht als exportierte Funktion behandeln
toString() überschreibbar, trotz lazy evaluation
Operators: implies, <, <=, ==, !=, >=, >, !, unary -,
potential bug - EfficientLazyString is mutable || return value from cached function -->
flag "isImmutable" in EfficientLazyString; static method "concat" insetad of "append" to treat this transparently
logNullDeRef: log call stack including call parameters - runtime flag to log "verbosely"?
Map als Builtin-Typ
globalVars rauswerfen? --> ContributionStateContext?
UML type system
equals auf Type-Implementierungen
new String --> ""
Optimierung: recursiveSupertypes initial ermitteln, speichern, bereitstellen & f. isAssignableFrom verwenden
AOP
Check
make the concept of the "XyzRegistry" explicit, common abstraction --> interoperability of languages