From lieber@ccs.neu.edu Tue Jun 30 19:16:28 1998 Received: from stockberg.ccs.neu.edu (lieber@stockberg.ccs.neu.edu [129.10.116.114]) by amber.ccs.neu.edu (8.8.6/8.8.6) with ESMTP id TAA14512; Tue, 30 Jun 1998 19:16:26 -0400 (EDT) From: Karl Lieberherr Received: (from lieber@localhost) by stockberg.ccs.neu.edu (8.8.6/8.8.6) id TAA14502; Tue, 30 Jun 1998 19:17:42 -0400 (EDT) Date: Tue, 30 Jun 1998 19:17:42 -0400 (EDT) Message-Id: <199806302317.TAA14502@stockberg.ccs.neu.edu> To: dougo@ccs.neu.edu, johan@ccs.neu.edu, lieber@ccs.neu.edu, mira@ccs.neu.edu Subject: Re: interface class graph Cc: jayantha@ccs.neu.edu Status: R Hi Johan: >From johan@ccs.neu.edu Mon Jun 29 16:12:16 1998 >To: lieber@ccs.neu.edu, mira@ccs.neu.edu, dougo@ccs.neu.edu >Subject: Re: interface class graph >Date: Mon, 29 Jun 1998 16:12:12 -0400 >From: Johan Ovlinger > >Mira said: > Karl says: > > > We will need to work out a precise definition of the family > > of class graphs defined by a strategy type. > > Johan was in my office, and we kinda mentioned that maybe ... graph > homeomorphism could be used for defining the family ... Just an idea ... > >We have perhaps been staring ourselves blind on substrategies. Karl >has already mentioned that maybe we should see about commoning up >several strategies into inteface (that was his mail of yesterday : > > you are talking about the interface of an APPC to a class graph. > That interface expresses constraints which the class graph > must satisfy for the APPC to work. Those constraints are of > different forms but a very important kind of constraints are > path existence constraints. Those constraints come from the strategies > used internally by the APPC. Now, instead of putting all those strategies > into the interface of the APPC I propose that we consolidate them > into one strategy (a strategy type). > >Which I didn't understand until now). My conversation with Mira >cleared up alot of confusion about that. (I tried to speak with Karl, >but he was apparently out). > >What I realised (and I think Karl realised this on wednesday, which is >why he was insisting on me getting that TCS paper) is that we should >bypass the idea of using strategies to constrict the APPC's class >graph, and instead directly use subgraph homeomorphism: > >Simply specify a minimal interface class graph for the APPC to which >any acceptable concrete class graph must be homeomorphic. As I >understand from mira, this is what the strategies were meant to >accomplish, but this way we do it directly. > I agree 100% with: >Simply specify a minimal interface class graph for the APPC to which >any acceptable concrete class graph must be homeomorphic. And you want to keep this interface class graph separate. You don't want to play a second role of "summing up" all the strategies in the APPC. I kind of view the sum of strategies also a strategy. > >This is exactly what I had in mind for modules for demjava, with >every class graph implementing many interfaces (one per APPC). > >One reason why I think using Class Dictionary/ Module Interface >notation is superior to Strategies for defining APPCs' interface to >concrete class graphs is that class dictionaries have this notion >about sentences and adaptively instantiating objects. Strategies lack >this concept, so if we use strategies as interfaces to class graphs, Yes, strategies as defined in the paper with Boaz lack this concept. >we will have to "peek" into the concrete class graph to discover what >grammar to use for object instantiation. This will couple the APPC >more tightly to that particular class graph, which is generally >regarded as a bad thing. Very good point. > >Karl: > Strategy graphs have now subclass edges and abstract classes. > >The other reason is that of abstract classes, which class dictionaries >speak about, but I'm still confused about how strategies have >them. > >Johan > In summary I think Johan and Mira are right in viewing the interface of an APPC as an interface class dictionary. We could define a uniform translation of the interface class dictionary into a strategy graph which is summing up all the internal strategies. -- Karl From johan@ccs.neu.edu Tue Jun 30 18:58:41 1998 Received: from carbon.ccs.neu.edu (root@carbon.ccs.neu.edu [129.10.120.106]) by amber.ccs.neu.edu (8.8.6/8.8.6) with ESMTP id SAA13624; Tue, 30 Jun 1998 18:58:40 -0400 (EDT) Received: from carbon.ccs.neu.edu (johan@localhost [127.0.0.1]) by carbon.ccs.neu.edu (8.8.6/8.8.6) with ESMTP id SAA03929; Tue, 30 Jun 1998 18:58:38 -0400 (EDT) Message-Id: <199806302258.SAA03929@carbon.ccs.neu.edu> To: Karl Lieberherr cc: johan@ccs.neu.edu, mira@ccs.neu.edu, dougo@ccs.neu.edu, jayantha@ccs.neu.edu Subject: Re: interface class graph In-reply-to: Your message of "Tue, 30 Jun 1998 18:51:09 EDT." <199806302251.SAA14358@stockberg.ccs.neu.edu> Date: Tue, 30 Jun 1998 18:58:37 -0400 From: Johan Ovlinger Status: R >term "strategy type". I think it is a good idea to write class graph >interfaces in the interface part of an APPC by using a notation like that >of class dictionaries. Thus, the interface part of an APPC contains Yes. We have come several times to the conclusion that strategy graphs and class dictionaries should be integrated. Strategies probably should talk about syntax so that a strategy graph defines a nice family of class dictionaries and not only a family of class graphs. Let's think about this. This is not what I intended. Indeed, I think whilst they can/should use the same syntax on a shallow level (but grammars/abstract classes for strategies it think is not good), they are quite different and should be treated so. Let me start by pointing out the difference in languages they induce. The difference in languages arrises from a difference in goal; class graphs define the grammar of the object graph. Strategies define regexps that match sentences of this language. They are connected, but not the same. Thring to make them the same (as opposed to looking similar) is bound to confuse the issues beyond what mere mortal (or at least swede) can understand Johan