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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP Path: utzoo!linus!decvax!mcnc!philabs!cmcl2!seismo!rlgvax!cvl!umcp-cs!brad From: brad@umcp-cs.UUCP Newsgroups: net.lang,net.lang.ada Subject: Re: Abstraction In Ada Message-ID: <7617@umcp-cs.UUCP> Date: Sun, 24-Jun-84 22:15:11 EDT Article-I.D.: umcp-cs.7617 Posted: Sun Jun 24 22:15:11 1984 Date-Received: Wed, 27-Jun-84 03:24:34 EDT References: <1979@mit-eddi.UUCP> <5400007@ea.UUCP> <7506@umcp-cs.UUCP>, <2144@mit-eddie.UUCP> <2620@ncsu.UUCP> <2226@mit-eddie.UUCP> Organization: Univ. of Maryland, Computer Science Dept. List-Id: Let me respond to a few points in the Ada abstraction debate. >>> From: nessus@mit-eddie.UUCP >>> To do a good job with data abstraction, you really need >>> heap-based allocation with automatic garbage collection. >>> Ada doesn't support this. Not true. The Ada Language Reference Manual (LRM) says the following: (section 4.8, page 4-25) "An implementation must guarantee that any object created by the evaluation of an allocator remains allocated for as long as this object or one of it's subcomponents is accessable directly or indirectly, that is as long as it can be denoted by some name. Moreover, if an object or one of its subcomponents belongs to a task type, it is considered to be accessible as long as the task is not terminated. An implementation may (but need not) reclaim the storage occupied by an object created by an allocator, once this object has become inaccessible." This last sentence gives an implementor the choice of providing garbage collection. You see, it's an implementation issue. You should note that in some cases (such as real-time systems) it may be a bad thing to have garbage collection since your system may be effectivly halted for noticable periods of time. >From: nessus@mit-eddie.UUCP >If data abstraction is done right, data types that are added to the >languange should look just like data types that are already built into >the language. Stack-based allocation doesn't work right because you >have to know how much space you will use before you use it. This is not >very abstract. You might not know how much space you need. Heap-based >allocation where explicit deallocation is required doesn't work right >because you can have dangling references. On object isn't very abstract >if you try to reference it and find out it's been turned to garbage. >Explicit dealocation also violates modularity because one part of a >program has to take responsibilty for deallocating an object and it has >to know when everyone else is no longer using it. This compromises >modularity. Ada has been designed so that dangling references are eliminated. An object isn't deallocated (and possibly garbage collected) until all references are elimated. If you are used to a language like C, where many objects are unneccessarily global in scope, then you might feel this is a problem, but in Ada, objects can be declared with an appropriate scope. >I will demonstrate by example. Let's say that you want to implement a >bignum (integer with arbitrary size) abstraction. In order to be >abstract, the bignum data type should be just as first class as any >other number type. If you use stack-based allocation, you will have to >worry about reserving the right amount of space in advance. But gee, >you don't have to do this with number types that are built in. If you >use heap-based allocation with explicit dealocation, you will have to >worry about dealocating a bignum when you are finished with it. But >gee, you don't have to do this with number types that are built in. Again, in Ada, one can implement the "bignum" using dynamic allocation (i.e. access types) and you do not have to do explicit deallocation. Of course there is the problem of possibly running out of memory, but that is only if your implementation does not do garbage collection (again, an implementation issue). I wonder how much memory your "bignum" scheme would use anyway. I won't even mention virtual memory. >> From: mauney@ncsu.UUCP (Jon Mauney) >> (C) a type can be declared "limited private." In this case the >> only operations supplied by the system are declaration of >> variables (an essential ability) and passing as parameter (also >> essential). This is useful in many cases, because the >> system-supplied operations are not appropriate to the particular >> abstraction or implementation. The '=' operator may be >> overloaded, and definition of '=' automatically implies >> definition of '/='. Sad to say, ':=' is not an operation that >> can be overloaded, and assignment of limited private types must >> be done using a different syntax. This system is not without >> its defects, but is it really so horrible? >Yes, it's gross! You also forgot to mention that if a composite type >has components of a limited private type "=" is not available for >objects of the composite type. I don't understand why it's so gross. The lack of overloading for ":=" has it's trade-offs. One of the reasons that limited private types may not be assigned is so that copying of secure or limited resources may be forbidden. I don't understand under what circumstances that operation "=" for type A shoud be inherited for objects of type B that contain objects of type A. If type B is a record, for example, then the subcomponent of an object of type B (i.e. one of type A) still has the "=" operation. Could you give me an example? Also, for a discussion of Object Oriented Design and Ada, pick up a copy of Grady Booch's book, "Software Engineering with Ada". It is the definite reference for Object Oriented Design and how it can be used in Ada. Brad Balfour arpa brad@maryland csnet brad@umcp-cs uucp {seismo,allegra}!umcp-cs!brad