wren
wren copied to clipboard
Implement an optional `mirror` module.
An attempt at implementing #1004, using a mirror module.
Not yet ready for merge.
Thought: Might be easier to review/read the changes if all the makefile auto-built changes weren't also included?
Yes and no.
First patch is an utility patch, second patch is the core of the patch, and third one is the premake update in isolation. If one want to review, the first one will hardly change, and the effort should be concentrated on the second one. premake update is required because of the new module. At best it is a reminder, and at worse an argument against having generated files in the git in the first place.
And personally, while I understand the motivations behind the inclusion of the generated files, their inclusion is a huge pain as it creates a fragmentation for contributions. I never know how to push changes that impacts premake generated files, because of differences between official and my local premake versions, and the fact it is required for the project build.
Ah, true your commit history is indeed very clean. That's not always the case (in general - perhaps it's better here in Wren) and I'm just so accustomed to using "Files changed" for reviews. :-)
Agree entirely with the "huge pain" comment... although it was a small pain to get the correct version of premake installed (it doesn't seem to be updated in homebrew), so I also see it as a mixed blessing/curse. Wish I had a suggestion.
Ignoring some changes that I developed in separated branches that I don't consider urgent for inclusion, my main branch is +200 patch ahead of main. So I'm "forced" to tidy my changes, so (check) rebasing is as seamless as possible.
Fixed a some issues I noticed. added patch to access Class attributes from ClassMirror.
Arff changed my mind, will have to have a minimal layer of MethodMirror support to provide access to attributes.
Since we don't expose setSlot(), I don't think we should rename it.
And I still think we should put it in the meta module: reflection is some kind of metaprogramming, too. And I don't see a reason to exclude one but not both.
Also, before we merge this PR, I think we need to have some way to actually invoke methods. I have some ideas, and would like to think about it a bit more.
Finally, what's the purpose of MethodMirror? It's not used at all!
setSlot must renamed, since it is not static anymore, the symbol will be leaked in the library.
MethodMirror is still a place holder as I hack the thing. eval is much more dangerous than the mirror API, and I want to be able to disable it.
The classMirror that's commented out on methodMirror would be super helpful, I'm trying to get a bit more detail in my stack traces akin to Node (showing both the class and function):
at Object.toEqual (rna-transcription.spec.js:17:24)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
While I agree, for now it is not possible because there is no pointer from the method to the class. I have to look how it impacts the vm.
What your code makes possible. :)
The only thing I needed to add:
class StackTrace {
frames { _stackTrace } // added
For accessing the raw frames so you can process them however you may want.
I have to think about that, because that way you can alter the stack trace, which is what I wanted to forbid.
So why not?
frames { _stackTrace[0..-1] }
Was more thinking at making it a readonly list like container.
To me it's just a list of items... once I have it I should be able to alter it, remove items, insert new items, it's MY list.. as long as I have a copy and I'm not messing with the canonical version or something bad.
I updated so you should be able to pull the class form the MethodMirror.
I also added a breaking change, that will trigger in debug mode when a Method is tried to be bound again.
For your last concern, you can do [].addAll( stackTrace ) so that it remains constant. But it raise the question of an ArrayedSequence abstraction that could be really useful here.
Avoid to update yet, I have some concerns about how MethodMirror works. I think I have to change the underlying data, to be based on a Class methodIndex pair, instead of direct Closure/Fn access, to be able to reference primitives.
Updated. Not final yet, but in better shape, and allows "MethodMirror" to perform calls (though it needs a little bit more security).
Silenced an issue, where method can be bound multiple times. While the grammar allow inner class definitions and the behavior is even tested, it is implemented incorrectly. For that behavior to be correct; the whole ObjFn should be duplicated and bound.
Fixed silenced issue thinko.