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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: What is your opinion on Global Objects? Date: Fri, 21 Nov 2014 10:01:35 +0100 Organization: cbb software GmbH Message-ID: <1tz9u84opgdwc$.a7dpkorp05gp.dlg@40tude.net> References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: nyHeW7QjJmC1odUjK4LkDA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:23597 Date: 2014-11-21T10:01:35+01:00 List-Id: On Thu, 20 Nov 2014 22:35:16 +0100, J-P. Rosen wrote: > Le 20/11/2014 21:33, sbelmont700@gmail.com a écrit : >> For what it's worth, I'm in the "pass everything as an argument" camp >> (and really functional programming in general), and loathe the >> 'hidden state' setup, for the following reasons: > Let's see what the other camp has to respond... > >> 1. You are hardcoded to a particular implementation (i.e. no dispatching) > Yes, it is more static, therefore safer and more easily provable. This is a bit contradictory. Proofs as such are always against some stated things. That already presumes several instances. Some instances may withstand the proof some don't. Thus the idea of proving an inherent singleton looks somewhat dubious. Singleton is only in the usage not a property. Anyway proving things about a type (singleton-object) might be easier than doing this for an ad-hoc package. > Dispatching is a very powerful tool, but only when you really need it. Dispatching does not make sense for singletons, but Ada won't do any dispatch anyway since the object's type is not class-wide. >> 2. You always end up needing a second object, no matter much you think you >> don't think you will. > Doesn't meet my experience. Knowing that by design there can be only one > object simplifies understanding and provability. You don't have to worry > about which object you are dealing with - there is only one. But the design may change and maintaining changes on the client side is easier when the object is properly typed rather than when it is implicit, in an assorted sets of subprograms stuffed into a package. And you forgot about reuse. A singleton implementation may use some other types implementations or provide its implementation for reuse. >> 3. The majority of the program becomes impure > ??? Please explain you notion of "purity". I understood it as: Pure = the only side effect is on the mutable arguments and/or the result. >> 5. Everything is compile-time constant (i.e. no creating or deleting things dynamically). > I would regard this as a huge benefit - dynamicity has always been > opposed to simplicity and provability. Huh, that reminds me of a relatively fresh discussion about termination of a library-level task in Ada. A typical singleton, isn't it? Yet impossible to terminate on application exit! Making it an access type (=not a singleton) or moving out of the library level solved the problem. Ego, it is not simple to have things static, though most things aren't any static anyway, not even keeping them at the library level is simple. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de