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 X-Received: by 10.224.172.129 with SMTP id l1mr28723860qaz.4.1373616359937; Fri, 12 Jul 2013 01:05:59 -0700 (PDT) X-Received: by 10.49.133.201 with SMTP id pe9mr1230609qeb.34.1373616359890; Fri, 12 Jul 2013 01:05:59 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.bbs-scene.org!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!t19no1290417qam.0!news-out.google.com!f7ni2066qai.0!nntp.google.com!t19no1290416qam.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 12 Jul 2013 01:05:59 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=20.133.0.8; posting-account=g4n69woAAACHKbpceNrvOhHWViIbdQ9G NNTP-Posting-Host: 20.133.0.8 References: <69246de0-4b33-4d47-b5be-a45e8c911fb0@googlegroups.com> <4d7e6232-1e3b-4ad8-b754-16d6e8642006@googlegroups.com> <91927795-6b9d-41d5-b885-2709d96fc1f9@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada202X: Easy to use "UML private"-like components From: Martin Injection-Date: Fri, 12 Jul 2013 08:05:59 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:16318 Date: 2013-07-12T01:05:59-07:00 List-Id: On Friday, July 12, 2013 7:57:28 AM UTC+1, Simon Wright wrote: > I would have thought it'd make more sense to provide accessors for the > public attributes (and not for the others) while keeping the public > attributes themselves private (protected?), since derived(?) classes > _should_ be able to see the protected attributes? But, that said, it > doesn't seem unreasonable to map the model's attribute visibilities to > accessor visibilities. What else should you do? Exactly...esp as both attributes & their set/get can each have their own visibility...and you can see those on any OMD...why would you *not* reflect them as-is in the code?... My assumption is that the out-the-box behaviour is lost in the mists of time but they can't change it without being non-backwards compatible. I guess it's a little like having to remember "-gnato" ;-) -- Martin