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,ee887b7593f7961b X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad.newshosting.com!newshosting.com!newspeer.monmouth.com!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada OS based on Minix3 Date: Tue, 11 Nov 2008 17:09:54 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1pmkcuemqczer.j2i34pvc2lne$.dlg@40tude.net> <81912719-8c66-439d-a40e-529b22acd8a6@u29g2000pro.googlegroups.com> <14t6hwu8udm8j$.1x339y69m2ew1.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1226441394 1045 192.74.137.71 (11 Nov 2008 22:09:54 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 11 Nov 2008 22:09:54 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:WAj55MtM4b4jQh+1cFIYTAbLHJA= Xref: g2news2.google.com comp.lang.ada:8382 Date: 2008-11-11T17:09:54-05:00 List-Id: "Dmitry A. Kazakov" writes: > On Mon, 10 Nov 2008 10:31:27 -0500, Robert A Duff wrote: > >> "Dmitry A. Kazakov" writes: >> >>> 6. Proper construction/destruction >> >> What do you see as the limitations/problems with Ada in this area? > > 1. User-defined initialization/finalization shall be definable for any > type. I do mean any. Finalization: Agreed, but the compiler really needs to take care to avoid distributed overhead. Initialization: Use function calls. They work for all types. I think we've discussed this idea before, but I don't remember any fundamental problems. The Initialize procedure of controlled types seems unnecessary to me (although something needs to be done regarding abort deferral). > 2. Composition rules of initialization/finalization for derived types must > ensure execution of the user-defined initialization/finalization code for > the base type. Agreed (except I think you mean "parent type", not "base type"). This is a more general issue -- it would be useful to say "must call parent op" for various things, including Finalize. > 3. User-defined initialization/finalization shall be definable for > class-wide types. AKA dispatch from constructor/destructor. Actually, a > part of the pos. 1. OK. There are some interesting issues here -- the constructor (a function, in my mind) might want to plug a pointer-to-classwide into some global data structure, but I want to make sure the specific-typed thing is fully initialized and ready to be dispatched to, before that happens. > 4. Task-as-a-component problem to be solved. Which problem is that? > 5. Getting a pool-specific pointer to the object upon > initialization/finalization, when the object is allocated in such a pool. > (Unchecked_Conversion is really nasty there) I think you mean Unchecked_Access -- Unchecked_Conversion is not necessary. I don't see how this can make sense. In Initialize or Finalize, you don't know whether the object is in a pool, nor which pool. So how can you get a pool-specific pointer? Also, given point 1 ("any type") the thing being init/finalized could be a bitfield component of a packed record. Pointers to bitfields could cause distributed overhead, if you're not careful. > 6. LHS/RHS issue. What issue is that? How about: 7. It would be nice if Finalize would be passed a parameter indicating the reason for finalization (normal exit, some exception occurrence, abort). Perhaps also an ability to declare that finalization only applies to certain "reasons". 8. Interactions with user-defined storage pools. 9. Interactions with garbage collection. 10. Reify the finalization operation (that is, the operation on some type that calls Finalize on all the parts of it, including the whole). - Bob