110 likes | 224 Views
Objects and Aspects: What we’ve seen so far. 15-819 Jonathan Aldrich. In-place vs. Functional Extension. In-place extension Add new methods, fields, superclasses to existing ADTs Cecil, EML, Aspects Strengths Can evolve system without planning ahead Direct, first-order composition
E N D
Objects and Aspects:What we’ve seen so far 15-819 Jonathan Aldrich
In-place vs. Functional Extension • In-place extension • Add new methods, fields, superclasses to existing ADTs • Cecil, EML, Aspects • Strengths • Can evolve system without planning ahead • Direct, first-order composition My opinion: Can’t ignore need for in-place extension in real world due to unplanned evolution/reuse
In-place vs. Functional Extension • Functional extension • Produce new classes that enhance old ones • Inheritance, Mixins, Scala • Strengths • Can have different versions of classes side-by-side • Simpler semantics and typechecking My opinion: (1) Can get better reuse this way, and(2) Many systems need side-by-side versions
What’s Unique About…(Disclaimer: the systems where we first saw a features are notnecessarily the first systems with that features in the research literature) • Self • Dynamic inheritance • Singleton objects (copied by Cecil, Scala) • Shared state (copied by Cecil) • Overridable fields (copied by Cecil, C#) • Cecil (much is actually also in CLOS) • Multi-methods • In-place extensibility: methods, fields, inheritance • Flexible type system: • F-bounded poly + structural (partially copied by Scala) • Conditional subtyping • EML • Clean unification of ML-like FP & OOP • Combination of pattern matching and multi-methods • Modular typechecking of in-place method extension
What’s Unique About… • Units/Mixins • Side-by-side base classes and extensions • Extensions of related groups of classes • More flexible reuse through mixins • Dynamic, recursive module linking • Scala • Clean integration of fns and objects • But more object-like vs. EML’s design • Nice implementation choices • XML support, control structure syntax, local type inference • Clean version of mixins/multiple inheritance • Traits: no state, flexible use • Mixins: richer but less flexible • Rich parameteric types • Variance for type parameters, F-bounded poly., Family Polymorphism, ADTs • Views: partial unplanned extensibility • Vs. Cecil: views are a new object, not an extended version of the old one
What’s Unique About… • F-bounded polymorphism • Binary methods like comparable • Hierarchies of families of related types • Graph & Node • Family polymorphism • Keeps different Graphs of same type separate • Nested Inheritance • Way to refer to surrounding Graph type from Nodes, Edges • Typestate for Objects • Enforcing client-level protocols in OO setting • Correlating typestate to internal invariants • Ownership • Enforcing encapsulation properties in presence of aliasing, state, and inheritance
Open Problems • Typechecking • Dynamic inheritance • Allow more info. hiding in EML • Advanced in-place extensibility (e.g., subclassing) • Full flexibility of Units/Mixins • Combining family poly. & nested inheritance • Combining in-place and functional extensibility • Typestate, ownership, etc. • Still wide open: increasing expressiveness & checking
Expressiveness Challenges • ***Grouped extension • Scala, Nested Inheritance • Late-bound inheritance • ***Parameterized modules with mixins (Units) • *Dynamic inheritance (Self) • Other idioms • ***Multiple dispatch/pattern match (Cecil, EML) • **Singleton objects (Self, Cecil, Scala) • *Shared state (Self, Cecil) My opinion: *** = necessary, ** = nice, * = interesting
Checking Challenges • In-place extension • **Modular typechecking for open classes (EML) • Do they have the rules right yet? • Typechecking extensibility features • ***Hierarchies of related classes (F-bounded poly) • Grouped by object instance (Family poly) • With ways of talking about group from within (Nested Inheritance) • *Merging structural & nominal (Cecil) • Can this be simulated by in-place inheritance extension? • ***Checking properties in presence of inheritance • Typestate: correct use & impl. of library objects • Ownership: encapsulation w/ state, aliasing, inheritance • Later: effects and object invariants My opinion: *** = necessary, ** = nice, * = interesting
The Best of Both Worlds? • In-place extensibility • Add methods, fields, subclasses to ADTs • Multi-methods & pattern matching • Other AOP features • Functional extensibility • Parameterized modules & singleton objects • Combine family poly. & nested inheritance • Dynamic inheritance • Combining these is probably non-trivial! • What does it mean to extend a parametric module in place?
The Road Ahead • AOP • Advanced in-place extensibility techniques • Cleaner separation of concerns • Empirical validation • Modular reasoning • In presence of inheritance and AOP