Foundational Features of Programming Languages

	Analysis	Requirements & Principles	architecture: Paradigms	substance: Abstractions	structure: Domains	building blocks: Features			surface: Syntactics	Defining PLs	Language List
						foundational	safety	flexibilized
Features that extend or elaborate the model of computation[^], i.e., the "ontological foundation" of the programming language Inheritance and Delegation Mechanisms Other Mechanisms, etc.

1. Inheritance mechanisms on the class level: subclassing, behavioral extension, mixin, features, type-oriented, extension hierarchies
2. Delegation: sound delegation, encapsulated inheritance, viewpoints, traits, wixins
3. Forwarding: environmental acquisition, fashioning
4. Constraint slots

2.1 Delegation (object-based inheritance) In delegation-based languages [InhMod] F J Hauck: Inheritance Modeled with Explicit Bindings: An Approach to Typed Inheritance; OOPSLA'93.	Delegation is a method forwarding mechanism entailing property sharing of methods and variables (not just their declarations!) [SplitO]. Methods delegated from A to object B are executed in A's context (not in B's, as in Forwarding) [EnvAcq] (A) --super--> (B) ^------self----' [InhMod]	(+) sharing variables useful for JoeAsSportsman delegating to JoeAsPerson [SplitO] (-) breaches encapsulation. ``Full access to an object's properties can be gained ... by creating a child of it'' [SplitO] No distinction between client and inheritor: A object cannot hilde its specialization interface [C/OInh].
2.2 Sound Delegation In prototype systems (KR), actor systems (Act1), framebased systems (Y3)	[SplitO]: A kind of copy-on-write: Before the delegator writes an inherited variable a new variable is created for it.	[SplitO]: (+) The frontiers between objects are clear.
2.3 Encapsulated Inheritance [C/OInh] P Steyaert, W DeMeuter: A Marriage of Class- and Object-Based Inheritance Without Unwanted Children; ECOOP'95.	Only the object itself can define new objects inheriting from itself. For this mixin-methods are used.	(+) No client can access the specialization interface, it is encapsulated within the object.
2.4 Viewpoints [DelegInSplit] D Bardou, C Dony: Split Objects: a Disciplied Use of Delegation within Objects; OOPSLA'96.	Delegating objects are viewpoints (aspects, roles) organized in a property-sharing delegation hierarchy. Viewpoints and delegators together are the ``pieces'' (of the representation) of a ``split object''. ``Pieces do not have an objects status, whereas split objects do.'' In a message send the viewpoint must be named. self = the split object receiver, thisViewpoint = the used viewpoint.	(+) solves the question of the identity of viewpoint objects. (+) ``may perhaps be a well-adapted tool for the implementation of role models''
2.5 Prototypes + Traits [PWoC] D Ungar et.al.: Organizing Programs Without Classes; Lisp and Symbolic Computation 4(3); 1991. see also Self	Prototype objects are the objects replicated for cloning. Trait objects are parent objects, not cloned but shared among descendents; they represent classes.	(+) Traits requires no additional language support. Concrete data type = prototype + trait; abstract data type = trait; singleton = prototype. (+) dynamic migration to another class = redirecting the trait reference.
2.6 Wixins Sheldon Nicholi: Wixins: a new object model.; JOOP Nov/Dec'99.	A wrapper object corresponding to a mixin (static). The parent pointer `inner' (corresponding to a mixin's static `super' parameter) can be changed dynamically.	...

3 Forwarding	Methods forwarded from A to object B are executed in B's context (not in A's as in Delegation) [EnvAcq] (A) --fwd--> (B) ------. ^--self--'	(+) B is reused as an encapsulated black-box. (-) internal working of B's method cannot be adapted (by overriding methods).
3.1 Environmental Acquisition (forwarding part -> whole) [EnvAcq] J Gil, D H Lorenz: Environmental Acquitision -- A New Inheritance-Like Abstraction Mechanism; OOPSLA'96.	An object (e.g a part) acquires attributes and methods from its environment (e.g its whole). Class defines (1) features mandatoryily or optionally to be acquired, (2) default implementation for optionally acquired feature, (3) specialization of acquired feature.	(+) supports graphics: when car changes color, so do its doors. (+) forwarding to environment less complex than delegation. (!) the acquirer cannot substitute the acquiree.
3.2 Fashioning (forwarding whole -> part) [Fash] G Moerkotte, A Zachmann: Multiple Substitutability Without Affecting the Taxonomy; 120-135; EDBT'92, LNCS 580.	Whole forwards requests to its part, if it used in place of a part without exposing the part.	(+) aGasStationAttendant .fillup (myPorsche) more natural than aGasStationAttendant .fillup (myPorsche .getGastank()) (+) A department object can substitute for an employee by forwarding to a representative.

navigation bar: Coupling coupling relations / bonds quantity-dependency system view object change propagation systems object constraint programming

Object Constraint Programming in Object Change Propagation Systems

Some proposals describing new features for ISO C can be found in the ISO C Standard.

Feature	Description	Argument
exception handling mechanism [1] Wong, Ooi: Treating failure as a value; 29-32: SIGPLAN Notices 25/1, ACM Jan 1990. [2] Meek: Failure is not just one value; 80-83: Sigplan Notices 25/8; ACM Aug 1990. [3] Wong, Ooi: Treating Failure as State; SIGPLAN Notices 25/8, 1990. [4] Stroustroup's C++PL 3rd edition, ch 14 [5] Patrick Doyle (doylep@ecf.toronto.edu): Message-ID EKq5AL.DpL@ecf.toronto.edu Subject: Exception Handling in OO? In: comp.object Date: 5 Dec 1997.	When an exception is raised (throw in C++), computation switches to "exceptional mode" and continues with special "exception handling code" (catch in C++). exceptional return to caller (without exception information) - eg. Eiffel throw/catch: throw exception-information back to caller [4] forward skipping exceptions: An exception sets a flag (state). Then all instructions are skipped until an exception handler is found [3]. Without MOC-support, the alternative is a convention: Certain result values indicate failure. Then the caller must check the result and branch to error handling	«[T]reating failure as a value brings no benefits to anyone» [2] Handling exceptional cases inline with the main code for an algorithm can be very distracting to the readability of the code. Using exceptions in the appropriate places can make the intent of a routine clearer, and move the exceptional cases somewhere else, to be considered only when they are needed. [5] Throw-catch exception handling allows a non-exceptional (mis)use: The code for deeply recursive tree searches may be vastly simplified by "throwing" the found object back to the original caller [4]. Forward skipping exceptions: Simple implementation [3].
value-based reference schemes vs OIDs [ORM1]	«Because of reliance on oids, UML does not require entities to have a value-based reference scheme.» ...	... «This can make it impossible to communicate naturally at the instance level, and ignores the real world database application requirement that humans have a verbal way of identifying objects.»
should your MOC-with-nonlinear-control be based on events or threads Why Threads Are A Bad Idea (for most purposes) (8 Slides PS)	...	Concurrency is fundamentally hard. Only use threads where true CPU concurrency is needed/ Use events for GUIs, distributed systems, low-end servers
RPC - should different semantics be hidden from programmer? Some technical paper from sun?	...	remote calls (distributed applications) should not look like local calls because failure semantics are totally different.
weak references In Java 1.2: class Reference reifies references	do not prevent to GC the referent	--

Analysis

Requirements & Principles

Paradigms

Abstractions

Domains

Features

foundational

safety

flexibile typing

Syntactics

Defining PLs

Language List