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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,81bb2ce65a3240c3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.238.67 with SMTP id vi3mr3675969pbc.6.1337292114488; Thu, 17 May 2012 15:01:54 -0700 (PDT) Path: pr3ni10893pbb.0!nntp.google.com!news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Fri, 18 May 2012 01:01:53 +0300 Organization: Tidorum Ltd Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <20780405.1069.1336372385458.JavaMail.geo-discussion-forums@pbkc8> Mime-Version: 1.0 X-Trace: individual.net S23ccMBSXGQR0LFX4tc+OgYQxus9ClPy1d1Mw9U8vZeZqWb7wSr9vLpbtOQxN2gWYX Cancel-Lock: sha1:E9GhJicsh/JS/ArqCVnCbRUHvVc= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-05-18T01:01:53+03:00 List-Id: On 12-05-16 03:19 , Randy Brukardt wrote: > "Niklas Holsti" wrote in message > news:a1g0h2Fm2bU1@mid.individual.net... > > (I did read your whole message, but since I have to leave here ASAP, I'm > just going to answer a quick summary.) > > ... >> The widening derivation only adds. The deepening derivation changes, by >> refining. > > I have never wanted to "refine" an enumeration. I do it often, but in current Ada I have to do it "in reverse", by defining the most detailed enumeration first, and then coarsening it into larger-grained concepts by defining subtypes. For example, I write: type Detailed_Message_Kind is ( Sign_On, Read, Write, Data, Ack, Refused, Sign_Off); and then coarsen it to subtypes: subtype Request is Detailed_Message_Kind range Read .. Write; subtype Reply is Detailed_Message_Kind range Data .. Refused; This works, but it is a bit error-prone when I need to add some literals and make sure that they go in the right subtype, and of course the collection of "coarsening" subtypes does not itself form an enumeration, so I cannot, for example, loop over all the "coarser" concepts. > Perhaps its not even > something I would think of (because it's not possible, so why even consider > it), so I can't be certain that's because its rare, but off-hand, I can't > think of any possible use of such a construct. > > Well, one, where you have a specific literal in your original type for > "future expansion", and you then hang new literals on it. That is, using > "deepening" to emulate "widening". > > So that's the main problem I have with your concept: it doesn't solve any > real problems that I have. OTOH, the need to add a new (operation, border > style, font choice, etc.) happens all of the time. But surely, in most such cases, the right solution is to open an editor and add the new literals to the original type declaration, isn't it? The constant assumption in this discussion -- although perhaps not explicitly stated -- is that we are talking about situations where we want to keep the parent type around in its original form, and instead derive a new type, with a specific relationship to the parent type. A valid reason for this could be, for example, that some operations can be written in general form on the parent type, and then inherited by several derived types, or that the same genericity can be got from classwide programming on Parent'Class. > I'm definitely not > certain that there is anything that can be gained from having a language > feature to do this. Nor am I certain, but I felt that the "deepening" idea was at least significantly better than the "widening" method in AI95-261, so I presented it for discussion. Thank you for taking part. > I understand your desire to keep apples and oranges separate, but typically > these don't share operations either (most of the operations on these fruits > are completely different - think removing seeds). But such operations can be overridden, or even defined separately as overloading, for the two types. > That's why the value of > untagged derived types is low (and that carries over to tagged types for > many kinds of operations - few things map as well to OOP as GUIs). It may be beside the point, but I have found OOP in the form of tagged type hierarchies (rooted in abstract types) to be a very good method for decoupling subsystems in my programming (and no GUI around). > I could easily see a version of Dmitry's user-defined conversions to allow > two otherwise separate types to share operations (but not representations), > but a more specific feature just doesn't have enough bang-for-the-buck (the > "buck" here being the effort to define and implement this in language > terms). Fair enough, thanks. I don't think Dmitry's proposal would cover "deepened" enumeration types, because there is no natural conversion from the parent type to the "deepened" type. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .