Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33194 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 6133 invoked by uid 1010); 17 Nov 2007 03:34:15 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 6118 invoked from network); 17 Nov 2007 03:34:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Nov 2007 03:34:14 -0000 Authentication-Results: pb1.pair.com smtp.mail=sean@caedmon.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=sean@caedmon.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain caedmon.net from 64.15.79.181 cause and error) X-PHP-List-Original-Sender: sean@caedmon.net X-Host-Fingerprint: 64.15.79.181 iconoclast.caedmon.net Linux 2.5 (sometimes 2.4) (4) Received: from [64.15.79.181] ([64.15.79.181:60962] helo=iconoclast.caedmon.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 83/58-51194-6316E374 for ; Fri, 16 Nov 2007 22:34:14 -0500 Received: from localhost (localhost [127.0.0.1]) by iconoclast.caedmon.net (Postfix) with ESMTP id 26DF9E8008; Fri, 16 Nov 2007 22:34:05 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at iconoclast.caedmon.net Received: from iconoclast.caedmon.net ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Utr11xuXDQpf; Fri, 16 Nov 2007 22:33:57 -0500 (EST) Received: from [10.8.0.2] (sarcasm.vpn [10.8.0.2]) by iconoclast.caedmon.net (Postfix) with ESMTP id 338DEE8003; Fri, 16 Nov 2007 22:33:57 -0500 (EST) Cc: Sam Barrow , internals@lists.php.net Message-ID: <6743D10C-4AE9-4974-B0C3-3A632A0326F1@caedmon.net> To: Michael McGlothlin In-Reply-To: <473E5F4F.2020508@swplumb.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 16 Nov 2007 22:34:03 -0500 References: <8D.46.01128.768AD374@pb1.pair.com> <1195246391.21084.15.camel@sbarrow-desktop> <1195250285.4012.6.camel@johannes.nop> <1195251014.21084.20.camel@sbarrow-desktop> <473E349E.3050704@swplumb.com> <1195259494.10547.2.camel@sams-room> <0E6C7DB2-4126-4660-A813-E21C03045247@caedmon.net> <473E5F4F.2020508@swplumb.com> X-Mailer: Apple Mail (2.915) Subject: Re: [PHP-DEV] Re: Question about superglobals From: sean@caedmon.net (Sean Coates) > So the idea now is to inappropriately force everything to be a class? >> It is appropriate. That's how it was designed. Obviously superglobals were not designed to be user-definable. If configuration is defined in a class, then as a maintainer, you can easily determine where the data was defined (unless you do things are even less appropriate), but simply looking up the class. Globals (and superglobals) can be defined _anywhere_. This makes them a maintenance nightmare, and a very inappropriate place to store data such as configuration information. S