Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reflection #7

Open
8 tasks
koczkatamas opened this issue Dec 30, 2017 · 0 comments
Open
8 tasks

Reflection #7

koczkatamas opened this issue Dec 30, 2017 · 0 comments
Assignees

Comments

@koczkatamas
Copy link
Collaborator

koczkatamas commented Dec 30, 2017

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).

@koczkatamas koczkatamas self-assigned this Dec 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant