🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.eiffel
Article #1594

Re: global objects

#1594
From: Philippe Stephan
Date: Wed, 21 Feb 1990 22:37
72 lines
2637 bytes

In article <925@tuewsd.lso.win.tue.nl>, Eelco Vriezekolk asks:

> We want to define some classes, and create only one object of each
> class. The object names must be global, so that they can be used
> in all the class definitions and all refer to the same only one)
> object. Each object must be able to call routines of any other
> object.

   Assume that you want to define classes A, B, C, and create
only one object of each, the name of the objects being global.

   The general solution is to make all your classes inherit from a
class PARENT (or use class HERE) where you declare:

   a: A is once Result.Create end;
   b: B is once Result.Create end;
   c: C is once Result.Create end

   However:

   1) You have to be careful not to generate any creation
loop calling some of these once functions in the creation routines
of class A, B and C, e.g. do NOT use:

   class A inherit PARENT feature create is do foo (b) end end
   class B inherit PARENT feature create is do bar (a) end end

   2) Another problem with this is that if you want arguments in
the creation routines of classes A, B and C, you need them to be
shared, i.e accessible from class PARENT, which has probably nothing
else to do with them.

   In order to avoid this clumsiness, use something like:

in class PARENT:

   a: A is once Result := aa end;
   aa: A is deferred end;
   (aa: A is do end;)

in class INIT_A:

   class INIT_A
	  inherit
	     PARENT
			(redefine aa)
	  feature
	     Create is do
	        aa := a_initialized (arguments);
	        foo (a)
            -- The first call to ``a'' sets it for good.
	     end;
         a_initialized (...): A is
	            -- Instance of A, initialized with ``arguments''.
            do
            ...
            end;
	     aa: A
                -- (Re)defined as an attribute
      end

   As you have guessed, the programmer has to take care, in this
case, to create an instance of INIT_A at the right time, in order
to properly set the reference ``a'', which would always be void
if called before that.

Hoping this helps,

-- Philippe Stephan
-- stephan@eiffel.com
Technical Details
Message-ID: <252@eiffel.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!ucsd!hub!eiffel!stephan
References: <925@tuewsd.lso.win.tue.nl>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!ucsd!hub!eiffel!stephan
From: stephan@eiffel.UUCP (Philippe Stephan)
Newsgroups: comp.lang.eiffel
Subject: Re: global objects
Summary: A solution to the "shared names" problem
Message-ID: <252@eiffel.UUCP>
Date: 21 Feb 90 22:37:51 GMT
References: <925@tuewsd.lso.win.tue.nl>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 72