paradigm/context-oriented-programming

The lookup method of OOP, takes in consideration also the execution context, that can be DEV or PROD environment, the roles of the user in a web application and so on.

There is also a ContexL extension to CL. “ContextL is an extension to the Common Lisp Object System that allows for Context-oriented Programming. It provides means to associate partial class and method definitions with layers and to activate and deactivate such layers in the control flow of a running program. When a layer is activated, the partial definitions become part of the program until this layer is deactivated. This has the effect that the behavior of a program can be modified according to the context of its use without the need to mention such context dependencies in the affected base program. We illustrate these ideas by providing different UI views on the same object while, at the same time, keeping the conceptual simplicity of object-oriented programming that objects know by themselves how to behave, in our case how to display themselves. These seemingly contradictory goals can be achieved by separating class definitions into distinct layers instead of factoring out the display code into different classes”

Among others, we have implemented exception handling [2], multiple views on the same object which are selected based on execution context [14], coordination of screen updates [16], discerning of phone calls based on the context of both callers and callees [41], selecting billing schemes based on dynamic context conditions [15], and traversals of expression trees [26]. ContextL, our first language extension that explicitly supports our vision of Context-oriented Programming, has already been integrated into Lisp on Lines, a Web framework that is used in commercial applications [12], and is used for generat- ing different document formats (like html, pdf, etc.) from the same object structures. In other settings, we have developed Piccola, a language with first-class namespaces [1], a context-oriented extension of AspectS [25] for Smalltalk/Squeak, ContextS for Smalltalk/Squeak, and context-oriented extensions of AmbientTalk [42].

[1] P. Costanza and R. Hirschfeld, “Language constructs for context-oriented programming: an overview of ContextL,” 2005, pp. 1–10. doi: 10.1145/1146841.1146842. [1] M. von Löwis, M. Denker, and O. Nierstrasz, “Context-oriented programming: beyond layers,” 2007, p. 143. doi: 10.1145/1352678.1352688. [1] R. Hirschfeld, P. Costanza, and O. Nierstrasz, “Context-oriented Programming,” vol. 7, no. 3, p. 27.

MAYBE in Dok, thefeature/attribute-grammar approach will suffices because: systems are synthetized from AG rules; AG manage the concept of context at compile-time naturally using top-down attributes; at run-time the context can be an explicit param of methods.

FACT layers (the context name in ContextL) are dynamically activated, e.g. they can depend from the role of an user in a web session.

TODO in case of dynamic layers, the AG must be executed at run-time, or it can generate a system receiving the layer (i.e. the context) at run-time as parameter.

FACTfeature/abstract-interpretation can help into managing static and dynamic layers in the same way

FACT Context Oriented Programming differs from Aspect Oriented Programming because it does not attach :after or :before code to methods, but it can create a totaly different implementation

FACT Context Oriented Programming differs from Subject Oriented Programming, because the class hierarchy remains the same