Alright, I guess I'll start the discussion on PHP constant use in phpBB4.
The big thing for me is that I'd like to see the PHPBB_ROOT_PATH and PHP_EXT from the old 3.2 branch code brought back -- it really helps readability of the code and reduces the need for globaling in variables.
Table constants are something I see of issue in phpBB3. If you try to tie in major apps with phpBB, there is the risk of constant names conflicting. In my opinion, table constants should stay as normal global constants (as opposed to class constants) and should have a new naming scheme.
Table constants should be created like so: PHPBB_{table name}_TABLE. Some examples: PHPBB_USERS_TABLE, PHPBB_SESSIONS_TABLE.
Having the PHPBB_ prefix for the table name helps reduce the risk of constants conflicting when integrating multiple applications.
Constants
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Re: Constants
PHP 5.3 supports namespaces, which would be much cleaner than adding phpbb_ prefixes all over the place.Desdenova wrote:Having the PHPBB_ prefix for the table name helps reduce the risk of constants conflicting when integrating multiple applications.
If possible the design should be in a way that these are no longer needed. Autoloading can do quite a lot. But if they should be needed in some places then constants would be the way to go, I agree.Desdenova wrote:The big thing for me is that I'd like to see the PHPBB_ROOT_PATH and PHP_EXT from the old 3.2 branch code brought back -- it really helps readability of the code and reduces the need for globaling in variables.
Re: Constants
PHP extension is only of real concern to user facing scripts we shouldn't use it everywhere.
-
- Registered User
- Posts: 653
- Joined: Wed Sep 21, 2005 3:01 pm
Re: Constants
one small issue is that php is a bit brain-damaged wrt constants.
what i mean is this: if you have a variable named $VAR, you can create a string so:
$str = "blah blah $VAR blah"; (bad),
or
$str = "blah blah {$VAR} blah"; (good),
the 2nd form even supports arrays and objects, eg:
$str = "blah blah {$VARAR[12]} blah";
$str = "blah blah {$VAROBJ->filed} blah";
and the $VAR or {$VAR} are replaced by the value of this variable.
a reasonable expectation would be that if you have a constant CONST, the following should also work
$str = "blah blah {CONST} blah";
however, here there will be no substitution[1], so yo end up doing
$str = 'blah blah ' . CONST . ' blah'; (yuck!)
for this reason, we see stuff like
$sql = 'select a b c from ' . TABLE_X . ' where column = value;'
if we kept the table names in something other than constant, we could write it as:
$sql = "select a b c from {$tables->TABLE_X} where column = value;"
or
$sql = "select a b c from {$tables['TABLE_X']} where column = value;"
both of which are, IMO superior to the use of constants.
just some food for though...
peace.
[1] here is where php is brain damaged, IMO, because i can't see any downside to extending the syntax to support {CONST} expansion.
what i mean is this: if you have a variable named $VAR, you can create a string so:
$str = "blah blah $VAR blah"; (bad),
or
$str = "blah blah {$VAR} blah"; (good),
the 2nd form even supports arrays and objects, eg:
$str = "blah blah {$VARAR[12]} blah";
$str = "blah blah {$VAROBJ->filed} blah";
and the $VAR or {$VAR} are replaced by the value of this variable.
a reasonable expectation would be that if you have a constant CONST, the following should also work
$str = "blah blah {CONST} blah";
however, here there will be no substitution[1], so yo end up doing
$str = 'blah blah ' . CONST . ' blah'; (yuck!)
for this reason, we see stuff like
$sql = 'select a b c from ' . TABLE_X . ' where column = value;'
if we kept the table names in something other than constant, we could write it as:
$sql = "select a b c from {$tables->TABLE_X} where column = value;"
or
$sql = "select a b c from {$tables['TABLE_X']} where column = value;"
both of which are, IMO superior to the use of constants.
just some food for though...
peace.
[1] here is where php is brain damaged, IMO, because i can't see any downside to extending the syntax to support {CONST} expansion.
Re: Constants
You can't declare class constants on the fly, however. It's not something readily done, which makes it less suitable for use with anything that extends the core.