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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Extending a third party tagged type while adding finalization Date: Mon, 11 Dec 2017 10:03:26 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <4db43571-7f86-4e73-8849-c41160927703@googlegroups.com> <6496a10f-c97e-4e42-b295-2478ad464b2f@googlegroups.com> <6106dfe6-c614-4fc1-aace-74bf8d7435e3@googlegroups.com> <24767ee5-cda8-45e4-98d1-7da44757bd40@googlegroups.com> <037e7f02-9149-4648-b7c5-91f67c1c1961@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 X-Notice: Filtered by postfilter v. 0.8.2 Content-Language: en-US X-Mozilla-News-Host: news://news.aioe.org Xref: reader02.eternal-september.org comp.lang.ada:49449 Date: 2017-12-11T10:03:26+01:00 List-Id: On 2017-12-09 01:17, Randy Brukardt wrote: >> How can you tell? To me it is meaningless without considering the >> semantics. If an operation implements some part of the ADT semantics, it >> is of ADT. If it does not then it is an implementation detail and must be >> hidden unless it belongs to some other ADT. > > This seems to suggest that you are trying to make everything into an ADT (as > opposed to just a DT - "Data Type"). Absolutely. > The crux of the matter here is the > "abstract" part - there has to be a consise description of the purpose of > the type and operations. In the project documentation or else in the developer's head. Don't we (Ada community) promote think first approach? > Something spread all over the place can't have the > abstract semantics necessary for an ADT. Semantics can be modular, so can be implementation. If you do not allow that, abstractions will be limited to very basic things and the rest will remain a "datatype mess". I see that as a problem many Ada supporters have when they argue against OO. OO is an attempt to have the design mostly in terms of ADTs. Object orientation is thinking in instances of ADTs. Procedural approach is falling back to amorphous data as opposed to types and ad-hoc subprograms instead of operations/methods. > ... >>>> 1. Private type means that parts of the representation is hidden. Your >>>> definition is not related to that. >>> >>> All of the operations need to be explicit and a closed set. >>> If the representation is not hidden, that cannot be true. >> >> The representation can exactly match the type semantics, e.g. an >> enumeration type or discrete type: >> >> type Alarm is (Low, High); >> type Room_Temperature is digits ... range 0.0..30.0; >> >> [If you consider these representations.] >> >> There is nothing wrong in exposing representations telling the problem >> space's truths. Only implementation artifacts need to be hidden and only >> when they expose things breaking the abstraction. > > The problem here is that you are exposing a lot more than just the fact that > Room_Temperature is a numeric value with a range. You're also exposing the > representation details (Size, Alignment, the fact this is a float rather > than fixed representation), and a large bunch of inherent operations which > may or may not make sense for this data type (what does "**" mean for a > temperature, for instance?). I can hide operations I don't want by making them abstract. Regarding representation attributes they are ADTs from another domain. Each type is a bunch of interfaces. You need an interface of a container element in order to have arrays of temperatures. You need an interface to have pointers to temperatures. You need an interface to read/write temperatures from/to the stream etc. > The number of ADTs where exactly what Ada gives > you is correct sensible is essentially zero. Thus, the statement that the > type of an ADT has to be private. It need not to be exact. It must be inclusive. Other interfaces that do not break the abstraction of interest are OK. There is nothing wrong in having Room_Temperature'Input operation. > The types you have above cannot be ADTs (at least not in Ada), since they > expose many irrelevant implementation details. I use a lot of such types, > but I wouldn't care to try to give any sort of abstract definition for them. You cannot have insulated abstractions and so self-contained ADTs. This simply is not how the Universe works. The use of an object depends on the point of view. Each type is necessarily an implementation of a number of interfaces limited only by the design. >>> If they're not part of the package, then they are operations that use the >>> ADT, but are not part of the ADT. >> >> Now you are attempting to tie ADT with packages. Why should these be >> related. Aren't types partially defined in a chain of packages and >> completed in some other package ADT? > > No, I wouldn't say that. An ADT might be built out of some other types > (including other ADTs), but pretty much only by composition. The only > exception would be inheritance of operations from some parent type, and > those can be thought of as being repeated (implicitly) in the definition of > the new type. You also have generic instances (parametrized types) and type cloning (type X is new Y;) >> No you want to deny ADT reuse or abstraction. A matrix element can be ADT >> but the matrix and vector cannot because it uses element ADT? > > ?? Composition of ADTs makes perfect sense. That doesn't make the vector > operations (having element parameters) part of the element ADT (its clearly > part of the vector ADT). > 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? > ... >>> 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. > We're working on user aggregates and literals > for private types, and probably some other things I've forgotten. That is great news, really. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de