I think we all agree. For me, a syntactic unit defines a set
of objects out of which I can select a specific one by
providing an annotated UML class diagram.

In other words, Grammar = Annotated UML class diagram.
In this context, I view an object as the weaving of a sentence
and a grammar.

-- Karl

From gregor@parc.xerox.com Tue Sep  2 13:39:03 1997
To: wand@ccs.neu.edu
CC: AOPCore.PARC@xerox.com, dem@ccs.neu.edu
Subject: Re: aspects and objects

I agree with pretty much all of Mitch's message.

Clearly AOP wants to provide compact semantic and syntactic units
with which to express "control over emergent entities in the component
structure".  My concern was over calling those "objects" in the sense
of OOP.


I'd say that the goal of PL research in general is to provide compact
semantic and syntactic units with which to program the <concerns of
interest>.

In our work we are trying to reserve the term "aspect" to mean a more
specific thing than "concern", that's why I don't formulate this the
same way Mitch does ("the goal of programming languages should be to
offer syntactic abstractions of aspects").

The contribution AOP makes is to try and work with cross cutting
concerns by *weaving* *different* kinds of program units.

I also agree that databases are a good example of AOP (and Open
Implementation) like concepts.



   Date: Tue, 2 Sep 1997 08:20:04 PDT
   From: Mitchell Wand <wand@ccs.neu.edu>

   Karl wrote:

      From: Karl Lieberherr <lieber@ccs.neu.edu>
      Date: Fri, 22 Aug 1997 04:52:02 PDT

      We had an extended discussion on this with Crista, Anurag and
      in our group. A member of our group (Johan) summarized as follows:

      AspectsToObjects Principle (ATOP):
      The goal of programming languages should be to offer
      abstractions which turn aspects into objects.               

      I agree with ATOP. Do you? 

   and Gregor replied:

   > AO is about controlling entities that emerge from the interactions of
   > the components.  Thus it is about concerns that do not fit in the
   > component structure, but rather, in a certain sense, fit in the emergent
   > cracks in the component structure.

   > AOP, or any xxP, is about providing language constructs that are a good
   > match with the concepts and concerns that a programmer is trying to work
   > with.  So, AOP languages have to be a good match to the emergent
   > entities the programmer is working with.

   I agree that turning things into "objects" is unnecessarily restrictive, and
   when I expressed support for ATOP, I was thinking of "objects" as some kind of
   local syntactic entities, not "objects" as in object-oriented programming.

   I think I do agree with something *like* the ATOP principle; here's a
   formulation:

      The goal of programming languages should be to offer 
      syntactic abstractions of aspects.

   Primitive programming language had syntactic abstractions only for *very*
   primitive things, eg machine instructions or local bits of control flow.
   Later languages added procedural abstractions-- these required a more complex
   composition mechanism.  It is not accidental that language processors are
   called "assemblers" or "compilers"-- the idea of rearranging syntactic bits
   into machine codes with a quite different structure is very old.

   Modern languages allow "generalized procedures" or what you call
   "components"-- the possibility of dynamically choosing a procedure body to
   execute is one of the core ideas of OOP.  This in turn requires a more complex
   notion of composition.

   Another example:  modern DBMSs allow the programmer to specify different
   aspects of the database (tables, queries, forms, and reports) using different
   sublanguages (some textual, some visual) and provides an interconnection
   mechanism (an architecture or backplane) to weave these disparate entities
   into a running system.  [Sorry, I've just spent the last week learning MS
   Access].   The work of the last decade on domain-specific software
   architectures has much of the same flavor.

   So, AOP is asking us to consider more complex abstractions (the specification
   of the aspects), and to invent more complex composition mechanisms (the
   weaver). 

   Does this make sense?  Does it help?

   --Mitch