Re: Extending a third party tagged type while adding finalization

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p0lhk4$1okm$1@gioia.aioe.org...
> On 2017-12-09 01:17, Randy Brukardt wrote:

I was going to write a longer response, but I think we understand each 
other's positions and we're unlikely to change each other's mind by further 
talk. (And no one else seems to be reading this...) So just a closing 
summary.
...
>> But most mixed operations don't clearly belong to one ADT or another.
>> They're just things that need to be done. (Indeed, the entire top-level 
>> of a
>> program tends to be in this category - it's not going to be reusable 
>> since
>> it is tied to a particular task, it's not going to be commonly used since 
>> it
>> is the high-level operations for a particular task - and as such, 
>> spending
>> much time at all figuring out what abstract entities are involved is 
>> wasted.
>> Just get the job done, spend the effort on the building block parts of 
>> the
>> system that will be reused.)
>
> See, you mow all type abstraction running all the rest basically 
> weakly-/untyped. Why bother with ADTs if you don't let them grow?

Changing ADTs can be very difficult. (That's especially true for full OOP 
designs.) And it is highly unlikely that one will get the initial design 
correct. So in the interest of getting the maximum work done for the minimum 
effort, it's necessary to draw a line at a point where the advantages of 
ADTs are outweighed by their disadvantages. And they have clear 
disadvantages for code that isn't well-understood or experimental or is a 
pure one-off. (That's probably 80% of the code I write.)

> ...
>>>> Based on this definition, almost nothing should be an ADT, because very
>>>> little can be described only by its semantics. Humm, that's actually a
>>>> true
>>>> statement; probably we are feeling different parts of the elephant and
>>>> describing it very differently.
>>>
>>> Probably. Things you cannot associate with the semantics are
>>> implementation aspects. They can be any so long the semantics 
>>> maintained.
>>
>> I suspect you are trying to describe much more of a system by its 
>> semantics
>> than I do. As I previously noted, it just isn't worth the effort to 
>> figure
>> about abstract meanings for things unless they are either very common in 
>> a
>> system or likely candidates for reuse. There's a lot of stuff that has to 
>> be
>> done in programs that defies logical explanation, but that's 
>> irrelevant --
>> one just has to implement something that passes the test, no one cares if 
>> it
>> is elegant. (It took me a long time to come to grips with this truth.) So
>> it's important to realize that one is a lot more productive if one picks
>> their spots where to be elegant (where to use an ADT, in this 
>> discussion).
>
> Yes, this is our core disagreement. I want everything designed in ADTs 
> with a stated purpose.

I don't think that is practical -- certainly not by me. I don't think 
abstractly enough to be able to come up with abstract definitions for a lot 
of things easily. It takes a lot of effort (and time and money), and that 
effort isn't well-spent for things that aren't ever going to be reused, that 
aren't a large part of a program, and often are rather illogical (for 
instance, some of the rules of a real language like Ada). One has to be 
careful to err on the side of over-designing rather than under-designing, 
but trying to abstract everything would double the amount of effort it takes 
(for me, YMMV) to get it built. And re-factoring is always an option if it 
turns out that an ADT would actually have been useful.

                                               Randy.