Operation can be dispatching in only one type
in [ADA]
|
From: Robert A Duff on 18 Nov 2009 21:11 "Randy Brukardt" <randy(a)rrsoftware.com> writes: > OTOH, doing something that even generates a runtime accessibility check is a > bug IMHO (it's what Bob Duff calls a "tripping hazard"... I didn't invent the term. ;-) I think I first heard it from OSHA regulations, when I was working in a factory making "real stuff" instead of software. For example, I just found this by googling "OSHA tripping hazard": Extension cords that could cause a tripping hazard. This is an easy area for OSHA to find violations while auditing most organizations. Extension cords are a major cause of tripping and fall hazards and therefore are under a microscope. Extension cords shall not be found passing through hallways, windows and other areas which could cause a tripping hazard. ... and train employees how to use the cords without creating a tripping hazard. 29 CFR 1910.310 & 1910.305(G)(2)(iii) >... - a latent problem > that will bite you when someone does something unconventional -- in that > sense it is just like the bug of assigning a string parameter has lower > bound 1); it would be useful if the compiler could optionally point out such > places so you could fix them. 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. So we have a run-time check on something that is known at compile time (by the person who wrote P), and should be known at compile time (by the person who wrote the client). Yes, it's a tripping hazard. And when the exception is raised, we don't know whether P or client-of-P is at fault. - Bob
From: tmoran on 18 Nov 2009 21:23 > package Documents is > > type Document is abstract tagged private; > type Text_Region is abstract tagged private; > type Marker is abstract tagged private; > ... > procedure Move_Text (Doc : in out Document; > From : in Text_Region; > To : in Marker) > is abstract; There's really no way at compile time to require a particular relationship between two (or more) arbitrary parameters to a procedure. If that's necessary, you usually combine them into a single object that's a single parameter. Thus if a Document could have up to 10 defined Text_Regions and 20 Markers one could say type Document is abstract tagged private; -- Presumably includes an array or list of appropriate Text_Region -- descriptors and of Marker descriptors. type Text_Region_Ids is range 1 .. 10; type Marker_Ids is range 1 .. 20; procedure Move_Text (Doc : in out Document; From : in Text_Region_Ids; To : in Marker_Ids) is abstract;
From: Dmitry A. Kazakov on 19 Nov 2009 03:32 On Thu, 19 Nov 2009 02:23:07 +0000 (UTC), tmoran(a)acm.org wrote: >> package Documents is >> >> type Document is abstract tagged private; >> type Text_Region is abstract tagged private; >> type Marker is abstract tagged private; >> ... >> procedure Move_Text (Doc : in out Document; >> From : in Text_Region; >> To : in Marker) >> is abstract; > > There's really no way at compile time to require a particular > relationship between two (or more) arbitrary parameters to a procedure. > If that's necessary, you usually combine them into a single object that's > a single parameter. Yes, this is why I consider these cases single dispatch on a tuple of types. It is like type Editing is interface (Document, Region, Marker); And the operations are in fact defined on Editing, which has only one tag. > Thus if a Document could have up to 10 defined > Text_Regions and 20 Markers one could say > > type Document is abstract tagged private; > -- Presumably includes an array or list of appropriate Text_Region > -- descriptors and of Marker descriptors. > > type Text_Region_Ids is range 1 .. 10; > type Marker_Ids is range 1 .. 20; > > procedure Move_Text (Doc : in out Document; > From : in Text_Region_Ids; > To : in Marker_Ids) > is abstract; It is not ADT. ID does not have finalization and cannot refer to a specific Document. You will not be able to transparently manage Regions and Markers. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 19 Nov 2009 03:50 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. > OTOH, doing something that even generates a runtime accessibility check is a > bug Isn't it an advise to use only 'Unchecked_Access? (:-)) I think it is a problem that the code containing 'Access or upcast pointer type conversions is "suspicious", a subject of careful inspection for false positives upon accessibility check: Upcast_Ptr (P) -- Unsafe P.all'Access -- Unsafe P.all'Unchecked_Access -- "Safe" > IMHO (it's what Bob Duff calls a "tripping hazard" - a latent problem > that will bite you when someone does something unconventional -- in that > sense it is just like the bug of assigning a string parameter has lower > bound 1); it would be useful if the compiler could optionally point out such > places so you could fix them. 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.) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Adam Beneschan on 19 Nov 2009 10:57
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. -- Adam |