This project is read-only.

TypeScript core

Topics: General, Language Specification
Mar 26, 2014 at 3:01 PM
first of all i would like to thank all the typescript team for your work
you made an awesome implementation!

i saw alot of requests for reflection, method overloading, extension methods and such

i think that the best way to solve those issue
is actually exactly what you have been doing
through javascript api's (TypeScript object)

but instead of combining everything together why not breaking those issues into multiple objects and divide the responsibilities ?

smth like FormatterServices for code conversion (runtime eval;TS to JS)
Reflection for runtime code information

for instance i understand (in a large view) the problems of making methods (class functions) overloadable because of the type checking that should will occur at runtime
this could be avoided by using metadata of the method call on TS
so that the actual function call on javascript will not rely on type checking
but instead on the hardcoded 'reference' to the said method

if the code was compiled by calling the method X (a:number)

then it will be parsed to call(X, args, signature) from inside a catch all method with the same name

i understand that while i have good arguments i do not see the big picture and that there are other things to consider
however i do feel that typescript is a .NET like thinking in solving a particular problem
(OOP key feature) and that instead of simply ignore some of the runtime aspects developers require, typescript should face this problem head on by implementing a model in which we address to our TS code in JS runtime by a set of certain objects and resources that will completely simplify that task
whether it is reflection or some kind of prototype linking (method overloading).

thanks to whomever devoted the time in reading my suggestion

mazor vanunu