Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:22980 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 61857 invoked by uid 1010); 26 Apr 2006 20:59:41 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 61842 invoked from network); 26 Apr 2006 20:59:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Apr 2006 20:59:41 -0000 X-PHP-List-Original-Sender: edink@emini.dk X-Host-Fingerprint: 192.38.9.232 gw2.emini.dk Linux 2.4/2.6 Received: from ([192.38.9.232:12939] helo=gw2.emini.dk) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 10/22-19715-B3FDF444 for ; Wed, 26 Apr 2006 16:59:40 -0400 Received: from [10.0.0.11] (gw1.emini.dk [212.242.124.121]) by gw2.emini.dk (Postfix) with ESMTP id 0C2DBAE9C4; Wed, 26 Apr 2006 22:59:30 +0200 (CEST) Message-ID: <444FDF4C.4020303@emini.dk> Date: Wed, 26 Apr 2006 22:59:56 +0200 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcus Boerger Cc: php internals References: <444E0854.2000804@emini.dk> <200604251602.42837.bu@orbitel.bg> <444E2108.8050203@iamjochem.com> <749874265.20060426211537@marcus-boerger.de> In-Reply-To: <749874265.20060426211537@marcus-boerger.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Static properties From: edink@emini.dk (Edin Kadribasic) Marcus Boerger wrote: > It is just some decision that was taken that the newer OO stuff should be a > bit more strict. I don't remember any such decision. I don't even remember a discussion about it. I'm aware of the efforts of some people to make PHP less PHP and more Java and thus we end up in a situation where: class foo{}; foo::$bar = 1; is a fatal error. This makes things that I really like about PHP impossible. By now I'm used to being not constrained by a static language and having such restrictions placed on new features makes no sense to me. I write code that does things like this: class Customer { function get($id) { $res = $DB->query("select * from customer where id=".((int)$id); while ($row = $DB->fetchRow($res)) { foreach ($row as $key = $value) { $this->{$key} = $value; } } } } All nice and dynamic. Now, I thought why not make my site options work in a similar way but use class variables (a.k.a. static properties). So I made my options class class options { function load() { $res = $DB->query("select * from options"); while ($row = $DB->fetchRow($res)) { self::${$row['KEY']} = $row['VALUE']; } } } so I could for example througout my code use simple: if (options::$allow_anon) { ... } without having to make an istance of the class. Simple and beutiful PHP way. All I needed to do to get a new site option variable was to insert "into options(key, value) values ('foo', 'bar')" and I would instantly have my options::$foo. Unfortunately I was faced with a fatal error about having to declare all static properties. I was afraid that this was not caused by any technical difficulty, but by desire to make PHP less PHP. I propose that we remove this restriction in PHP 5.2.0 and that we consider this attitude towards making PHP more strict and less dynamic in the future. Edin