Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:17560 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49067 invoked by uid 1010); 6 Aug 2005 13:56:53 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 49051 invoked from network); 6 Aug 2005 13:56:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Aug 2005 13:56:53 -0000 X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.4/2.6 Received: from ([204.11.219.139:33273] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 36/A0-04646-4A1C4F24 for ; Sat, 06 Aug 2005 09:56:52 -0400 Received: from [192.168.2.106] (c-24-6-1-160.hsd1.ca.comcast.net [24.6.1.160]) (authenticated bits=0) by colo.lerdorf.com (8.13.4/8.13.4/Debian-3) with ESMTP id j76DunCp004116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Aug 2005 06:56:49 -0700 Message-ID: <42F4C1A1.1050109@lerdorf.com> Date: Sat, 06 Aug 2005 06:56:49 -0700 User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ron Korving CC: internals@lists.php.net References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] custom superglobals From: rasmus@lerdorf.com (Rasmus Lerdorf) Ron Korving wrote: > Hi, > > Wouldn't it be a good feature to have users create their own superglobals? I > think it would be good for at least two reasons (rather similar though): > > - Application settings can be stored in such a global, so that objects can > use them without needing the information passed to functions or using the > rather ugly "global" statement. > > - A singleton constructor could use it to grab information. Normally, in my > own database abstraction layer, I would create the database object and pass > the constructor information on where to connect. I don't want to implement > my DB class to open a file to read connection information and I don't want > it to use the "global" statement. This presents a problem if I want it to be > a singleton object, because I'd need the information everytime I call > getInstance() which is of course not really an option. Personally, I don't > consider using a superglobal from within the constructor an ugly practice. That's what $GLOBALS is for. -Rasmus