Viewed   144 times

In PHP 5, what is the difference between using const and static?

When is each appropriate? And what role does public, protected and private play - if any?



In the context of a class, static variables are on the class scope (not the object) scope, but unlike a const, their values can be changed.

class ClassName {
    static $my_var = 10;  /* defaults to public unless otherwise specified */
    const MY_CONST = 5;
echo ClassName::$my_var;   // returns 10
echo ClassName::MY_CONST;  // returns 5
ClassName::$my_var = 20;   // now equals 20
ClassName::MY_CONST = 20;  // error! won't work.

Public, protected, and private are irrelevant in terms of consts (which are always public); they are only useful for class variables, including static variable.

  • public static variables can be accessed anywhere via ClassName::$variable.
  • protected static variables can be accessed by the defining class or extending classes via ClassName::$variable.
  • private static variables can be accessed only by the defining class via ClassName::$variable.

Edit: It is important to note that PHP 7.1.0 introduced support for specifying the visibility of class constants.

Friday, November 25, 2022

Check this chart :)

grabbed from this article

Monday, August 1, 2022

It depends on your system, and on how you use the variable. For static variables:

Case 1: You never use the variable, and the compiler silently discards it. This cannot happen with extern variables.

Case 2: You use the variable, but you never take its address. The compiler converts use of the variable to immediate operands, just as if it were a #define or enum. The compiler can still convert extern static to immediate operands, but it must still find an address for it anyway.

Case 3: You use the variable and take its address, the compiler is forced to find a place to put it in the object code, exactly as if it were extern.

As for "data" versus "program" memory, well, that is very specific to the system you are using. On my Linux x64/ELF system, it will probably get put in the .rodata section, which goes in the same segment as code (.text), but a different segment from read-write data sections (.bss, .data). My system appears not to create a separate segment for read-only non-executable data.

Addendum: Note that the behavior is different in C++. In C++, a const variable has internal linkage by default, so static const is redundant and extern const is necessary to get a constant with external linkage.

Monday, November 7, 2022

It does refer to the correct class, it's just that, unless redeclared or otherwise the reference set is broken, static properties in subclasses are in the same reference set as in the superclass.

So you must do:

class Brother extends Mommy
    protected static $_data;


class Brother extends Mommy

$tmp = null;
Brother::$_data =& $tmp;
Tuesday, November 29, 2022

I also posted this question on scala users google group and Bill Venners one of the authors of "Programming in scala" reply had some insights.

Take a look at this: and

Here is an excerpt:

I think one goal was simply to be simpler, by having every value be an object, every operation a method call. Java's statics and primitives are special cases, which makes the language more "complicated" in some sense.

But another big one I think is to have something you can map Java's statics to in Scala (because Scala needed some construct that mapped to Java's statics for interop), but that benefits from OO inheritance/polymorphism. Singleton objects are real objects. They can extend a superclass or mix in traits and be passed around as such, yet they are also "static" in nature. That turns out to be very handy in practice.

Also take a look at this interview with Martin Odersky (scroll down to Object-oriented innovations in Scala section)

Here is an excerpt:

First, we wanted to be a pure object-oriented language, where every value is an object, every operation is a method call, and every variable is a member of some object. So we didn't want statics, but we needed something to replace them, so we created the construct of singleton objects. But even singleton objects are still global structures. So the challenge was to use them as little as possible, because when you have a global structure you can't change it anymore. You can't instantiate it. It's very hard to test. It's very hard to modify it in any way.

To Summarize:

From a functional programming perspective static members are generally considered bad (see this post by Gilad Bracha - the father of java generics. It mainly has to do with side effects because of global state). But scala had to find a way to be interoperable with Java (so it had to support statics) and to minimize (although not totally avoid) global states that is created because of statics, scala decided to isolate them into companion objects.

Companion objects also have the benefit of being extensible, ie. take advantage of inheritance and mixin composition (separate from emulating static functionality for interop).

Tuesday, December 27, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :