views,dynamic binding, addendum to my previous posting 
Author Message
 views,dynamic binding, addendum to my previous posting

Continuing on my previous posting, here is the problem that I am facing now,
hope this will be more precise than the other one:

suppose i have a class named ACCOUNT which does not export anything but defines
the following attributes:
  and the routines :
with obvious meaninig.

classes  READ_V and WRITE_V are defined as follows:

class READ_V

class WRITE_V

-- intention is that 'reading' and 'writing' on ACCOUNT s are to be done by
-- classes READER and WRITER respectively.

Example of a routine is WRITER is as follows:

  set_balance(ac:WRITE_V,amt:REAL) is
           io.putstring("some message etc ")

Example of a routine in READER is similarly:

   read_balance(ac:READ_V):REAL is
            result := ac.amt

Now on the top level class, say  ACCOUNTING, i define the routine
deposit as follows

     deposit(ac:ACCOUNT,amt:REAL) is
              x,y : REAL;
              r: READER;
          -- foreget about efficiency and optimization on some local
          -- entities
             a1 ?= ac;
             a2 ?= ac;
             x := r.read_balance(a1);
             y:= x+amt;

Now from the static type checking point of view this whole thing should
compile okay. What i want to know here whether read_balance and set_balance
will work properly on the objects pointed to by a1 and a2 after successful
(suppose deposit will be called with a nonvoid ACCOUNT  actual)reverse
assignment attempt...

There must be other ways to 'view' the same account by the readers and the
writers... any help? different design of class structures ?

thanks for bearing with me..


Sun, 25 Sep 1994 09:25:33 GMT  
 views,dynamic binding, addendum to my previous posting
sorry folks,please ignore my previous posting, my understanding of
reverse assignment attempt was incorrect and the example i tried to
build with read_v write_v and reverse assignments are simply WRONG.

However I would like to know the answer to the question i asked in the
first posting ( different views of same BANK_ACCOUNT as posed in Dr.
Meyer's book)...

How about the following class structure:

                      BANK_ACCOUNT {no export, only definition}



3 classes in 2nd row are each child of BANK_ACCOUNT,
COMMON_VIEW is child of all the three views above it, and in the top
level class like a session, accounts are created and passed around as
common_view objects..

sorry about my previous posting and thanks for your helps..


Sun, 25 Sep 1994 22:04:19 GMT  
 [ 2 post ] 

 Relevant Pages 

1. views and dynamic binding

2. No bind on variable View (801) attempting ot open the currewnt view

3. Addendum to Sather post

4. PREVIOUS( view ) hangs - continued

5. PREVIOUS( view ) hangs

6. ODP: PREVIOUS( view ) hangs

7. Correction of my previous posting.

8. Sorry Happy.Exe previous posting

9. loop variants (Re: ^^^^^ignore the previous post)

10. Retraction of previous posting

11. How can I see previous postings

12. omit previous post about intrument drivers


Powered by phpBB® Forum Software