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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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-7-bit Received: by 10.68.196.130 with SMTP id im2mr14900896pbc.3.1326230827435; Tue, 10 Jan 2012 13:27:07 -0800 (PST) MIME-Version: 1.0 Path: lh20ni164939pbb.0!nntp.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news-out.readnews.com!transit3.readnews.com!xlned.com!feeder5.xlned.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!amsnews11.chello.com!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Object-Oriented style question Date: Tue, 10 Jan 2012 15:26:59 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: 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> <36ee3b54-496c-41d4-a8ba-3357741adada@p4g2000vbt.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1326230824 22645 69.95.181.76 (10 Jan 2012 21:27:04 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 10 Jan 2012 21:27:04 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-01-10T15:26:59-06:00 List-Id: "Maciej Sobczak" wrote in message news:36ee3b54-496c-41d4-a8ba-3357741adada@p4g2000vbt.googlegroups.com... On Jan 10, 12:58 am, Georg Bauhaus wrote: >> Wouldn't the following lookup function handle the situation? >> >> function Lookup (Table : Dictionaries.Map; >> Object : T'Class) return Boolean is >> begin >> return Table.Contains (Object'Unchecked_Access); >> 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. I agree with your differentiation here, but I think it is usually a mistake to expose lifetime management to the user. That is, if it is reasonably possible, don't hamstring your clients by forcing *your* ideas of appropriate lifetime on them (which forces them to do memory management explicitly, which is error-prone). For instance, Claw makes lots of internal pointers to objects. But we don't impose any requirements on the lifetime of the objects passed. How do we do this? All Claw objects are designed to unhook themselves from any Claw data structures that they were stored in when they are finalized. So the fact that Claw maintains these structures is invisible to the client, and if they want to use local variables or put Claw objects into a container, they can do that. Randy.