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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.248.8 with SMTP id yi8mr588437pac.26.1416517871856; Thu, 20 Nov 2014 13:11:11 -0800 (PST) X-Received: by 10.50.73.98 with SMTP id k2mr686949igv.8.1416517871632; Thu, 20 Nov 2014 13:11:11 -0800 (PST) Path: border1.nntp.dca1.giganews.com!nntp.giganews.com!news.glorb.com!uq10no2077020igb.0!news-out.google.com!ks2ni26178igb.0!nntp.google.com!uq10no2077013igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 20 Nov 2014 13:11:10 -0800 (PST) In-Reply-To: <8561e9omp7.fsf@stephe-leake.org> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=KSa2aQoAAACOxnC0usBJYX8NE3x3a1Xq NNTP-Posting-Host: 66.126.103.122 References: <8561e9omp7.fsf@stephe-leake.org> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <65f2470c-0828-4f97-9f0e-f11966896c06@googlegroups.com> Subject: Re: What is your opinion on Global Objects? From: Adam Beneschan Injection-Date: Thu, 20 Nov 2014 21:11:11 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.giganews.com comp.lang.ada:190881 Date: 2014-11-20T13:11:10-08:00 List-Id: On Thursday, November 20, 2014 8:34:31 AM UTC-8, Stephen Leake wrote: >=20 > > That basically is a vote for global objects. Whether they are accessed > > through a global variable or some sort of getter function that returns > > access, it means bypassing the parameters. Well from what I read here, > > there are no strong opinions for either concept. Strange, I wasn't > > able to find good arguments for or against the two concepts anywhere, >=20 > If you can really, truly, absolutely guarrantee that you will _never_ > need two different copies of the data structure, then the singleton > pattern makes sense (data in a single variable in a package body). >=20 > If you ever need two different copies of the data structure, then you > need to pass it around in parameters. >=20 > The symbol table for a compiler is a good candidate for a singleton. This doesn't seem right to me. =20 I haven't followed the whole discussion closely, so I might have missed som= ething... But in the case of a symbol table, an Ada compiler that implemen= ts generics by "macro instantiation" is an example of why a symbol table sh= ould *not* be a singleton. If the compiler rescans the text of the generic= , the entire context (i.e. what symbols are visible) will change while the = generic is being instantiated, and then it will change back at the end. An= d of course the generic can instantiate another generic. This doesn't mean that any data structures are being copied. The "symbol t= able" could be implemented as a single access object, or as a smallish reco= rd that contains an access object that points to the root of the symbol tab= le and has some other housekeeping info. But it still wouldn't be a single= ton. Making it a singleton (or global) would mean that any time the contex= t has to change, some subprogram has to save the global value into a local,= change the global value, call whatever other subprogram will be using the = new context, then restore the global value from the local. I've worked wit= h this kind of arrangement and have suffered from numerous migraines as a r= esult. (That's one of the reasons I try not to use singleton objects in ge= neral; there have been too many times when it's seemed clear that there nee= ds to be only one instance of something, and it's come back to bite me.) In any case, though, I don't know what it has to do with "copies of a data = structure". That seems to be the wrong criterion, especially in a case lik= e a compiler symbol table. Perhaps I just view the world too differently f= rom you, or you're just used to working with different examples than I am. -- Adam