From dougo@ccs.neu.edu Wed Oct 10 05:05:17 2001 X-UIDL: def8c9390ccb4e0dfebef26298b948be Return-Path: Received: from vega.ccs.neu.edu (vega.ccs.neu.edu [129.10.116.206]) by amber.ccs.neu.edu (8.10.0.Beta10/8.10.0.Beta10) with ESMTP id f9A94gP24271; Wed, 10 Oct 2001 05:04:42 -0400 (EDT) Received: (from dougo@localhost) by vega.ccs.neu.edu (8.10.0.Beta10/8.10.0.Beta10) id f9A94fN17250; Wed, 10 Oct 2001 05:04:41 -0400 (EDT) From: Doug Orleans Message-ID: <15300.3880.875515.804540@vega.ccs.neu.edu> Date: Wed, 10 Oct 2001 05:04:40 -0400 (EDT) To: Karl Lieberherr Cc: lorenz@ccs.neu.edu, wupc@ccs.neu.edu, johan@ccs.neu.edu, wand@ccs.neu.edu Subject: Re: OOPSLA poster -- final review In-Reply-To: <200110100152.f9A1qpj04257@denali.ccs.neu.edu> References: <200110100152.f9A1qpj04257@denali.ccs.neu.edu> X-Mailer: VM 6.72 under 21.1 (patch 3) "Acadia" XEmacs Lucid X-Face: (4D-osoq?}7M3\EgvbWKo I agree with David. > http://www.ccs.neu.edu/research/demeter/posters/oopsla2001 > > contains the latest version. I made numerous changes > including the ones suggested by David. > > > I included Doug's new text. Please can you check. Okay, that's too many bullets... Also, you changed "More flexible control over decisions = Better SOC" into "B&B gives more flexible control..." But that's not what I meant! That statement was meant to be a conclusion of the previous set of bullets, i.e. that AOP gives you better SOC by giving you more flexible control over decisions (e.g. separation from subtyping). I then follow that with the definition of branches, which gives you even more flexible control. Try this: [Large] Branches and Bundles [Medium] A new programming model that unifies OOP, AOP, and other separation of concerns (SOC) mechanisms. [Small] An observation: in OOP, every message send causes a decision to be made: which behavior (method) should be run? The decision depends on the message name and run-time type of the receiver. (In multiple dispatch OOP, the decision also depends on the run-time types of arguments.) New behavior for a decision point can only be added with inheritance, by adding a new subtype with overriding methods. In AOP, behavior is added separate from subtyping: advice is provided in aspects. Which behavior to run depends on * what aspects are defined * which pointcuts the join point is in The decision can involve control flow context in addition to the message name and the run-time types of the receiver and arguments. These enhancements allow cross-cutting behavior to be defined. [Medium]Thus, more flexible control over decisions = better SOC. [Small] We propose a new construct, [bold]branches, which unify methods and advice. Each branch has a condition that says when to run. Like predicate dispatch [Ernst et al 98], the condition can involve: * arbitrary expressions over argument values, not just types * logical combinations of expressions The condition can also involve other context information: * control flow history * message name * thread-local or global data Method combination mechanisms (e.g. before, after, around) can customize dispatch order and reduce code duplication. In order to encapsulate sets of branches, we propose another new construct, [bold] bundles, which organize branches by concern. They bundles can be parameterized for reuse and linked together by composition, like units [Flatt & Felleisen 98]. We are developing a simple prototype language called Fred, embedded in Scheme. It would be great if this could all fit on one slide. Otherwise, don't split paragraphs across slides. --Doug