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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 23 May 2012 17:39:25 +0000 (UTC), NatarovVI wrote:

>>> 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?

That has nothing to do with types. Data relations are ones between
individual instances = between *values*. All RDB relations are values of
just one type. (There was C. Date's "third manifesto" to change that, but
so far not much happen)

Relations between types is a very different thing. Compare:

1. 5 and -5 are in relation as a value and its additive inverse.

2. N (integers) and R (reals) are related numeric types, latter is a
continuation of the former. R is a field = implements the interface of a
field. N is a ring etc.

> program structure can always be builded flat and modular.

No, that would be unmaintainable with the programs sizes common today and
technically impossible too, due to lack of even minimal reuse.

>> 2. serve purpose of software design per types decomposition, e.g. reuse,
>> readability, maintainability etc.
> 
> yep. small number of dependencies == good reuse, readability, 
> maintainability.

Reuse is impossible without substitutability. Substitutability
automatically means that the corresponding types are related =
substitutable.

>>> 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

q.e.d.
 
>>> 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.
> 
> 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...

I don't see any relevance.

>>> 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.

So, integer components are not modular? What is your point?

> how do you think, why all OOP gurus now recommends limit use of 
> inheritance to one-level inheritance from abstract base classes.

They must be eating or smoking something...

I don't care much about OOA/D literature. 90% of it is just garbage, in my
humble opinion of course.

>> 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?

I don't see how this question proves your point, which was, I quote: 

"child incapsulation broken, because it contains parts defined elsewhere."

Operations of an integer component are defined *elsewhere*. So, why a thing
from "elsewhere" is good when composed and bad when inherited?

>>> 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?))

In order to understand the point, yes. There is nothing wrong with any
terminology when explained. But we seem agreed that type is a set of values
+ operations.

>>> 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?

Data are *always* typed. This is why there is no data without a type. It is
meaningless to talk about a value without any operations defined. Because
without them you cannot operate it. You cannot copy it, you cannot compare
it, you cannot tell if it the same value, you cannot do anything.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de