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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,36a29c2860aff686 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news4.google.com!feeder.news-service.com!tudelft.nl!txtfeed1.tudelft.nl!feeder.erje.net!news.internetdienste.de!noris.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Thu, 02 Dec 2010 00:24:14 +0100 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101129 Thunderbird/3.1.7 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Properties References: <3b84c8e7-1a51-4a7c-9646-119f1fc51478@s4g2000yql.googlegroups.com> <4cf24d13$0$6985$9b4e6d93@newsspool4.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <4cf6d91e$0$6980$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 02 Dec 2010 00:24:15 CET NNTP-Posting-Host: f8afc260.newsspool4.arcor-online.net X-Trace: DXC=]EA2C?8<`ejVhT]Gi\06@l@lP3WSn]E`?od X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:16708 Date: 2010-12-02T00:24:15+01:00 List-Id: On 12/1/10 8:52 PM, Martin Krischik wrote: > Am 28.11.2010, 13:37 Uhr, schrieb Georg Bauhaus : > >> As such, an ASIS enabled Ada processor should be able to write >> these without too much effort. > > Not from a readability point. The argument for properties is that they don't clutter your code. Imagine that when 'Image, 'Value etc. pp where purposed your solution was choosen and code generator would actually add the code for those functions into source. Would that not look hyper ugly. I don't see how "automatic" get/set subprograms offer software engineering advantage, even when they are terse and semi-implicit and purport to avoid repetitive clutter. It's the desire for the structural clutter that get/set style really is that I find worrisome. I'd like to mention an alternative language design idea by Jeffrey Kingston for contrast with get/set style for record components. Whenever you invoke an operation of an object, you create a new object. Observe the programs resulting from get/set style. If they are working, aren't they typically hiding spaghetti coding, and privacy intrusion? There certainly are ways of justifying programs in spite of these qualities. One is the post hoc fallacy: "The get/set feature works, since this program works. Therefore, to choose the get/set approach was right." If the post hoc fallacy helps you as a person to get along, fine. If the post hoc fallacy helps bring customers to Ada, that's fine for the vendors, I'd say. Is it fine, though, with those companies in industry needing to maintain software in order to stay competitive? There is an everyone-does-it argument in favor of get/set. I list some use cases. Which ones do I miss? - array like access to data structures. The low level style thinking shines through. Sometimes just right. Worth a language change? - GUI field updates Forms have not really become "smarter", though, after 30 years of writing form input logic. (Oh, I see! If we did the software engineering thing and use good algorithms instead of record component assignments bridled by get/set, still à la FORTRAN 66, we will not make any more money by writing the same programs over and over. The old ones still work... O.K., that's a point.) - data base objects For building a layer on top of relational records, OK. For quick and dirty database scripting it might be enough to update some field in some view (or table) through some setter. As a design guide, get/set let me understand the many reports about data bases whose handling requires intimate knowledge of the details of every program and of every table. - ... OK, I'm biased as I'm usually the one who cleans up after those who think that getting and setting is the best software design principle. Anyway, one can always add get/set to Ada since that eases the transition from the other languages who have added get/set in very recent years, too. And exclude get/set from SPARK for the more critical programs. ~