Replies: 4 comments
-
In particular, I'm thinking of adding three new opcodes, mirrors of |
Beta Was this translation helpful? Give feedback.
-
An initial experiment in The two failing cases are essentially: class Ca { field $x; method test { $x = 123; eval('$x') } } i.e. string-eval relying on being able to see the field at runtime, and class Cb { field $x; method test { $x = 123; return sub { $x } } } i.e. capture of a field into a non-method closure. I can't think of a solution to both of these that doesn't basically turn out to just be using the same lexical-pad trick as before. So it may turn out that the |
Beta Was this translation helpful? Give feedback.
-
Current approach is that |
Beta Was this translation helpful? Give feedback.
-
This is now entirely solved by the "field binding" part of OP_METHSTART, as described by #8. This issue can now be closed (if I could find the button to do that...) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
How should the optree inside a method body access the fields of the instance?
In
Object::Pad
I couldn't easily influence the way the parser would build, so about the only thing I could do was pretend that the lexical scope of every method in fact contained a whole bunch of extra lexicals, then arrange for all those extra pad slots to be SV-aliased to the relevant instance fields as part of method startup. It makes entry of every method somewhat slow, because it has to do all that aliasing.A real core implementation ought to do something a lot nicer.
Beta Was this translation helpful? Give feedback.
All reactions