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: some trivial questions? Date: Tue, 21 Nov 2017 11:26:23 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <6a5368c5-f015-4dcb-9291-e77b40fa1bf1@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.4.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.2 X-Mozilla-News-Host: news://news.aioe.org Xref: feeder.eternal-september.org comp.lang.ada:49029 Date: 2017-11-21T11:26:23+01:00 List-Id: On 2017-11-20 23:03, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:ouotuh$1ig3$1@gioia.aioe.org... >> On 2017-11-18 02:14, Randy Brukardt wrote: > ... >>> Changing names of overloadable things is not a maintenance hazard unless >>> the >>> things have the exact same profile. (And that's a problem by any >>> definition, >>> having two identical entities with different meanings.) >> >> And if they are not overloadable I still can use long names. Use-clause >> makes nothing worse than already is. > > Giving things junk names to avoid name conflicts is more evil than even > package use clauses. ;-) Sure, remove one of the use-clauses then. The point is that either there must be no conflicts or else all of them must be explicitly resolved. It is more like manifested vs. implicit approach. > See the bogus naming conventions of C systems where encoded type > names are jammed into other things. That makes it all the harder to > model the problem space (rather than the solution space). I think it is more related to C's weak typing and thus lack of overloading than to a single name space. >> Sure, nothing useful going to happen for Ada. > > I agree that this is annoying. The problem is that an incompatible Ada would > be starting over from scratch (as existing libraries would not be usable), There are lots of changes which can be made while keeping everything compatibility. The problem is with small increments. That does not work. If we want to do something real this must be done in one large jump. This worked for Ada 95 once, it can work again. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de