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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
