The paper "Subject-Oriented Programming (A Critique of Pure Objects)" by William Harrison and Harold Ossher from IBM T.J. Watson Research Center explores the limitations of traditional object-oriented programming (OOP) in scaling to large, integrated suites of applications. The authors argue that OOP's emphasis on object identity and encapsulation is inadequate for managing multiple subjective views and extrinsic information associated with objects. They propose a new paradigm called Subject-Oriented Programming (SOP), which emphasizes subjective views and the binding concept of identity to tie these views together. In SOP, each application or tool is treated as a subject, defining its own state and behavior. Subjects can independently define and operate on shared objects, without needing to know the details associated with those objects by other subjects. The key characteristics of SOP include: 1. **Subject Activation**: Each subject has an activation that provides an executing instance, including the data manipulated by the subject. 2. **Compositions**: Subjects can be combined into cooperating groups called compositions, which define rules for combining components. 3. **State and Behavior**: Subjects can specify their own behavior for each object, and the inheritance relationships among classes can vary across subjects. 4. **Object Creation and Initialization**: Creation and initialization behavior must be shared among subjects, with deferred initialization to save space and time. 5. **State References**: Methods within an activation can only access instance variables specified by that subject, providing tighter encapsulation. 6. **Points of Agreement**: Subjects must agree on operation interfaces and object classifications for effective interaction. The paper also discusses various composition rules, such as "merge" and "nesting," and explores strategies for matching classes across subjects, including explicit, inferred, interface-based, and operational classification. It presents a formal model of SOP and discusses efficient implementation considerations, such as package sharing, data sharing, and subject compositors. Finally, the authors provide a concrete example of using SOP in software development environments, where tools are integrated as subjects, each with its own class hierarchy and definitions for classes. This example illustrates how SOP can facilitate the development and evolution of cooperating applications.The paper "Subject-Oriented Programming (A Critique of Pure Objects)" by William Harrison and Harold Ossher from IBM T.J. Watson Research Center explores the limitations of traditional object-oriented programming (OOP) in scaling to large, integrated suites of applications. The authors argue that OOP's emphasis on object identity and encapsulation is inadequate for managing multiple subjective views and extrinsic information associated with objects. They propose a new paradigm called Subject-Oriented Programming (SOP), which emphasizes subjective views and the binding concept of identity to tie these views together. In SOP, each application or tool is treated as a subject, defining its own state and behavior. Subjects can independently define and operate on shared objects, without needing to know the details associated with those objects by other subjects. The key characteristics of SOP include: 1. **Subject Activation**: Each subject has an activation that provides an executing instance, including the data manipulated by the subject. 2. **Compositions**: Subjects can be combined into cooperating groups called compositions, which define rules for combining components. 3. **State and Behavior**: Subjects can specify their own behavior for each object, and the inheritance relationships among classes can vary across subjects. 4. **Object Creation and Initialization**: Creation and initialization behavior must be shared among subjects, with deferred initialization to save space and time. 5. **State References**: Methods within an activation can only access instance variables specified by that subject, providing tighter encapsulation. 6. **Points of Agreement**: Subjects must agree on operation interfaces and object classifications for effective interaction. The paper also discusses various composition rules, such as "merge" and "nesting," and explores strategies for matching classes across subjects, including explicit, inferred, interface-based, and operational classification. It presents a formal model of SOP and discusses efficient implementation considerations, such as package sharing, data sharing, and subject compositors. Finally, the authors provide a concrete example of using SOP in software development environments, where tools are integrated as subjects, each with its own class hierarchy and definitions for classes. This example illustrates how SOP can facilitate the development and evolution of cooperating applications.