note 71621 added to language.oop5.constants

From: Date: Fri, 08 Dec 2006 04:58:12 +0000
Subject: note 71621 added to language.oop5.constants
Groups: php.notes 
Request: Send a blank email to php-notes+get-120421@lists.php.net to get a copy of this message
In realizing it is impossible to create dynamic constants, I opted for a "read only" constants class. <?php abstract class aClassConstant { /** * Setting is not permitted. * * @param string constant name * @param mixed new value * @return void * @throws Exception */ final function __set($member, $value) { throw new Exception('You cannot set a constant.'); } /** * Get the value of the constant * * @param string constant name * @return void */ final function __get($member) { return $this->$member; } } ?> The class would be extended by another class that would compartmentalize the purpose of the constants. Thus, for example, you would extend the class with a DbConstant class for managing database related constants, that might look like this: <?php /** * Constants that deal only with the database */ class DbConstant extends aClassConstant { protected $host = 'localhost'; protected $user = 'user'; protected $password = 'pass'; protected $database = 'db'; protected $time; /** * Constructor. This is so fully dynamic values can be set. This can be skipped and the values can be directly assigned for non dynamic values as shown above. * * @return void */ function __construct() { $this->time = time() + 1; // dynamic assignment } } ?> You would use the class like thus: <?php $dbConstant = new DbConstant(); echo $dbConstant->host; ?> The following would cause an exception: <?php $dbConstant = new DbConstant(); $dbConstant->host = '127.0.0.1'; // EXCEPTION ?> It's not pretty, nor ideal, but at least you don't pollute the global name space with long winded global names and it is relatively elegant. Variables must be *protected*, not public. Public variables will bypass the __get and __set methods!! This class is, by design, not meant to be extended much further than one level, as it is really meant to only contain constants. By keeping the constant definition class seperate from the rest of your classes (if you are calling this from a class), you minimize the possibility of accidental variable assignment. Managing this instance may be a slight pain that requires either caching a copy of the instance in a class variable, or using the factory pattern. Unfortunately, static methods can't detect the correct class name when the parent name is used during the call (e.g., DbConstant::instance()). Thus there is no elegant, inheriting solution to that problem. Thus, it is easier to simply manage a single instance that is declared using conventional notation (e.g., new DbConstant...). - Michi Kono ---- Server IP: 216.194.113.175 Probable Submitter: 69.238.99.222 ---- Manual Page -- http://www.php.net/manual/en/language.oop5.constants.php Edit -- https://master.php.net/note/edit/71621 Del: integrated -- https://master.php.net/note/delete/71621/integrated Del: useless -- https://master.php.net/note/delete/71621/useless Del: bad code -- https://master.php.net/note/delete/71621/bad+code Del: spam -- https://master.php.net/note/delete/71621/spam Del: non-english -- https://master.php.net/note/delete/71621/non-english Del: in docs -- https://master.php.net/note/delete/71621/in+docs Del: other reasons-- https://master.php.net/note/delete/71621 Reject -- https://master.php.net/note/reject/71621 Search -- https://master.php.net/manage/user-notes.php

« previous php.notes (#120421) next »