Re: Full view of a private partial view cannot be a subtype

["Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>]

On 12/05/2017 01:35 PM, Jere wrote:
> 
> You run into the same issues with composition (only in my view worse).  With
> composition you still have to look up each component's file to see it's
> operations and worse yet you have no tools that can help you extrapolate
> what operations are available from a higher level component.  With extension
> you can at least use auto completion lists to see what all the options are.
> With composition you are stuck doing X.<see list> then X.Y.<see list> then
> X.Y.Z.<see list> and so on.  Then the component chaining when wanting to call
> an ancestor's operation can quickly blow up with composition (as opposed to
> extension where there is a single level).  You can simplify this by creating
> forwarding functions in the higher level components, but that is analogous
> to adding overloads in the higher level components for extension.  For either
> it is optional.

If you're lucky enough to have such a tool. I still find myself reading code 
without such assistance often enough that I think that code that is only 
readable with a tool is not readable at all.

But your argument is about ease of writing, with isn't going to convince anyone 
who likes Ada. Ada explicitly states in the ARM Introduction that it's for code 
that's easy to read, not easy to write. The fact that you type more with 
composition is not an argument against it.

But in my design a client wouldn't have X.Y.Z... It would apply an operation to 
a variant record X and the operation would do the correct thing for the current 
variant. If you needed to find the actual code executed without a tool, there's 
a chain of with clauses to lead you to it. You don't end up looking at an 
abstract subprogram with no idea where the actual subprogram is.

> I respect yall's view on this, but in either case it is still a subjective
> matter.  There are a variety of people out there who all view things very
> differently.

I disagree. There are a set of S/W-engineering principles that help guide the 
S/W engineer to create S/W that is simple, correct, and easy to read. Every 
real-world use of type extension that I've seen has violated the principle of 
locality--that's inherent in the nature of type extension. Thus it is 
objectively more complex and harder to read than S/W that violates none of the 
principles.

-- 
Jeff Carter
"I did not rob a bank. If I'd robbed a bank, everything
would be great. I tried to rob a bank, is what happened,
and they got me."
Take the Money and Run
139