Operation can be dispatching in only one type
in [ADA]
|
From: Adam Beneschan on 19 Nov 2009 11:04 On Nov 18, 11:21 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > Returning to the case where we do not want cross combinations. I thought > about it and came to the conclusion that this is single dispatch (tags are > synchronous). I think we should approach this differently. OK, this makes a lot of sense---the kind of thing I'm thinking of does seem a lot more related to "single dispatch" than to the sort of multiple dispatch in your earlier example involving a Printer and Contents. I haven't yet looked over the rest of your idea carefully yet... But at least I think we understand each other now. -- Adam
From: Robert A Duff on 19 Nov 2009 14:39 Adam Beneschan <adam(a)irvine.com> writes: > On Nov 18, 6:11�pm, Robert A Duff <bobd...(a)shell01.TheWorld.com> > wrote: > >> My objection to run-time accessibility checks is that you can't pin the >> blame on a particular line of code: >> >> � � procedure P (X : access T); >> >> P either stores the access value in a long-lived global data structure >> (in which case P(Local'Access) is a bad idea in clients) >> or P does not do that >> (in which case P(Local'Access) is just fine). >> The author of P knows which one is the case, >> but has no way (other than comments) to communicate this to >> the author of the client. >> I've never seen a case where P decides at run time which it is. > > Since I'm too lazy to look, I'm hoping you know this off the top of > your head: is there anything in the AI's about preconditions that > would allow something to be caught when P is called rather than later > in the body of P? I thought there were also some proposed attributes > that could test accessibility levels. Such things have been discussed. We're probably going to have preconditions, and I seem to recall discussing some way to query the necessary accessibility-level info. But I think perhaps the best solution is to use a named access type, or an 'in out' parameter, in most cases. Functions are going to allow 'in out' parameters (probably), so the need for access parameters is much diminished. - Bob
From: Randy Brukardt on 19 Nov 2009 18:43 "Robert A Duff" <bobduff(a)shell01.TheWorld.com> wrote in message news:wcctywq1ezh.fsf(a)shell01.TheWorld.com... > Adam Beneschan <adam(a)irvine.com> writes: .... >> Since I'm too lazy to look, I'm hoping you know this off the top of >> your head: is there anything in the AI's about preconditions that >> would allow something to be caught when P is called rather than later >> in the body of P? I thought there were also some proposed attributes >> that could test accessibility levels. > > Such things have been discussed. We're probably going to have > preconditions, and I seem to recall discussing some way to query the > necessary accessibility-level info. Memberships most likely will be extended to include accessibility checks. But I can't off-hand figure out how that could be used to do a library-level accessibility check short of declaring a named library-level access type to use in the membership. In that case, you probably should have just used the named type in the parameter in the first place and need no precondition (at least for that). Randy.
From: Randy Brukardt on 19 Nov 2009 18:54 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message news:1iipp3bn16fe2.yqa1gz1ru17a$.dlg(a)40tude.net... > On Wed, 18 Nov 2009 18:27:42 -0600, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message >> news:1wtsriaxu0s4s$.ikwnnz5teukp$.dlg(a)40tude.net... >> ... >>>> OK, I don't understand this. First, I don't understand what about >>>> accessibility checks was a disaster; >>> >>> Because they are the major contributor to hours spent on debugging >>> unhandled exceptions. >> >> That seems odd to me. I rather *like* getting unhandled exceptions, >> because >> it is almost always easy to see what the problem is from the exception >> name >> and the traceback. > > Only theoretically. Practically, the existing handlers of "legal" > exceptions get perplexed, the stack gets wound up causing a cascade of > exceptions in Finalize's. That might be true in general, but definitely not in this case: a handler for Program_Error is *always* wrong (unless it is a global handler for *any* exception), as Program_Error always represents a program bug. So I don't see how "existing" handlers can be confused. It is necessary to treat all Adjust and Finalize routines like task bodies in that they need a "when others" handler -- otherwise the exceptions are sucked up and you get completely lost. Our programming standard requires such handlers (generally, they output Exception_Information to the logging facility - and almost every significant Ada system needs some sort of logging facility). .... > The difference is that for string bound there is a way to do it safe and > for 'Access there is none (and I also agree with Robert's response.) Well, Ada 2012 (or whatever it will be called) should help that out by giving you a way to compare accessibilites (via memberships). So at least you will be able to make checks to avoid the problem. Better than nothing, but still not ideal. The better way to avoid the problem is to never, ever use anonymous access types. (Named access types have checks that are always made at compile-time for most compilers -- but not Janus/Ada, because of generic sharing.) Randy.
From: Dmitry A. Kazakov on 20 Nov 2009 03:34
On Thu, 19 Nov 2009 17:54:40 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message > news:1iipp3bn16fe2.yqa1gz1ru17a$.dlg(a)40tude.net... >> On Wed, 18 Nov 2009 18:27:42 -0600, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message >>> news:1wtsriaxu0s4s$.ikwnnz5teukp$.dlg(a)40tude.net... >>> ... >>>>> OK, I don't understand this. First, I don't understand what about >>>>> accessibility checks was a disaster; >>>> >>>> Because they are the major contributor to hours spent on debugging >>>> unhandled exceptions. >>> >>> That seems odd to me. I rather *like* getting unhandled exceptions, because >>> it is almost always easy to see what the problem is from the exception name >>> and the traceback. >> >> Only theoretically. Practically, the existing handlers of "legal" >> exceptions get perplexed, the stack gets wound up causing a cascade of >> exceptions in Finalize's. > > That might be true in general, but definitely not in this case: a handler > for Program_Error is *always* wrong (unless it is a global handler for *any* > exception), as Program_Error always represents a program bug. So I don't see > how "existing" handlers can be confused. exception when Error : others => some cleanup -- This usually becomes a problem raise; > It is necessary to treat all Adjust and Finalize routines like task bodies > in that they need a "when others" handler -- otherwise the exceptions are > sucked up and you get completely lost. Our programming standard requires > such handlers (generally, they output Exception_Information to the logging > facility - and almost every significant Ada system needs some sort of > logging facility). Yes, but this does not help. Upon exception propagation (Constraint_Error), you get some objects finalized. This in turn causes a snowball of exceptions in finalized objects, because no design is robust to hold any error at any place. In the end you have a huge log of meaningless messages, which only complicate debugging. Sometimes I which Ada had "halt at once" statement which would stop all tasks and hold any I/O. But of course the proper solution would be contracted exceptions. >> The difference is that for string bound there is a way to do it safe and >> for 'Access there is none (and I also agree with Robert's response.) > > Well, Ada 2012 (or whatever it will be called) should help that out by > giving you a way to compare accessibilites (via memberships). So at least > you will be able to make checks to avoid the problem. Better than nothing, > but still not ideal. The better way to avoid the problem is to never, ever > use anonymous access types. (Named access types have checks that are always > made at compile-time for most compilers -- but not Janus/Ada, because of > generic sharing.) The problem is not bound to only anonymous types. It also appears when you convert access types. The source type (or both) might be a formal generic parameter, so you cannot statically ensure that a "local" pointer is converted no a "less local" one. Pool specific pointers need to be converted though one target object is derived from another. Here everything is broken: generic contract, meaningless conversion, meaningless check, meaningless exception. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |