Open heretique opened 6 years ago
Bob said that he wanted wren to be "leaf only" (wren call C, C does not call wren). I think it's (or was) because of reentrancy problems. I don't know if that changed since (now that C can call wren handles). But I'm 100% for overriding C in wren.
Can someone who has a good understanding of wren's inner workings suggest a way of adding these features (foreign to foreign inheritance and inheritance from foreign). I want to try and add these myself in my fork but I don't have experience writing interpreters. I started reading @munificent's book "Crafting Interpreters", which is really good btw, but I still need a lot of guidance.
I'm currently working around this by making the base class a Wren class with no fields, just methods, and making the underlying structure a tagged union. It's awfully inconvenient, though, and I have to jump through a bit in the call-Wren-from-C interface to confirm the super type for further processing (I really wish there was a C interface for getting the string type name of a slot).
So yeah, put me down as a +1 for this.
Hi, I have a question that arises from a use case I have found while implementing a toy game engine using wren as scripting language. Suppose I have a foreign base
Node
class and a foreignSpatial
class that inheritsNode
. In wren I will have to duplicate and bind all the base class methods for each foreign subclass I want to expose to wren, adding a lot of error prone boilerplate. What would be the arguments against foreign class inheritance likeforeign class Spatial is Node
? Is it not supported because lack of time or some other technical impediments? Also what would be the arguments against subclassing from a foreign class directly in wren, something like:This is also a use case that I found a work around for, but would have been much easier (I think) if I could extend nodes directly in wren (a la Godot GDScript) without going the Unity's "MonoBehaviour" route.