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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8a402d78988bdf2b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-25 05:54:03 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!dialin-145-254-040-025.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: [announcement] SYSAPI and SYSSVC for Windows Date: Thu, 25 Dec 2003 15:00:20 +0100 Organization: At home Message-ID: References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-040-025.arcor-ip.net (145.254.40.25) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de 1072360440 12229264 145.254.40.25 ([77047]) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:3803 Date: 2003-12-25T15:00:20+01:00 List-Id: Robert A Duff wrote: > "Dmitry A. Kazakov" writes: > >> Robert A Duff wrote: >> >> > We should, instead, have allowed the "aliased" keyword on parameters. >> >> No, I think that "aliased" should better be used as a type qualifier: >> >> type X is aliased tagged ...; -- This is a by-reference type >> type X is tagged ...; -- The compiler is free to choose >> -- (with all the consequences) > > We're not (just) talking about whether parameters are passed by > reference. We're (also) talking about whether regular variables are > aliased. It seems to me somewhat dangerous, and deserving of a special > mark on the variable declaration. (It wasn't allowed at all in Ada 83.) Yes of course. There should be a choice: either to make all objects aliased by declaring the whole type aliased (so by-reference), or to allow the compiler to choose, but also to have an ability to apply "aliased" to an object or to a subtype: declare subtype Aliased_Integer is aliased Integer; X : Aliased_Integer; -- Same as aliased Integer To have "aliased" in the parameter profile, would mean an anonymous aliased subtype. This is OK, but then we should probably to make the consequent steps allowing anonymous subtypes of all sorts: procedure Get_Line (Line : in out String (1..Get_Line_Width)); That could be poblematic. >> For parameters there are access types. IMO it is a bad idea to get >> pointers to parameters, if that is really needed one should pass a >> pointer instead. > > I think I agree with that, but then you trip over another design mistake > -- there's no such thing as an "access constant" parameter. Yes. >> A good example is Finalize. There is a nasty problem to get a pointer to >> the parameter of Finalize, because there is no way to figure out which >> pool it should be. For by-reference types it should be sort of: >> >> procedure Finalize (Object : access not all Object_Type); -- (:-)) > > I'm not sure what you mean. How does this tell you what pool Object is > in (maybe none!)? That was a joke! Though seriosly, there should be some way to work with pool objects. Presently, pool is decoupled from the object type. It makes sense, but quite often one wishes to allocate controlled objects in a specific pool. Maybe we should allow: type Object_Type is new Ada.Finalization.Limited_Pool_Specific with private; for Object_Type'Storage use Pool; type Ptr is access Object_Type; -- Implies for Ptr'Storage_Pool use Pool; A : Object_Type; -- Compile error procedure Foo (A : access Object_Type); -- A is specific to Pool procedure Finalize (Object : access Object_Type); With MD we could make Finalize dispatching on both Object and Pool: procedure Finalize ( Object : access Object_Type; -- Object is specific to Pool Pool : in out Root_Storage_Pool ); But this would require too much work. >> Then I would disallow overloading like this: >> >> procedure Foo (Object : access Object_Type); >> procedure Foo (Object : in out Object_Type); >> >> Instead of this I would make access types transparent to primitive >> operations, as they are to array indexing and record member extraction. > > We proposed something like that (implicit .all) in the early stages of > the Ada 9X project. > > I actually don't like implicit dereference at all, even for selected > components. But the problem is that .all is so verbose and ugly, it > *needs* to be implicit. If it were up to me, the syntax for dereference > would be Pointer^ (from Pascal), which is unobtrusive, but still makes > the dereference explicit. Following a pointer and selecting a record > component is semantically much different from just selecting a record > component -- the syntax should convey that. I see it completely different. To me an access type should be just a subtype of the target type, so it would inherit all operations of the "base". To do it I would allow user-defined subtypes privately implemented in this case by a hard-wired access type: type Object is ...; subtype Handle is private Object; private type Handle is access Object; This would mean that all operations would be transparent, what one indeed expects from a handle. With appopriate constructors and destructors it could be made dangling-pointer safe. It would probably make 'Access attribute and anonymous access types superfluos in most cases. Though there would definitely be a problem with recursive types to solve. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de