Rework reflections #4
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Also, added contracts and support packages as peed dependencies.
This component will be removed, since most of its current utility methods are replaced by the support package's objects utils.
Reflection utilities will, for now at least, be added directly into the support package, so that circular dependencies can be prevented - e.g. a possible future port of the "callback reference", which could benefit from reflections.
Desired features are going to be added in the support package, in the reflections submodule.
In the case of anonymous classes, the name will be undefined.
There is no point in having a Reflection object know anything about how it is being stored inside meta, nor how it should be populated.
Also added as weak reference and modified the encoder to also handle owner property.
Caused by poor merge of Changelog
Internally, a weak reference is kept. But when accessing the property, the object should be returned, if no garbage collected.
Shows that obtaining nested object properties inside an array works.
This also shows that working with array index / keys, when setting or checking for existence works as intended.
The new decorate is based on the experimental @reflect() decorator (which will be removed) and is able to associate a target with specific metadata, by storing a reference address to the owning class and metadata key (prefix), where it can be retrieved again. It works for classes and class methods, but sadly some inheritance will not work as desired for static methods, due to no late "this" binding in static blocks or members.
The @reflect() decorator, along with all related components are now no longer needed. The idea was "good", but very cumbersome and possible too performance demanding. The new @targetMeta() decorator has taken the best out of this experiment and can now be used to associate metadata directly with class methods, which is good enough for now. Developers can use it to store their own "reflection-like" data as metadata, if needed.
In the end, the caching mechanism might not perform as desired. In large applications, with many classes that are tested, new entries will just be added to the WeakMap and possibly never truly removed / garbage collected.
Also, refactored inherit test of static method meta.
Due to the context kind enum, an array was created with several "undefined" entries, which would end up wasting a bit more memory per class' target metadata.
Intended for inheriting target meta of static methods, in situations when these are overwritten in sub-classes.
Hopefully this decreases the overall memory usage of storing the keys / paths to actual metadata a lot.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR started out with an idea to add a
@reflect()decorator that could store parts of the decorator context as metadata. However, this proved to be way too cumbersome and the benefits were not as desired. So, instead, a simplyisConstructor()implementation was added instead which is able to determine if a target can be invokednew, based on theFunction.isCallable() / Function.isConstructor()proposal. The source is heavily inspired by that of Core-JS.In addition, a new
targetMeta()decorator has been added, which is able to associate metadata directly with a target element, e.g. class instance or method reference.See the docs and
CHANGELOG.mdfor additional details.