Re: fyi, very interesting Ada paper OOP vs. Readability

[NatarovVI <4KCheshireCat@gmail.com>]

>> in russian - О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
> In Russian it is: О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, which is a loan translation of
> the original English term: Abstract Data Type.

say as you wish...

>> do you really need other relations?
> Sure. The relationships should:
> 1. reflect relevant relationships of the entities from domain space
> which values of these types model.

maybe data relations will be better represented in relational db
or just some datastructure like graph?

i really think, modular structure of program must not represent
or model "domain space" entities relations complications.
program structure can always be builded flat and modular.
and this will always be good for development and maintenance.
KISS. sure, it's just imho.

> 2. serve purpose of software design per types decomposition, e.g. reuse,
> readability, maintainability etc.

yep. small number of dependencies == good reuse, readability, 
maintainability. all interaction must be rigorously defined by
detailed interface, not just "class child inherits parent".
with such interfaces you can replace parent.

>> type is builded from set's.
> Certainly not. Which type is {-3, 'a', Pi, Employee}? A type cannot be
> inferred from its values domain set. It need not to be. This is what
> gives so much power to this abstraction. You can model galaxies on a PC
> because of that.

type = set of values for type plus set of operations on type

>> directly. parent, changing youself, can do any changes on child
>> functions.
> No. In a strongly typed language there is no way to have this scenario.
> It is a type error.

ooo... seems you find "strongly typed language of dream"...
but how you catch it really?)) child not bother about parents.
can be one or other - OOP have not mechanic to differ. they place
all "can it be" decisions to programmers erroneous brain as usual.

sure, there is checksum in _compiled_ packages etc.
but it not catched by _languages_, only by some language environments.
or by tools. or by development methodology. and this is different thing.

all OOP is "technology of patches", dedicated to one-way
developing. grow and grow. only from parents to childs, no other way.
no return to correct errors. only completely rewrite...

>> child incapsulation broken, because it contains parts defined
>> elsewhere.
> This is called modular design. In any case it is fully applied to
> containment/aggregation. When you put an integer into a record, that
> brings with it integer arithmetic defined elsewhere. I find it good.

hehehe...
such architecture is not "modularity". it's "student modularity".

modularity is about independently developed replaceable parts of system,
not about _internal structure_ of this parts.
mixing internal structure of parts in architecture of project is bad 
idea. they on different layers. do not show to other parts what must
not be showed. imho. but OOP pushes this bad method as law.

when you use containment, you have better defined interface for used part.
this is not just blindly all-trusting inheritance, interactions with 
defined part is checked by typesystem. it can be strong enough, like ML's.

how do you think, why all OOP gurus now recommends limit use of 
inheritance to one-level inheritance from abstract base classes.
and recommends wider use of composition, not inheritance?
meanwhile, such "only-from-abstract" inheritance may be replaced by
message buses.

> Note also there is no way to override operations inherited for integer
> components, because their type is sealed. On the contrary, inheritance
> allows some operations re-implemented.

how do you think, what is safer:
1) provide access to all, then let dumb programmer deny access to some 
parts by sealing, "protected", etc. let state what parts are changed or 
replaced. formulate system as "old base plus patches".
2) from begin provide only needed access and only real current 
functionality. fearlessly drop old unused parts to archive completely
and formulate only "current base".
so?

>> what bad in tree-like?
> Not everything is a tree..

if you wish, chop it to relational ))

>> types represents categories of expressions.
> Egh, which category of what expression Boolean is?

forgive me my country Humpty-Dumptyness of terminology))
maybe you do not attack my each word, sir?))

> Type is a set of values bound by operations defined in terms these
> values and values of other types.

yep, i also say it. set of values and set of operations.

> This is a model of weak typing. "Weak" is another word for inconsistent.
> One reason why this is inconsistent is because you don't know the type
> of the data. It could be any. That blows any formalism up. The concept
> of typing appeared in mathematics in order to avoid antinomies.

there is moment when typing gets strong. data exists before and forewer.
and there is difference between type and kind, sure.

>> yep. data exist independently, and we attach types to it at any time.
>> and make propositions and state invariants from that moment.
> No, that is no data. Data is a definite state which means something for
> the agent consuming them. Without a type, there is no meaning and no
> data.

...maybe you just confirm that data is not always typed and _can_ exist 
without types? (usefulness of such existance is other question)
or you really want make one more flame about terminology?

you need meaning or flame?