Scoping changes in self-supporting development environments using context-oriented programming

Abstract

Interactive development in self-supporting systems like Smalltalk or the Lively Kernel allows for an explorative and direct development workflow. Because of the immediate and direct feedback loops, changes to core behavior can lead to accidentally breaking the programming tools themselves. By separating the tools from the objects they work on, this fatal self referentiality can be avoided, but at the expense of interactive development. In this paper we show how contextoriented programming (COP) can be used to separate tools from the objects under development. Instead of directly modifying meta-structures, changes should go into layers on top of these structures. Since layers can be scoped at run-time, changes do not affect the programming tools. We demonstrate this approach by showing examples of adapting core behavior in our self-supporting development environment Webwerkstatt with ContextJS, our COP extension for JavaScript.

Edit Transactions: Dynamically Scoped Change Sets for Controlled Updates in Live Programming

“…This is of particular interest in combination with the Morphic framework of Squeak/Smalltalk [16]. In case of an exception in the [13][14][15] UI process, the process is suspended and the environment opens a debugger for it. Additionally, a new UI process is spawned which has an empty transactions stack.…”

“…The sender of the topmost context from which on no conflicting method has been found is stored and the block closure converted to a context using the asContext method. The stored [13][14][15][16] context's sender is set to the result of this call, whose sender is in turn set to the stored context's original sender, thereby intercepting the return of this context. Since the intercepted return may also return a value, we need to instruct the closure to pass through this value by returning thisContext at: 2 (the stack frame location where the last return has been stored).…”

“…The program editor as illustrated in figure 7 is constructed in a way that it might edit any Edit Transaction and view the source code through an arbitrary subset of Edit Transactions without actually running inside any active Edit Transactions itself. The outer left user interface elements give the programmer control over the existing [13][14][15][16][17] transactions in the system (upper list) and the staged ones (the lower list). The buttons in between the lists state or un-stage transactions.…”

“…which tools were used together). The case was executed by one of the authors who has more than five years of experience using Squeak/Smalltalk and is familiar with the pitfalls [13][14][15][16][17][18] of a live programming environment. Further, the programmer also took part in the development of the tool and thus there was no additional training.…”

Interleaving of Modification and Use in Data-driven Tool Development

“…We argue that, still, many tools employ designs that stretch the feedback loop unnecessarily. Typically, there is no direct connection between a tool's run-time components and its source code [9], modifications involve domain-independent redundancies, and there have to be additional means to reliably update tools to keep on using them [21].…”