Path: news.daimi.aau.dk!glad
From: eernst@fraxinus.daimi.aau.dk (Erik Ernst)
Newsgroups: comp.lang.beta
Subject: Re: Adding methods without renaming the class (was Re: What's wrong with this picture?)
Date: 26 Dec 1995 10:29:48 +0100
Organization: DAIMI, Computer Science Dept. of Aarhus Univ.
Lines: 81
Sender: eernst@fraxinus.daimi.aau.dk
Message-ID: <yz8vin441gz.fsf@fraxinus.daimi.aau.dk>
References: <4aodps$70h@netnews.upenn.edu>
	<4b6p2p$dua@fbi-news.Informatik.Uni-Dortmund.DE>
	<4b9apo$aop@krone.daimi.aau.dk> <4bkilb$g47@netnews.upenn.edu>
NNTP-Posting-Host: fraxinus.daimi.aau.dk
In-reply-to: Wolfgang Ziller's message of 24 Dec 1995 22:02:19 GMT
X-Newsreader: Gnus v5.1

In article <4bkilb$g47@netnews.upenn.edu> Wolfgang Ziller 
	<wziller@math.upenn.edu> writes:

   [discussion on adding attributes to an existing class]

   olevi@daimi.aau.dk (Ole Villumsen) wrote:
   >There's another possibility: using an attributes slot.
   >
   >myClass: (# <<slot myClassLib: attributes>>
   >
   >            methodA: (# ... #)
   >            ...
   >         #);
   >
   >Such a slot allows you to define in a different fragment, additional
   >methods for myClass, even if myClass is written by someone else,
   >frozen and delivered to you.

   However, the FAQ (v. 1.7) says that this is not possible
   with the current compiler since certain ambiguities come up
   by doing that.  To (partially) solve the problem, one is
   allowed to write <<slot myClassLib: attributesDecl>> which 
   only allows *one* attribute to be added.

   Has this problem been fixed in the current implementation 
   or is the limitation still in place?


I've neither experienced nor heard of such a limitation (ever).  The

   myClass: (# <<slot myClassLib: attributes>> ... #);

method has worked just fine for at least five years, and probable long
before that.  But there is a limitation (could that be what you've
read about?): You cannot add _substance_ to the instances of a pattern
through an attribute slot, i.e. it is not (currently) supported to
have


-- myClassLib: attributes --

aThing: @SomePattern;  (* A static item is certainly substance *)
doit:< (# ... #);      (* .. and a virtual pattern implies some
                        * substance, too *)


Whereas this is OK: 


-- myClassLib: attributes --

aPattern: (* no limitations compared to any other pattern *)
  (# aThing: @SomePattern; (* .. so this is fine *)
     doit:< (# ... #);     (* .. and this, etc. *)
  #);

anotherPattern: somePrefix(# .. #);


It might be possible to allow substance in attribute slots by
augmenting those objects whose pattern has an attribute slot with a
pointer to some off-line data.  Then substance added in attribute
slots could be allocated outside the (primary) object and accessed via
the pointer.  However, it might very well be necessary to have more
than one such "satellite" object in cases where there is more than one
occurrence (possibly in different source files) of the corresponding
"-- ??:attributes --" fragment form header.  So it's probably hard to
do in a no-use-means-no-penalty manner.  It would be very convenient,
though! 

Anybody who knows about _any_ language implementation which combines
separate compilation and split-module specification of substance of
objects?  (Of course, "generating substance" in C++ header files by
means of macros does not count: it is textually included)


   xmas cheers, 

--
Erik Ernst                            eernst@daimi.aau.dk
Computer Science Department of Aarhus University, Denmark