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,3a7c118fd2cc64f9 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!newsfeed.straub-nv.de!news2.arglkargh.de!news.n-ix.net!news.belwue.de!LF.net!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: A hole in Ada type safety Date: Sun, 08 May 2011 12:30:04 +0200 Message-ID: <87pqntscwj.fsf@mid.deneb.enyo.de> References: <87oc3odtci.fsf@mid.deneb.enyo.de> <87tydfbtp3.fsf@mid.deneb.enyo.de> <87d3k2u36e.fsf@mid.deneb.enyo.de> <877ha2op0n.fsf@mid.deneb.enyo.de> <87oc3en898.fsf@mid.deneb.enyo.de> <1mwaabp60tuqi$.1cbqxk0do4ic$.dlg@40tude.net> <87oc3dtwaa.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ruchba.enyo.de 1304850604 3497 172.17.135.6 (8 May 2011 10:30:04 GMT) X-Complaints-To: news@enyo.de Cancel-Lock: sha1:Eq0/fmuFVXdrLMo1PBT0X3uHyWs= Xref: g2news2.google.com comp.lang.ada:20161 Date: 2011-05-08T12:30:04+02:00 List-Id: * Dmitry A. Kazakov: > Then a built-in access-to-component type might be a better solution. It > would eliminate a need for components to be aliased. Since the offset is > statically known (or a function that calculates it is), it need not to be > kept anywhere. You'd still have the safety hazard with the reference to the outer record. There are is some impact on encapsulation which has to be considered. And it's not going to help with the original problem (a safer replacement for discriminants with defaults). > OK, but you need to create the first reference somehow. Uhm, I had imagined you'd use an allocator for that. The whole thing is meant to be a bit similar to access values. >>> IMO weak references are quite useless if do not support notifications (when >>> the last strong reference is removed). I.e. you need a list of weak >>> reference holders. >> >> I think they are supposed to be used for parent pointers in trees, for >> instance, to avoid the cycle issue. Not so much for finalization. > > I rather use: parent-->child is a plain pointer, child-->parent is a > strong reference. Dereferencing a weak pointer incurs a run-time check and operations on the counters (if reference counting is used), and the parent pointer is only needed for some traversal operations, so weak pointers upwards seem the way to go. > The most interesting cases for weak references are in the first line > finalization notification. E.g. cached objects. You would get that with controlled types. I don't think weak references work for caches if you have reference counts and precise finalization because the last reference to the cached object goes away too soon. There are different types of references (sometimes called "weak", too) which are cleared by the memory manager if it cannot satisfy an allocation request, but this raises awkward concurrency issues, and this wouldn't actually need references, you'd just have to register those special references with the memory manager. > I think that the issue is too varying and complex to have it > built-in. I would prefer if Ada provided mechanisms for > implementation of such stuff at the library level. E.g. user-defined > access types with primitive referencing, dereferencing, finalization > operations. Classes of access types etc. A pure library implementation would make certain optimizations difficult or impossible: for example, link-time replacement of tasking-safe counter implementations when there is no tasking, or avoidance of repeated counter operations on the same object. It also requires a lot of mechanics, adding more complexity to the language than a built-in facility.