Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!columba.udac.uu.se!news.mdh.se!news.seinf.abb.se!eua.ericsson.se!erinews.ericsson.se!cnn.exu.ericsson.se!convex!cs.utexas.edu!howland.reston.ans.net!Germany.EU.net!Dortmund.Germany.EU.net!Informatik.Uni-Dortmund.DE!veronica!warda
From: warda@veronica.informatik.uni-dortmund.de (Armin M. Warda)
Newsgroups: comp.lang.beta
Subject: Re: How to obtain a ref. to current _component_ obj.?
Date: 11 May 1995 14:54:02 GMT
Organization: CS Department, Dortmund University, Germany
Lines: 127
Sender: warda@veronica (Armin M. Warda)
Distribution: world
Message-ID: <3ot8ea$8q3@fbi-news.informatik.uni-dortmund.de>
References: <3nj0if$6hh@fbi-news.informatik.uni-dortmund.de> <3nkp02$17i@engnews2.Eng.Sun.COM> <199505110947.AA16864@quercus.daimi.aau.dk> <3oo4cb$jpd@fbi-news.informatik.uni-dortmund.de>
NNTP-Posting-Host: veronica.informatik.uni-dortmund.de
Keywords: component,current,this

Søren Brand writes:
>
> Armin M. Warda writes:
> >
> > Perhaps a component should simply be a more qualified item. 
> > Then it should be possible to do what is marked by (* illegal *) 
> > in the above example (b), because in aComp[] -> anItemRef[] a 
> > more qualified object reference would be assigned to a less 
> > qualified object reference (no runtime qualification check needed) 
> > and in anItemRef[] -> aCompRef[] the dynamic reference anItemRef[] 
> > denotes an object with the same qualification as aCompRef[] (would 
> > have to be checked by a runtime qualification check, as usual).
> 
> Agreed, and this is the way I think of this issue. Using the code I sent you
> in an earlier news, you may write:
> 
>   aComp[]->ComponentToObject->anItemRef[];
>   anItemRef[]->ObjectToComponent->aCompRef[];

Yes, it works, but

I still have to distinguish between items and components when 
writing an abstract superpattern with selfreferences, even if I use 
your 'ObjectToComponent'-work-around.

> What the compiler should do, would be to insert these conversions implicitly
> when compiling the code marked as (* illegal *) above. 

Agreed, but

even if the compiler would handle this implicitly, if the abstract 
super-pattern would be located in a different fragment for separate compilation, 
wouldn't it have to be recompiled _differently_ for a component-specialization
and item-specialization? And if I use _both_ specializations at the same time?
Wouldn't I need both object-codes (with and without these conversions)?

So far about the implementation, now about the concept:

> Personally I prefer to be able to see at the declaration spot whether a
> reference refers an object or a component. 

Of cause this is an argument, but what sense does it make to have a 
(super-) pattern to be specialized and finally instantiated to a 
component-object or item-object if it can't handle references to such 
objects in a general way at the higher level?

I think it is not elegant to have to write 

  superPatternForComponents :
    (# next : ^ | superPatternForComponents;
       ...;
       (* the remainder is the same 
          as is superPatternForItems *)
       ...;
    do this(superPatternForComponents)[] -> next[]; 
    (* this(superPatternForComponents)[] -> objectToComponent -> next[] *)
    #);

  superPatternForItems :
    (# next : ^   superPatternForItems;
       ...;
       (* the remainder is the same 
          as is superPatternForComponents *)
       ...;
    do this(superPatternForItems)[] -> next[];
    #);

  aComp  : @ | superPatternForComponents;
  anItem : @   superPatternForItems;

Instead I would prefer to be able to write:

  superPatternForBoth :
    (# next : ^ (* what do I write here? *) superPatternForBoth;
       ...;
    do this(superPatternForBoth)[] -> next[];
    #);

  aComp  : @ | superPatternForComponents;
  anItem : @   superPatternForItems;

You write:

> But then I'm not really sure
> what should happen in the following case:
> 
>   aComp[]->anItemRef[];
>   anItemRef;
> 
> Would this be an attach or a usual method call. I'm pretty sure that the
> current BETA compiler would treat it as a usual method call leading to all
> kinds of trouble...

If there is no SUSPEND during execution of anItemRef then it should
behave as a usual method call, otherwise -- or if anItemRef[] denotes
an object that already made a SUSPEND earlier -- as an activation.

The only trouble I see is: what should happen when a terminated component
is re-attached? Run-Time-Error or Recreation? Especially because it can 
depend on data if a SUSPEND is reachable in the do-part of the pattern.

Another related idea:

Do you think it would be useful to allow to move the component-"|" to a 
pattern declaration instead of restricting it to be used at the object 
resp. reference declaration?

  aSuperPattern :    (# ... #);
  aSubPattern   : |  (# ... #);
  aComp         : @  aPattern;  (* this is a component by inheritance *)

versus 

  aSuperPattern :    (# ... #);
  aSubPattern   :    (# ... #);
  aComp         : @| aPattern;  (* this is a component by declaration *)

Thank you very much for your efforts, your explanations 
are very enlightning and encouraging! Have a good time 
in The Land Down Under!

A.
-------------------------------------------------------------------------------
Armin M. Warda    http://ls4-www.informatik.uni-dortmund.de/QM/MA/warda/pi.html
UniDo, FB Inf.4   work: 0231-755-4824      warda@ls4.informatik.uni-dortmund.de
D-44221 Dortmund  home: 0231-753730        warda@nephilim.ruhr.de
PGP FP= 66 C0 3E 8E D9 FE 61 77  DB 37 0D 40 36 53 71 6A  (SUPPORT ZIMMERMANN!)