Re: procedural vs object oriented

Ludovic Brenta wrote:
Dmitry A. Kazakov wrote:

On 27 Apr 2006 03:42:10 -0700, Ludovic Brenta wrote:

Dynamic dispatching, by definition, means that you don't know which
subprogram you call at run-time. The compiler guarantees that the call
will succeed (i.e. that there exists a subprogram to dispatch to),
but there is uncertainty about which one it is.

(I have an impression that it will not be true in Ada 200Y.)


No, nothing changes in this respect, just synctactic sugar.


OK, but this is the same uncertainty as in X + 1. You don't know X, so the
result selected by "+" is uncertain (to you.) Are programs using "+"
certifiable?


Yes, programs using "+" are certifiable. To obtain the certification,
you prove that X+1 is within range and that the operation does not
raise an exception. Ada's type safety features go a long way to help us
there, so we only have to test for a few boundary cases. SPARK takes
that to its logical conclusion, i.e. static proof.


A static procedure call has no uncertainty: when you read the program
source, you know exactly which subprogram is called, even in the
presence of overloading.

Well, no:

if Read (File) then
Foo;
else
Bar;
end if;

The uncertainty of a dispatching call is one of the context, exactly as in
the example above.


Nothing in your example is uncertain. Whatever path execution takes,
you know exactly what's happening.


Provided, that there is nothing uncertain in how
dispatching works or what potential targets do.


But with compiler-provided dynamic dispatching, there *is* uncertainty
as to how dispatching works and what the targets are.

This is something I'm not getting in this discussion. Provided that you know all derived classes, you know all possible dispatchings and you can validate all for correctness and time the worst one. How's this different than evaluating all branches in a case?

It's true that you don't have the information at the calling point, but you have it elsewhere.


.

Relevant Pages

  • Re: Abusing tagged types
    ... One of the nice things in Ada is the ability to make a difference between a method and a subprogram. ... IMHO, the term method should be reserved to operations that have a general semantics, but whose implementation depends on the type to which it applies. ... Methods make sense only in the presence of dynamic dispatching, i.e. the ability to tell an object: ... Although subprograms may have a parameter of a non-tagged type which is in some sense distinguished, they are not methods by my definition, and I would not favour using that notation. ...
    (comp.lang.ada)
  • Re: How to test object hierarchy
    ... > I know that for a subprogram to be dispatching, ... It must defined in the same package *spec* (visible part or private ... One obscure point is that if you override an inherited subprogram, ... It has to be declared in the same declarative region in ...
    (comp.lang.ada)
  • Re: procedural vs object oriented
    ... subprogram you call at run-time. ... The compiler guarantees that the call ... To obtain the certification, ... dispatching works or what potential targets do. ...
    (comp.lang.ada)
  • Re: abstract sub programs overriding
    ... Finalize for the parent type would be called--after it had been ... > and then calling a dispatching routine on this classwide type. ... language lawyers and compiler vendors should worry about those cases. ...
    (comp.lang.ada)
  • Re: procedural vs object oriented
    ... but what uncertainty of dynamic dispatching is ... Or, maybe, "certification" is the context of? ...
    (comp.lang.ada)