Prev: Mail Function Using PEAR Issues
Next: Get Power Saving Settings of the Server
From: Nathan Rixham on 20 Apr 2010 13:37
Gary . wrote:
> On Mon, Apr 19, 2010 at 3:12 PM, Ashley Sheridan wrote:
>> On 19 April 2010 14:24, Gary wrote:
>
>>> Okay. Why not?
> ...
>> Class constants must be defined with static values, not variables. They are constants after all! If they relied on the value of a variable, surely that would mean that their own value might change, so they would just become regular variables not constants.

a constant is something constant (doesn't change), something static is
something static (persistently there, but may change)

> Right. But in fact the only referenced values are *also* constant
> (unless I'm completely misunderstanding the use of 'const'), so I
> think it's a valid thing to want to do. I accept it doesn't seem to be
> possible, I'm now curious as to the thinking behind it.
>
>> Is there a specific reason that you need to try and achieve this?
>
> Okay, well here's a more meaningful situation, perhaps:
> class SomeTable
> {
> const TABLE_NAME = 'mytable';
> const SELECT = 'SELECT * FROM ' . MyTable::TABLE_NAME;
> const INSERT = 'INSERT INTO ' . MyTable::TABLE_NAME ...
>

try

public static $INSERT = 'INSERT INTO ' . MyTable::$TABLE_NAME ...

self::$INSERT

> If the table name should change for some reason, it is preferable to
> make the change in one place in the code (i.e. the value of
> TABLE_NAME), surely, than changing the name in the alternative, which
> is something like:
> class SomeTable
> {
> // const TABLE_NAME = 'mytable';
> const SELECT = 'SELECT * FROM mytable';
> const INSERT = 'INSERT INTO mytable...

First  |  Prev  | 
Pages: 1 2 3
Prev: Mail Function Using PEAR Issues
Next: Get Power Saving Settings of the Server