From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,2c6139ce13be9980
X-Google-Attributes: gidfac41,public
X-Google-Thread: 1108a1,2c6139ce13be9980
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 103376,3d3f20d31be1c33a
X-Google-Attributes: gid103376,public
X-Google-Thread: f43e6,2c6139ce13be9980
X-Google-Attributes: gidf43e6,public
From: ansible@xnet.com (James Graves)
Subject: Re: Safety-critical development in Ada and Eiffel
Date: 1997/07/11
Message-ID: <5q5p9o$2s4@typhoon.xnet.com>#1/1
X-Deja-AN: 256219465
References: <ED3E9M.F0u@syd.csa.com.au> <ED5AGp.5MJ@syd.csa.com.au>
Organization: XNet Information Systems
Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel
Date: 1997-07-11T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <ED5AGp.5MJ@syd.csa.com.au>,
Don Harrison <donh@syd.csa.com.au> wrote:
>
> I suspect that you can also make an Eiffel reference access a statically
> allocated object (expanded type) using a standard class (MEMORY? someone may 
> wish to confirm this). There would certainly be no technical obstacle to 
> providing this capability if it doesn't already exist enabling you to 
> statically allocate whatever memory you require if that's what you want 
> (as in your application domain). 
>

You are not allowed to make a reference to an expanded object in Eiffel,
because of the information hiding principal.  To be able to diddle with
another object's internal data could easily violate the class
invariant.

That's why Mr. Meyer doesn't like Java's ability to perform direct
assignments of an object's data fields (features in Eiffel terms):

    int x;
    Platoon platoon_a;
    x := 50;
    platoon_a.size := x;         <- Could be an invariant violation
				    if Platoons aren't supposed to have
				    that many soldiers.

It could be the programmer should have used platoon_a.set_size(x) which
(presumably) would check the size of it's argument.  Of course in Java,
you can just not export the size variable at all.  Then you would need
to create a function like:

    int get_size()
    {
	return size;
    }

for every variable that clients of the Platoon class should be able to
see (and not set directly).  Does this remind anyone of Smalltalk?

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

As for using Eiffel in a Hard Real Time (HRT) situation, when dynamic
allocation/deallocation of memory is not desired, I suppose you could
create all the needed objects at the start, stick them in a hashtable 
(or array), and then turn off garbage collection.  Then search through
all the rest of the code for creation instructions (!!a.make or such),
and a.clone() procedures.

As you run the system, look at it's memory size after the start, and if
it ever grows, you know you've missed something.  A nice compiler option
would be to report how many dynamically bound calls there were, so you
could eliminate those too if you really wanted.  (ISE claims that even
dynamically bound calls are dispatched in constant time, and I bet other
Eiffel vendors have picked this up too.)

Since learning about the proposed concurrency mechanism in Eiffel, I
would feel more secure using it instead of some threads package for C.
If implemented correctly (which only needs to be done once), it
elliminates a lot of the effot and the contention/locking problems of
parallel programming.


Later,

James Graves