comp.lang.ada
 help / color / mirror / Atom feed
From: sbelmont700@gmail.com
Subject: Dynamic accessibility
Date: Wed, 13 Jun 2012 14:31:29 -0700 (PDT)
Date: 2012-06-13T14:31:29-07:00	[thread overview]
Message-ID: <d2894d55-cb84-461c-8b82-da32093eda4b@googlegroups.com> (raw)

Hi,

   Does anyone have any insight or historical perspective as to why it is that access parameters carry a dynamic lifetime along with them, whereas access discriminants do not?  I cannot think of a good reason why you would want to try and explicitly typecast an access parameter anyway, so it would seem easier on everyone had parameters been defined statically as discriminants are (i.e. lifetime as being declared inside the subprogram, so that it is checked by the compiler and forbids all attempts at typecasting).  
   
   On the other hand, if there is a good reason for doing it, then it would seem appropriate that one would need the same ability for access discriminants as well; i.e. carry along the dynamic lifetime so that someone could explicitly typecast it and save it somewhere else, exactly like an access parameter.
   
   Is there some sort of esoteric accessibility conundrum that requires the rules be like this, or is it a judgment call?  Was it just that the implementation of discriminants would be more costly than that of parameters?  Was the intention to provide a mechanism for both, so that a programmer could choose either way?  Or is it just that the lack of out parameters for functions and inability to dispatch on named access types required a backdoor in case an unlucky programmer was forced into an access parameter, but needed to get back the 'real' type of controlling operand?
   
   Thanks for any opinions, rants, or special secrets anyone might know.
   
-sb



             reply	other threads:[~2012-06-14 17:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-13 21:31 sbelmont700 [this message]
2012-06-21 18:43 ` Dynamic accessibility Randy Brukardt
2012-06-22  0:43   ` sbelmont700
2012-06-22 20:03     ` Randy Brukardt
2012-06-24 16:51       ` sbelmont700
2012-06-26 22:53         ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox