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: a07f3367d7,4ce5890331a5b529 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder2.ecngs.de!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Discriminants of tagged types Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <14314714-e92c-4036-9cbb-da8e72489261@h7g2000yqn.googlegroups.com> <3243de1d-c6b4-4845-ab5f-28ea4e9f5738@c20g2000yqj.googlegroups.com> <14f33f04-40f5-4a72-a18b-d511dd2eb3b3@w21g2000vby.googlegroups.com> Date: Thu, 28 Oct 2010 12:28:56 +0200 Message-ID: <1golp1kh7fc3j$.aeqd3d3zlf60$.dlg@40tude.net> NNTP-Posting-Date: 28 Oct 2010 12:28:56 CEST NNTP-Posting-Host: de6e5e60.newsspool4.arcor-online.net X-Trace: DXC=g;W<3\jj4VMU`5g[@c]@JA4IUK On Thu, 28 Oct 2010 01:50:51 -0700 (PDT), Maciej Sobczak wrote: > On 28 Pa�, 09:53, "Dmitry A. Kazakov" > wrote: > >>> Because tagged types usually represent entities that are bound to some >>> resources >> >> This has nothing to do with copying. Consider a handle of a resource, e.g. >> HWND as an example. It is bound to the resource, nevertheless it is >> copyable. > > Just like a file descriptor. Yet, there is no reason for these things > to be polymorphic. Nonsense. The handles must be typed. The relationships between their types must reflect ones of the types of the target objects. Example, the handle to an edit control must have a type derived from the type of a handle to a window. > Now consider a window or a file (as opposed to handle or descriptor). > They are different from handles and descriptors in that they represent > the target resources together with their lifetime management. That is, > I expect that finalizing the window object leads to the window being > closed or that finalizing the file object leads to the file being > flushed and closed, etc. Copy operations for such types are > meaningless. That depends on the concrete case. There is much sense to be able to copy a file or a graphical context. > What would it mean to copy a file object? Should the file on disk be > copied as well? Yes, the file is on the disk, isn't it? > Should the data that is still in the buffer be copied? Yes. The data in the buffer is an implementation detail of which the file user does not care. That is, the observable behavior shall not depend on the implementation. If you copy a file it is copied independently on whatever buffers be in whatever state. > And so on. Instead of answering these questions in an unsatisfactory > way, it is better to outlaw the dubious operation up front. Programming is all about answering questions in unsatisfactory ways. The goal is to minimize unsatisfaction. (:-)) >> Rather the opposite, most of container types are not copyiable [*] > > Is Vector limited? In which library? It could be or could be not. I designed unbounded arrays not copyable. >> most of them are very useful to derive from [**]. > > I don't see any justification for this. Maybe you don't, but as a matter of fact, I derive from 3/4 of container types I use. The container implementation provides an implementation to adjust. It is a design tool, not an end product. The way types (tools) are applied constitutes the types algebra. Derivation is one of the most important operations of the algebra. That is why ideally any type shall be inheritable. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de