From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b076e6315fd62dc5 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.195.165 with SMTP id if5mr24169630pbc.1.1337626478412; Mon, 21 May 2012 11:54:38 -0700 (PDT) Path: pr3ni21957pbb.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: fyi, very interesting Ada paper OOP vs. Readability Date: Mon, 21 May 2012 20:53:07 +0200 Organization: cbb software GmbH Message-ID: References: <1ir29foizbqv1.v9uuhpykjl3n.dlg@40tude.net> <1qkmythqujvoa$.h4megbum9r4c$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 4RFYTQ6jM/dAKFJoI0fUkg.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="iso-8859-5" Content-Transfer-Encoding: 8bit Date: 2012-05-21T20:53:07+02:00 List-Id: On Mon, 21 May 2012 17:23:24 +0000 (UTC), NatarovVI wrote: >> ADT was. > > in russian - ���������� ������ In Russian it is: ����������� ��� ������, which is a loan translation of the original English term: Abstract Data Type. >> A poor abstraction also, because it fails to capture any types >> relations, beyond trivial containment. > > 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. 2. serve purpose of software design per types decomposition, e.g. reuse, readability, maintainability etc. > 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. >> How? > > 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. > 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. 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. >> Containment breaks information hiding principle, separation of interface >> and implementation, incapable to express referential semantics, enforces >> tree-like structure of objects, break proper abstraction of semantically >> integral types ... should I continue? > > nope, all remains isolated in "subcontainer". and if we change it, > "subcontainer" module interface changes and clients see it. As I said, it defeats the information hiding principle. A leaking abstraction is a poor one. > what bad in tree-like? Not everything is a tree.. >> How reading can be context free? > > here is difference i talked about. when you read non-polymorphic prog, > you have "one static context" - language definition. 1. You forgot ad-hoc polymorphism and statically parametric one, which are still there without any inheritance. The operation "." (record member extraction) is heavily overloaded, that is ad-hoc polymorphism. 2. There are visibility scopes bringing declarations of types, objects, subprogram. The thing you envision exists only in Assembler, probably not even there. >> Type are not forms of program. > > types represents categories of expressions. Egh, which category of what expression Boolean is? Type is a set of values bound by operations defined in terms these values and values of other types. >> Data does not exist without types, moreover they do not exist without >> the agents interested in these data. In a larger context there are only >> values, sets of values, types (sets of values bound by operations >> defined). > > not exactly. data exist independently. then we attach types to it and can > do operations (of type). one data can have more than one type. 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. >> Data is a definite state of some input to some program. That state is >> described in terms of values of defined types from the problem domain. >> So 2 could be data for the left argument of integer +, or an ASCII >> character STX, or standard output descriptor, or whatever. > > 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de