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.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,c890e6ab3fb2c5fc X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,c890e6ab3fb2c5fc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-01-20 18:22:55 PST Path: pad-thai.cam.ov.com!noc.near.net!chpc.chpc.org!bigboote.WPI.EDU!news.mathworks.com!udel!gatech!newsfeed.pitt.edu!uunet!newsgate.watson.ibm.com!watnews.watson.ibm.com!ncohen From: ncohen@watson.ibm.com (Norman H. Cohen) Newsgroups: comp.lang.ada,comp.lang.c++ Subject: Re: ADA Objects Help! Date: 20 Jan 1995 17:22:29 GMT Organization: IBM T.J. Watson Research Center Distribution: world Message-ID: <3forgl$11cd@watnews1.watson.ibm.com> References: <3f9g1u$j4m@nps.navy.mil> <3fcs59$70s@nps.navy.mil> <3ff186$c19@gnat.cs.nyu.edu> <3fhggr$11dp@watnews1.watson.ibm.com> Reply-To: ncohen@watson.ibm.com NNTP-Posting-Host: rios8.watson.ibm.com Xref: pad-thai.cam.ov.com comp.lang.ada:14508 comp.lang.c++:70174 Date: 1995-01-20T17:22:29+00:00 List-Id: In article , Mats.Weber@matrix.ch (Mats Weber) writes: |> In article <3fhggr$11dp@watnews1.watson.ibm.com>, ncohen@watson.ibm.com wrote: |> |> > Because, unlike task units, package units export declarations for use |> > outside. |> |> Well, tasks export entries, which are usable outside just like subprograms |> exported from packages. True enough. The entries are per-type entities, whose declarations are elaborated once for each task type. (This is noticeable by the fact that entry-family discrete ranges are elaborated once per task type, not once for each object of the type.) Entities declared in the declarative part of the task body are per-object entities, whose declarations are elaborated once per object. The distinction I was trying to make (alhtough I wasn't very clear about it) was about per-object entities: The entities declared in a package- type declaration would be exported by each object in the package type, unlike the per-object entities of a task type. |> > Each time an object of a package type is created, these |> > declarations would have to be elaborated again, so that identically |> > declared entities exported by different objects of a package type would |> > be distinct. For example: |> > |> > package type PT is -- THIS IS NOT VALID ADA XX for XX <= 95 !!!!!! |> > N: Integer := [some nonstatic expression]; |> > type T is array (1 .. N) of Integer; |> > end PT; |> > |> > Package_1, Package_2: PT; |> |> The declaration for N does not cause a problem. It would be treated just |> like a record component declaration with a default initial value (i.e. the |> nonstatic expression is evaluated at each elaboration of a PT). This is beginning to look suspiciously like a generic package. Generic templates are the only program units in Ada with the property that declarations inside the program-unit declaration are not elaborated as part of the elaboration of the program-unit declaration. |> Type, subtype, and exception declarations would not be allowed within |> package types. We don't want dynamic creation of types. The term package type is beginning to look like a misnomer. The instances of these types are far more restricted than packages are. In fact they are even more restricted than generic packages. A package that cannot provide types is little more than a record. |> > Package_1.T and Package_2.T are distinct types. The same applies to any |> > interesting entity exported by Package_1 and Package_2. So what do we |> > gain by defining them to belong to the same type? |> |> What do you mean by `interesting entity' ? Just about anything other than renamed views and named numbers. In particular, if there is a subprogram with an operation of a type declared in the package-type declaration, there is a distinct subprogram, with a distinct profile, for each object of the package type. That should make overloading resolution interesting. (There's that word "interesting" again, in a different sense this time!) Thus you are right to rule out type declarations in package-type declarations, but it makes package types little more than record types. |> I have just completed my thesis and part of it is a proposal for object |> oriented Ada based on package types. Aren't you glad I wasn't on your thesis review committee? ;-) -- Norman H. Cohen ncohen@watson.ibm.com