1 / 11

Objects and Aspects: What we’ve seen so far

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

fritzi
Télécharger la présentation

Objects and Aspects: What we’ve seen so far

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Objects and Aspects:What we’ve seen so far 15-819 Jonathan Aldrich

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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?

  11. The Road Ahead • AOP • Advanced in-place extensibility techniques • Cleaner separation of concerns • Empirical validation • Modular reasoning • In presence of inheritance and AOP

More Related