Your analysis is correct: DynamicVariables are hard to impossible to debug, the debugger always runs in another process. I don't think there is a solution here (maybe let the debugger process copy/share the binding ?) apart from what you suggest: make sure you enter the debugger after the lookup and assignment of the value to a local variable.
server := ZnCurrentServer value. Still, I find DynamicVariables very useful, especially architecture/design-wise. On 23 Jun 2014, at 13:50, Norbert Hartl <[email protected]> wrote: > In my code I'm using a DynamicVariable to request a context object when > needed. Until now I knew the name DynamicVariable only from seaside. There it > is called WADynamicVariable and it is an exception. So I blindly assumed the > pharo DynamicVariable works the same. > I thought this might be a good optimization not to travel the stack all the > time but put in the process. > Now that I am using it I can see the difference. I find it real hard using it > because I don't know how to debug/step in code. DynamicVariable is a process > specific variable but as soon as a debugger opens it is very likely to be in > another process. This makes stepping in method using the DynamicVariable > impossible. The only way round is to set break points after the dynamic > lookup and step from there. But this feels just wrong. > What would be the best way to have DynamicVariable and be able to debug > anything? Or is there a variant that uses the stack instead of the "active" > process? > > thanks, > > Norbert
