Re: Preventing type extensions

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Cyrille Comar writes on comp.lang.ada:
> On Sep 22, 10:01 am, "J-P. Rosen" <ro...@adalog.fr> wrote:
>> Ada is unique in that you can have true methods (aka primitive
>> operations) that belong to a specific type, and class-wide operations
>> that are unique for a whole subtree.
>
> what is unique about that? In C++ you also have methods and other
> subprograms taking a class as a parameter. I don't see any fundamental
> difference between the latter and what you call "classwide
> operations" (and by which I suppose you simply mean a subprogram with
> classwide parameters, right?)
>
>> Because they are unique, coverage testing drops from N to 1.
>
> No idea of what you are talking about... I suppose this is a reference
> to what OOTiA calls "pessimistic testing" but I still don't understand
> your claim.
>
>>>> For inlining, I was referring to the corresponding chapter of OOTiA
>>
>>> That's what I supposed.... There is little to be reused in that part
>>> of the document...
>>
>> I agree that there is nothing here specific to OO. However, inlining is
>> a problem when you need level A (code) coverage, because it creates
>> often dead code or hard to test paths.
>
> Level A requires statements+mcdc coverage. inlining doesn't impact any
> of those coverage metrics. It might impact object coverage, which can
> be used as an alternative method (with additional work to show
> equivalene with the aboce mentioned metrics)

My understanding (from the days when I worked at Barco Avionics) was
that level A requires full path (MC/DC) coverage at the object level,
not the source level.  This includes proof of absence of dead object
code.  The only practical way to achieve this is source-level MC/DC
coverage *plus* complete source-to-object traceability, including proof
of absence of object code not corresponding to any source.  In fact,
this is the essential difference between levels A and B.

> and it might also impact
> source-to-object traceability analysis. This is just a potentially
> complicating factor that you have to take into account when you make
> your plans and define your coding standard...

Oh, you said "just"!

>>> It is not the case. There is very little of OOTiA left in the OO
>>> supplement. It was an input to the process but the subcommittee soon
>>> realized that little could be reused. For one thing, most of the
>>> material is at the level of "coding standard" material and thus not at
>>> the right level for a standard such as DO-178.
>>
>> Sure. I would expect DO-178C to be more objectives-driven, while the
>> OOTiA was more about processes and issues. Can't OOTiA be considered as
>> a document that explores possible ways to achieve the objectives of DO-178C?
>
> not really. OOTiA raised all the issues that people had in mind when
> the document was written. Most of the issues come from either
>    - people from the certif community not knowing OO very well (the
> fear factor)
>    - people from the OO community not mastering DO-178

And people not knowing Ada and thinking that the only OO language was
C++.  I totally agree with Jean-Pierre that Ada has made a very
important contribution to OO technology in distinguishing class-wide
from specific types; C++ does not have class-wide types, it only has
class-wide *pointer* (and reference) types; and it conversely does not
have specific pointer or reference types.  Consider:

type T is tagged private;
function Construct return T'Class;
type T_Access is access all T; -- no equivalent in C++
type T_Class_Access is access all T'Class; -- equivalent to T* in C++

Object : T'Class := Construct; -- no equivalent in C++; you need a pointer

Another area where Ada helps certification is where it distinguishes
pool-specific from general access types.  C and C++ are both completely
helpless in this respect.  Consider:

type T_Access is access T'Class; -- no equivalent in C++
type T_General_Access is access all T'Class; -- equivalent to T* in C++

Hey, just a wild idea: how about

type T_Stack_Access is access aliased T;

which indicates that access values of this type can *only* designate
aliased objects that are on the stack, and never on the heap?

-- 
Ludovic Brenta.