Re: Re: class const versus define

Richard Lynch schreef:

Richard Lynch schrieb:

Is there any reason why the logic behind define() couldn't be pushed

down to class const?

Code like this is kinda fugly: //It's okay here, but not in a class? define('CACHE_DIR_LONG', CONFIG_ROOT_PATH . '/cache/'); class Cache { const CACHE_DIR = '/dev/shm/cache/'; const CACHE_TTL = 300; //5 minutes const CACHE_DIR_LONG = CACHE_DIR_LONG; I'd really prefer to write: class Cache { const CACHE_DIR = '/dev/shm/cache/'; const CACHE_TTL = 300; //5 minutes const CACHE_DIR_LONG = CONFIG_ROOT_PATH . '/cache/'; I'm happy to add it as a feature request, but not if somebody

reliable says "Don't Bother"...

Hi Richard, the define function is to be used on the global scope of your application. This is helpful to assign Configurations Options and other data that you do not will move. For the Class Constants you define the Constant only fo the Class where you are working. Please read the documentation about this on PHP.NET http://de.php.net/manual/en/language.oop5.constants.php

I understand the difference quite well, thank you.

lol

I need the PATH to differ in development, staging, and production due to mixed environments. Unfortunately, I CANNOT construct a class const "on the fly" from global define'd constants and constant strings. Yet, the logic that makes it possible to do that for define itself in some kind of pre-processor should not be terribly difficult to push down to the class level, I would think.

did you read my reply? define() ia runtime function, const is a compile time declaration. one is fast the other is slow.

So, in fact, I'd LIKE to use the class const properly for what it is mean for, but cannot do that because its value depends upon the environment.

great, then I suggest once more environment specific values don't belong in class constants. do you have full control over the servers in question? if so then one trick you might like to try is this: drop an app.ini into the /etc/php.d/ dir (I assume php is built to read additional ini files, if not add it to your php.ini) with something like the following: myapp_cache_dir = /foo/bar/qux myapp_another_dir = /foo/bar/another then in your app you can retrieve and set the data like so Cache::init(get_cfg_var('myapp_cache_dir')); where Cache::init() does something like: Cache { $private $cacheDir = '/my/default/cache/dir'; function init($dir) { if ($dir) self::$cacheDir = $dir; } } this works fairly fast (I tested various workable methods of defining/using installation specific app settings some time ago ... this came out on top), the ini file is only parsed once (i.e. when apache/fastcgi starts up) and get_cfg_var() is rapido because it only looks at ini values as they we're defined originally (as opposed to ini_get() which needs to check whatever the current value might have been changed to, etc) as you say, ymmv, and there are always other ways to skin the cat.

PS Apologies for the legal disclaimer over which I have no control; not even the silly punct- uation it ended up with in plain-text email. Sigh.

lol, figured as much ... didn't seem very lynch-like

_______________________________________________________ The information in this email or in any file attached hereto is intended only for the personal and confiden- tial use of the individual or entity to which it is addressed and may contain information that is propri- etary and confidential. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communica- tion is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product. Email trans- mission cannot be guaranteed to be secure or error- free. P6070214