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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,fa22a73e140a6fd1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.196.130 with SMTP id im2mr13145888pbc.3.1326185240294; Tue, 10 Jan 2012 00:47:20 -0800 (PST) Path: lh20ni162991pbb.0!nntp.google.com!news1.google.com!postnews.google.com!p4g2000vbt.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Object-Oriented style question Date: Tue, 10 Jan 2012 00:47:19 -0800 (PST) Organization: http://groups.google.com Message-ID: <36ee3b54-496c-41d4-a8ba-3357741adada@p4g2000vbt.googlegroups.com> References: <4f098fcb$0$6577$9b4e6d93@newsspool3.arcor-online.net> <11047e9f-a7ef-4728-8e1c-4202c5958e9c@ck5g2000vbb.googlegroups.com> <4f0b7f2b$0$7617$9b4e6d93@newsspool1.arcor-online.net> NNTP-Posting-Host: 83.3.40.82 Mime-Version: 1.0 X-Trace: posting.google.com 1326185240 1529 127.0.0.1 (10 Jan 2012 08:47:20 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 10 Jan 2012 08:47:20 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: p4g2000vbt.googlegroups.com; posting-host=83.3.40.82; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUALESNKRC X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13,gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-01-10T00:47:19-08:00 List-Id: On Jan 10, 12:58=A0am, Georg Bauhaus wrote: > Wouldn't the following lookup function handle the situation? > > =A0 =A0 function Lookup (Table =A0: Dictionaries.Map; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Object : T'Class) return Boole= an is > =A0 =A0 begin > =A0 =A0 =A0 =A0return Table.Contains (Object'Unchecked_Access); > =A0 =A0 end Lookup; > Object denotes an object, then, so no nulls. Therefore, passing > the result of 'Unchecked_Access to function "Contains" should > be safe in the sense that Contains always gets a meaningful > access value to be used as a key. Yes, but this also brings an idea for some typing convention, which I happen to use. The idea is to somehow express the expectation that the operation has with regard to the lifetime of the object and with regard to the aliasing that can be involved. In the case of Info, where no access value is used, the operation expects nothing, which means that it should not leak the reference to the object (store it, etc.). That is, after the operation completes, the object can be destroyed with no consequences, as no alias was created. In the case of Info_3 (or any other operation that accepts access values), the operation can assume that the object lives longer and can therefore leak (store, etc.) the reference and make new alias - it is up to the user to figure out the complete lifetime management. Of course, this convention is not checked statically (other than with the usual rules for access types, which can be bypassed with Unchecked_XXX anyway), but is a good hint for the user with regard to object lifetime expectations. For this reason I would explicitly use access values in the profile if the operation stores the access value in a dictionary. The user should know that there is some aliasing going on there. > The effect is that there still wouldn't be any parameters of an > anonymous access-to-object type at the level of T's definition. Why this should be a goal? I prefer if the profile describes what is going on. If sh*t is going on, then it is better to show it in the profile than to hide it and surprise the user later. -- Maciej Sobczak * http://www.inspirel.com