On 9 July 2013 10:15, Clément Bera <bera.clement@gmail.com> wrote:
Hello pharoers,
Recently I have been looking at the Pharo thisContext capabilities, in order to perhaps one day in the far future edit its implementation with the Pharo dev team. Nothing is planned or confirmed, it is just to discuss.
A context has instances variables (method closureOrNil receiver stackp sender pc) and holds the arguments and temporaries.
Now I'd like to know what context's state do we modify, and what states are just internal representations ?
For example, it seems that you can do 'thisContext receiver: #foo', but you cannot with Cog.
SomeClass>>foo thisContext receiver: #foo. ^ self
In workspace, evaluating: 1 to: 5 do: [:i | Transcript show: SomeClass new foo ]
Transcript result (with Cog): foo foo a SomeClass a SomeClass a SomeClass
Transcript result (with Stack or Vanilla): foo foo foo foo foo
Now as no one has ever complained, I guess this feature is not used.
As far as I know, the real use cases of the context seems to be: - setting and gettings temporaries - setting and getting the sender of a context - setting and getting the pc - getting method, closureOrNil, receiver, stackp, arguments but NOT setting them
Now setting the sender of a context seems to be used only in two cases: - continuations (as seaside continuations) - exception implementation
So imagine that in the future you would have a context that can be accessed in read-only, where you could only: - set the temporaries (but not arguments) - set the pc (or something equivalent, as set the currently executed ast node) - use continuations (exceptions can be implemented on top of continuations)
I would like to know if there are things that you do now and that you would not be able to do with a context like that. For non meta developer (like enterprise app developer) I guess it will not change anything, but I want to know if you implemented a framework as seaside, does it requires other things from the context and why ?
To my thinking playing with pc is awfully evil, it should be read-only, only to allow debugger to map it to source code. Same goes for stack pointer. Setting receiver is less evil and it may work, if receiver belongs to same inheritance chain as compiled method's class. But it should not be set without checking this. And for method's temps, it is fine.
Thanks for answering,
-- Best regards, Igor Stasenko.