X11 - MUMPS Development Committee

SC16 - Object Oriented Language

TG1 - Design Goals

Omega Foundation Document

Design Goals and Design Principles

Part 1: Executive Summary Starting in 1982 the MDC pursued efforts to add object-oriented (OO) capabilities to M. These efforts resulted in proposals suffering from excess complexity or a failure to capture the complete benefits of object-orientation. After years of efforts, in March of 1996 the MUMPS Development Coordinating Committee of Europe (MDCC-E) suggested that the problem with these proposals is that they tried to introduce concepts for which M was never intended. Therefore, in March of 1997 the MUMPS Development Committee (MDC) decided it would be best to form a new subcommittee, SC16--Object-Oriented Language (1), tasked with the creation of an object-oriented version of M. The subcommittee has given this new language the working name Omega.

1. Design Goals Summary
	1.1. M-Centered
	1.2. True OO
	1.3. Massive Interoperability
	1.4. Design for Future Evolution

2. Design Principles Summary
	2.1. Fire & Ice
	2.2. Elegance
	2.3. Gradual, Open-Ended Learning Curve
	2.4. Maintainability
	2.5. Customizability
	2.6. Diversity

Part 2: Detail

3. Design Goals in Detail

3.1. M-Centered: Combine M Concepts and New Concepts (Design Goal 1.1)

Omega's architecture will be based on M, but Omega's architecture will include the changes and additions needed for the seamless introduction of OO. Therefore, this must be the first step in the derivation of Omega's architecture from M's.

3.2. True OO: Make Omega Completely Object-Centered (Design Goal 1.2)

Unlike hybrid OO systems, Omega will be a pure OO system in which all system elements are objects.

3.3. Massive Interoperability: An Open Approach to M Computing (Design Goal 1.3)

For Omega to add OO features to M, M and Omega must transparently interoperate. Omega must also cleanly interoperate with non-M systems to open up their capabilities for our use.

3.4. Design for Future Evolution: Planning Ahead (Design Goal 1.4)

Since programming systems evolve, the design should allow for an evolution that is as painless as possible.

4. Design Principles in Detail

The MDC is pursuing the following design principles in the creation of Omega:

4.1. Fire & Ice (Design Principle 2.1)

The MDC will focus on creating a dynamic system with the ability to selectively freeze any or all elements of the software. Where most systems constrain which programming features are constant and which are variable, Omega's Fire & Ice principle will remove this constraint by letting the programmer choose.

4.2. Elegance (Design Principle 2.2)

Omega will combine related constructs and concepts wherever possible in order to have fewer but more powerful language constructs. This is a balancing act that requires careful judgment to avoid removing the expressibility of useful language elements while still reducing down redundant features.

4.3. Gradual, Open-Ended Learning Curve (Design Principle 2.3)

Omega should be simple for beginners to learn without capping the potential power of the language.

4.4. Maintainability (Design Principle 2.4)

Omega should lend itself to the creation of highly maintainable software.

4.5. Customizability (Design Principle 2.5)

Omega should be customizable toward the needs of local programming standards and other forms of specialization.

4.6. Diversity (Design Principle 2.6)

Omega should provide capabilities, not dictate solutions.