You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A rudimentary reflection had been implemented, but it's kind of mess and probably requires a full rewrite, but first we need to find out some overlooked aspects.
TODOs
Option to create instance of a class (eg. by name)
Publish full type system
Add target language-specific and canonized names (and maybe even source lang names - as those will be used in strings for getting classes / fields / methods, but if the source code contains more than one compilation units, then parts can be compiled from different languages, so there is no "source lang")
Support inheritance (if once we add inheritance to OneLang at first place)
Make differences disappear between languages (eg. currently C# lists inherited Object methods in the GetMethods() call: Equals, ToString, etc)
Canonized name (used by lookup functions) should handle the difference between field and _field (or the compiler should prevent generation of fields with conflicting names like these)
Fix canonized name implementation (or the lack of) in some languages (lower casing is not enough, we have to remove underscores too!)
Write tests
Using native reflection vs. lambdas
The current implementation tries to use native reflection where it can. Some languages does not have native reflection (eg. C++), or it allows only reflect instances, so no static field / method information is available (eg. Swift) or static is not understood in that language, OneLang uses fake static members (eg. Go).
The pros of using native reflection can be the source and compiled code size, maybe performance. As they usually don't require too much generated code, in the best case only the list of reflected classes have to be registered, so it's easy to manually modify the generated code.
On the other hand if we want to publish OneLang field / class "attributes" (attributes in C#, decorators in TypeScript, etc), and complete Type metadata (including canonized and language-specific names) then we have to generate tons of code anyway.
At the end maybe the only difference will be the setter / getter / caller / initiator lambdas. If we go that way, and use lambdas in every language then the whole reflection will work the same way and maybe it will be even faster (as the JIT can compile fast code instead of a dynamic, name-based field / method access code).
The text was updated successfully, but these errors were encountered:
A rudimentary reflection had been implemented, but it's kind of mess and probably requires a full rewrite, but first we need to find out some overlooked aspects.
TODOs
C#
lists inheritedObject
methods in theGetMethods()
call:Equals
,ToString
, etc)field
and_field
(or the compiler should prevent generation of fields with conflicting names like these)Using native reflection vs. lambdas
The current implementation tries to use native reflection where it can. Some languages does not have native reflection (eg.
C++
), or it allows only reflect instances, so no static field / method information is available (eg.Swift
) or static is not understood in that language, OneLang uses fake static members (eg.Go
).The pros of using native reflection can be the source and compiled code size, maybe performance. As they usually don't require too much generated code, in the best case only the list of reflected classes have to be registered, so it's easy to manually modify the generated code.
On the other hand if we want to publish OneLang field / class "attributes" (attributes in C#, decorators in TypeScript, etc), and complete Type metadata (including canonized and language-specific names) then we have to generate tons of code anyway.
At the end maybe the only difference will be the setter / getter / caller / initiator lambdas. If we go that way, and use lambdas in every language then the whole reflection will work the same way and maybe it will be even faster (as the JIT can compile fast code instead of a dynamic, name-based field / method access code).
The text was updated successfully, but these errors were encountered: