Everything

php

Why can constants only be scalars?

php.internals

Sara Golemon

22 years ago

Long ago I was told constants could only be scalars, so I accepted it.
Certainly ZEND_FUNCTION(define) does the check to ensure it's a scalar, but
why?

For what I can tell a zend_constant is just a container for an ordinary zval
which is refcounted and all that fun stuff.  I don't see any obvious reason
for this restriction, and my tests with those restrictions removed seem safe
enough so far...  Can someone spell it out for me with little words?

-Sara

Andi Gutmans

22 years ago

At 09:16 PM 5/7/2004 -0700, Sara Golemon wrote:

>Long ago I was told constants could only be scalars, so I accepted it.
>Certainly ZEND_FUNCTION(define) does the check to ensure it's a scalar, but
>why?
>
>For what I can tell a zend_constant is just a container for an ordinary zval
>which is refcounted and all that fun stuff.  I don't see any obvious reason
>for this restriction, and my tests with those restrictions removed seem safe
>enough so far...  Can someone spell it out for me with little words?

I don't remember all of the reasons, but the main reason is that it just
makes sense (IMO). I think constant values should be easily seen when
reading through source code. Having to read logic to see what values are in
the constants doesn't make much sense to me. I'd use variables for that.
If we start talking about class constants then it's obviously even more
important for them to be constants. You can't evaluate values during the
class definition as you don't have variables defined yet. I wouldn't want
define() to behave different from const.

Andi

Robert Cummings

22 years ago

On Sat, 2004-05-08 at 03:19, Andi Gutmans wrote:

> At 09:16 PM 5/7/2004 -0700, Sara Golemon wrote:
> >Long ago I was told constants could only be scalars, so I accepted it.
> >Certainly ZEND_FUNCTION(define) does the check to ensure it's a scalar, but
> >why?
> >
> >For what I can tell a zend_constant is just a container for an ordinary zval
> >which is refcounted and all that fun stuff.  I don't see any obvious reason
> >for this restriction, and my tests with those restrictions removed seem safe
> >enough so far...  Can someone spell it out for me with little words?
>
> I don't remember all of the reasons, but the main reason is that it just
> makes sense (IMO). I think constant values should be easily seen when
> reading through source code. Having to read logic to see what values are in
> the constants doesn't make much sense to me. I'd use variables for that.
> If we start talking about class constants then it's obviously even more
> important for them to be constants. You can't evaluate values during the
> class definition as you don't have variables defined yet. I wouldn't want
> define() to behave different from const.

I always thought constants were about imposing an unchanging nature to
the data and not about visual aesthetics when reading code :/ I too
would like to see constant support of non-scalar values.

Cheers,
Rob.

--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

Unnamed Person

22 years ago

--- Robert Cummings <robert@interjinn.com> wrote:

> On Sat, 2004-05-08 at 03:19, Andi Gutmans wrote:
> > At 09:16 PM 5/7/2004 -0700, Sara Golemon wrote:
> > >Long ago I was told constants could only be
> scalars, so I accepted it.
> > >Certainly ZEND_FUNCTION(define) does the check to
> ensure it's a scalar, but
> > >why?
> > >
> > >For what I can tell a zend_constant is just a
> container for an ordinary zval
> > >which is refcounted and all that fun stuff.  I
> don't see any obvious reason
> > >for this restriction, and my tests with those
> restrictions removed seem safe
> > >enough so far...  Can someone spell it out for me
> with little words?
> >
> > I don't remember all of the reasons, but the main
> reason is that it just
> > makes sense (IMO). I think constant values should
> be easily seen when
> > reading through source code. Having to read logic
> to see what values are in
> > the constants doesn't make much sense to me. I'd
> use variables for that.
> > If we start talking about class constants then
> it's obviously even more
> > important for them to be constants. You can't
> evaluate values during the
> > class definition as you don't have variables
> defined yet. I wouldn't want
> > define() to behave different from const.
>
> I always thought constants were about imposing an
> unchanging nature to
> the data and not about visual aesthetics when
> reading code :/ I too
> would like to see constant support of non-scalar
> values.

Same here. I have a number of static arrays that I use
for reference data that are usually encapsulated in a
function, or a global / session variable. It would be
very handy to be able to define a constant array
instead.

- Gabriel

=====

Sara Golemon

22 years ago

> > I always thought constants were about imposing an
> > unchanging nature to
> > the data and not about visual aesthetics when
> > reading code :/ I too
> > would like to see constant support of non-scalar
> > values.
>
>
> Same here. I have a number of static arrays that I use
> for reference data that are usually encapsulated in a
> function, or a global / session variable. It would be
> very handy to be able to define a constant array
> instead.
>

Whoa... easy, don't go putting words in my mouth...

I never said I wanted constants to allow arrays/objects, just wanted to
understand the reasoning which Andi explained well.  I also had an a-ha
moment over breakfast:  A constant array would require the allowance of
syntax like echo FOO[0];  which is, for my part, ugly.

-Sara

Robert Cummings

22 years ago

On Sat, 2004-05-08 at 12:35, Sara Golemon wrote:

> > > I always thought constants were about imposing an
> > > unchanging nature to
> > > the data and not about visual aesthetics when
> > > reading code :/ I too
> > > would like to see constant support of non-scalar
> > > values.
> >
> >
> > Same here. I have a number of static arrays that I use
> > for reference data that are usually encapsulated in a
> > function, or a global / session variable. It would be
> > very handy to be able to define a constant array
> > instead.
> >
>
> Whoa... easy, don't go putting words in my mouth...
>
> I never said I wanted constants to allow arrays/objects, just wanted to
> understand the reasoning which Andi explained well.  I also had an a-ha
> moment over breakfast:  A constant array would require the allowance of
> syntax like echo FOO[0];  which is, for my part, ugly.

