Just a general note here: I expect that this will eventually force the divergence of TclOO-as-extension (deliberately kept as targetting 8.5 for now) and TclOO-in-Tcl (deliberately focussed on 8.6 and later). I *believe* the hooks are in there to allow this to be done gracefully, with extensions compiled against TclOO 0.5 (external) able to still work when loaded into the 8.6 version even after this is done (can just bump the method type structure version number).
Now the matter of the general plan for how to do this. Two parts really I believe.
1) Make the core of TclOO support NRE methods
2) Make NRE-enabled method implementations (not all method impls need this)
Can't tackle 2 until 1 is done. Need to examine how NRE works first.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe (1) is not needed: TclOO already "supports" NRE methods, in the sense that they should run properly without TclOO ever noticing that they're NRE enabled.
What is required is step (2): teaching TclOO to evict the C stack while the methods are running.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Umm, no. TclOO currently uses a fair bit of C-stack allocated space to store temporary data that needs to be acted on both before and after a method body has run. Because of that, I believe that TclOO needs (1) more than (2). Once that's done, it should be possible to allow third-party NRE-aware method implementations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
everything done now except for constructors and destructors
Constructors are tricky. They need a bit more thought.
Destructors are much trickier. They currently run in a command delete trace, so probably can't be NRE-enabled at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=79902
Originator: NO
Just a general note here: I expect that this will eventually force the divergence of TclOO-as-extension (deliberately kept as targetting 8.5 for now) and TclOO-in-Tcl (deliberately focussed on 8.6 and later). I *believe* the hooks are in there to allow this to be done gracefully, with extensions compiled against TclOO 0.5 (external) able to still work when loaded into the 8.6 version even after this is done (can just bump the method type structure version number).
Now the matter of the general plan for how to do this. Two parts really I believe.
1) Make the core of TclOO support NRE methods
2) Make NRE-enabled method implementations (not all method impls need this)
Can't tackle 2 until 1 is done. Need to examine how NRE works first.
Logged In: YES
user_id=148712
Originator: YES
I believe (1) is not needed: TclOO already "supports" NRE methods, in the sense that they should run properly without TclOO ever noticing that they're NRE enabled.
What is required is step (2): teaching TclOO to evict the C stack while the methods are running.
Logged In: YES
user_id=79902
Originator: NO
Umm, no. TclOO currently uses a fair bit of C-stack allocated space to store temporary data that needs to be acted on both before and after a method body has run. Because of that, I believe that TclOO needs (1) more than (2). Once that's done, it should be possible to allow third-party NRE-aware method implementations.
Logged In: YES
user_id=148712
Originator: YES
I may misunderstand what you mean by (1); but TclOO runs nicely now, even when the methods are procs (ie, NRE enabled)
Logged In: YES
user_id=79902
Originator: NO
everything done now except for constructors and destructors
Constructors are tricky. They need a bit more thought.
Destructors are much trickier. They currently run in a command delete trace, so probably can't be NRE-enabled at all.
Logged In: YES
user_id=79902
Originator: NO
Constructors done; giving up on destructors.