From patrikj@ccs.neu.edu Thu Apr 5 13:00:59 2001 X-UIDL: 7605805ce4e3b858eba109c414d873a6 Return-Path: Received: from alderamin.ccs.neu.edu (patrikj@alderamin.ccs.neu.edu [129.10.117.137]) by amber.ccs.neu.edu (8.10.0.Beta10/8.10.0.Beta10) with ESMTP id f35H0wX09103 for ; Thu, 5 Apr 2001 13:00:58 -0400 (EDT) Date: Thu, 5 Apr 2001 13:00:38 -0400 (EDT) From: Patrik Jansson Reply-To: patrikj@cs.chalmers.se To: Karl Lieberherr Subject: New version of top level AC structure Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 55 Version 010329 15.15: Comments on the draft paper Modular Programming with Aspectual Collaborations Karl Lieberherr, Johan Ovlinger, Mira Mezini, David Lorenz I'll use EBNF to describe syntactic categories. Braces {} are used for zero or more occurences I assume the syntactical categories Member, Method, Field, Class are as in java, with Member ::= Field | Method. I sometimes use parentheses to enclose pseudocode. My reading of Definition 2.1 Aspectual Collaboration (AC) and Definition 2.2 Adapter (I call it Composite Collaboration (CC)) - ignoring the details about sharing and so on for now. Intuitively, an AC is a collection of classes (with missing pieces) and wrappers (aspectual methods). The language below is used to combine ACs using some glue (meta code mainly used for name mapping). The end result (when all missing pieces have been filled in) is a normal Java package. Aspectual Collaboration (AC): AC ::= 'collaboration' AC_Name (SC | CC) Simple Collaboration (SC): SC ::= '{' {PL} '}' Composite Collaboration (SC): CC ::= 'adapts' AC_Name {A} // previously 'into' (now similar to 'extends' as for classes) // Do we really need a list of adapters? Adapter (A): A ::= 'adapt' AC_Name {, AC_Name} MC // Other term.: 'using' // Do we really need a list of names? Meta Code (MC): MC ::= (This is as far as I have got!) // Johan calls it Attachment Participant or local class (PL): PL ::= P | Class Participant (P): P ::= 'participant' (A special kind of class with GM instead of Member) Generalized members (GM): GM ::= Member | EAM Expected Members and Aspectual Methods (EAM): EAM ::= EM | AM Expected Members (EM): EM ::= 'expect' Member Aspectual Methods (AM): AM ::= 'aspectual' Method // with some special restrictions on typing Operations on ACs: Participant Graph (pg): AC.pg = if AC is Simple then (A graph with class names as nodes and has_a and is_a edges, calculated from the participant set) else AC.CC.AC_Name.pg // The pg of the adapted AC - same as the unadapted? // The pg is not part of the concrete syntax Expected Interface (ei : AC -> {EAM}) // The type {EAM} should be further refined - Members should say // to which class they belong. (Simple fix - let the name be // prefixed with the class.) AC.ei = if AC is Simple then (All EAMs in the AC's participant set) else (Big union of all (AC.ei) - AC.pi) Provided Interface (pi : AC -> {M}) // Same type comment as for .ei AC.pi = if AC is Simple then (All public Ms in the AC's participant set) else (Big union of all (AC.pi)) ---------------------------------------------------------------- Ideas/observations: [ I saw the article on Aspects in Computer April 2001 - this is really a "hot topic" we're researching!] Would it be OK to say that an AC is a generalization of packages? Maybe the AC language can describe features useful not only for crosscutting concerns but also for parametrization of packages in general. But then there should probably be expected classes (class parameters) as well as expected methods? On the top level this language reminds me of the functors of SML - they are parametrized modules. What is the type of a package or better - what is the type of an AC? My rough guess: AC.ei -> AC.pi but it should be further refined: the aspectual methods in the .ei are also present in the result (with modified behaviour but identical type) the expected methods may or may not be in the result (dep. on their private status)