The problem I see with the "ugly argument" is that if non-scalars were
allowed for constants then YOU (and I and everyone else) would have the
option of opting out of using constants for non-scalars (and
subsequently the above "ugly" syntax). Personally I don't see anything
ugly or wrong with using the above syntax.

Cheers,
Rob.

--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

Unnamed Person

22 years ago

--- Robert Cummings <robert@interjinn.com> wrote:

> On Sat, 2004-05-08 at 12:35, Sara Golemon wrote:
> > > > I always thought constants were about imposing
> an
> > > > unchanging nature to
> > > > the data and not about visual aesthetics when
> > > > reading code :/ I too
> > > > would like to see constant support of
> non-scalar
> > > > values.
> > >
> > >
> > > Same here. I have a number of static arrays that
> I use
> > > for reference data that are usually encapsulated
> in a
> > > function, or a global / session variable. It
> would be
> > > very handy to be able to define a constant array
> > > instead.
> > >
> >
> > Whoa... easy, don't go putting words in my
> mouth...
> >
> > I never said I wanted constants to allow
> arrays/objects, just wanted to
> > understand the reasoning which Andi explained
> well.  I also had an a-ha
> > moment over breakfast:  A constant array would
> require the allowance of
> > syntax like echo FOO[0];  which is, for my part,
> ugly.
>
> The problem I see with the "ugly argument" is that
> if non-scalars were
> allowed for constants then YOU (and I and everyone
> else) would have the
> option of opting out of using constants for
> non-scalars (and
> subsequently the above "ugly" syntax). Personally I
> don't see anything
> ugly or wrong with using the above syntax.
>
> Cheers,
> Rob.

Agreed. "ugly" is a subjective argument and does not
change the usefulness of that particular ability.
Where would the C language be without the ability to
define arbitrary constant values?

- Gabriel

=====

Andi Gutmans

22 years ago

At 03:39 PM 5/8/2004 -0400, Robert Cummings wrote:

> > I never said I wanted constants to allow arrays/objects, just wanted to
> > understand the reasoning which Andi explained well.  I also had an a-ha
> > moment over breakfast:  A constant array would require the allowance of
> > syntax like echo FOO[0];  which is, for my part, ugly.

Yes this is correct. It would not be possible to de reference such
constants with object or array syntax. Thus, allowing constants to be
defined as such would mean you'd have to assign them to variables before
using them.
I don't see this as something which should be changed. Definitely not
before 5.0 but I'm not sure it's that critical also to change afterwards
although it might be possible.

Andi

Ilya Sher

22 years ago

Andi Gutmans wrote:
[snip, text was about non-scalar constant]

> I don't see this as something which should be changed. Definitely not
> before 5.0 but I'm not sure it's that critical also to change afterwards
> although it might be possible.
>
> Andi
>

We discussed this issue with Jevon Wright (private emails)
and in the end of the day agreed that most simple yet powerful
solution is "superglobals", which would work like $_GET,$_POST
etc.
$a=array('x'=>1);
superglobal $a;
function f() {
echo $a['x'];
}
with combination of naming convention to express the constant
nature of the data for example:
$const_a=...;
superglobal $const_a;
or
$MY_PARAMETERS=....;
superglobal $MY_PARAMETERS;

HTH.

Regards,
Ilya

Sean Coates

22 years ago

Ilya Sher wrote:

> We discussed this issue with Jevon Wright (private emails)
> and in the end of the day agreed that most simple yet powerful
> solution is "superglobals", which would work like $_GET,$_POST
> etc.

This can be accomplished in user-space, by cheating the existing $_*
superglobals (if you must -- cowiki does this, IIRC):

<?php

$_SERVER['foo'] = array('bar', 'baz');

function oink()
{
print_r($_SERVER['foo']);
}

oink();

?>

S

Ilya Sher

22 years ago

Sean Coates wrote:

> Ilya Sher wrote:
>
>> We discussed this issue with Jevon Wright (private emails)
>> and in the end of the day agreed that most simple yet powerful
>> solution is "superglobals", which would work like $_GET,$_POST
>> etc.
>
>
> This can be accomplished in user-space, by cheating the existing $_*
> superglobals (if you must -- cowiki does this, IIRC):
>
> <?php
>
> $_SERVER['foo'] = array('bar', 'baz');
>
> function oink()
> {
>   print_r($_SERVER['foo']);
> }
>
> oink();
>
> ?>
>
> S
>

That is one more word (to type) to access the variable,
each time. If you acces a variable more than once in
the function you would probably like to declare it
global (the usual way). Or even
extact($GLOBALS['my_globs']);
which would be a hash of all globals one usually needs.

I don't see much of advantage here.
The most frustrating case would be one usage of a
global per function. "superglobals" would save a lot
of typing. The suggested method wouldn't.

This discussion is theoretical anyway because Andi
already said "no" ...

Andi Gutmans

22 years ago

No. At the time of introducing superglobals it was made clear this is only
for internal use and not for script use. The main reason for introducing
them was to make it easier to access $_GET, $_POST and friends mainly due
to register_globals change. As this is something which happens at
compile-time, it should not be possible to change this at run-time.

Andi

At 09:57 AM 5/13/2004 +0300, Ilya Sher wrote:

Ilya Sher

22 years ago

[snip]

> Same here. I have a number of static arrays that I use
> for reference data that are usually encapsulated in a
> function, or a global / session variable. It would be
> very handy to be able to define a constant array
> instead.
>
> - Gabriel
>
> =====
>

Agreed. Also using arrays of constants without a way
to express myself properly about the constant nature
of the arrays.