Home » Questions » Questions

Posts by Jim

Filter
Sort by: Most Votes
1 vote
In reply to: PHP: self vs. $this

DO NOT USE SELF:: use STATIC::

There is another aspect of self:: that is worth mentioning. Annoyingly self:: refers to the scope at the point of definition not at the point of execution. Consider this simple class with two methods:

class Person
{

    public static function status()
    {
        self::getStatus();
    }

    protected static function getStatus()
    {
        echo "Person is alive";
    }

}

If we call Person::status() we will see “Person is alive” . Now consider what happens when we make a class that inherits from this:

class Deceased extends Person
{

    protected static function getStatus()
    {
        echo "Person is deceased";
    }

}

Calling Deceased::status() we would expect to see “Person is deceased” however what we see is “Person is alive” as the scope contains the original method definition when call to self::getStatus() was defined.

PHP 5.3 has a solution. the static:: resolution operator implements “late static binding” which is a fancy way of saying that its bound to the scope of the class called. Change the line in status() to static::getStatus() and the results are what you would expect. In older versions of PHP you will have to find a kludge to do this.

http://php.net/manual/en/language.oop5.late-static-bindings.php

So to answer the question not as asked …

$this-> refers to the current object (an instance of a class), whereas static:: refers to a class

NOTE: This answer was originally posted at StackOverflow.com by Sqoo

  • Jim answered 13 years ago
  • last active 11 years ago
1 vote
In reply to: Why does WordPress still use addslashes(), register_globals() and magic_quotes?

Wordpress Open Tickets over Time
(Wordpress Open Tickets over Time)

Don’t rely on the Wordpress codebase to do assumptions about good practice or current standards in PHP coding. I’m saying this as someone who has fiddled with wordpress development over a longer period of time.

Wordpress codebase is about 10 years old, it’s full of legacy code[1]. The program can not evolve on the code-level much because of that, so you find a lot of workarounds for problems that are already solved nowadays much better.

Just take this story: PHP had magic quotes. Wordpress developers thought it was useful. So for those hosts that did not have it configured, they added it. Ending up whith code that expects slashed input data often and at various places. The simple thing is, now they just can’t change it to proper input processing and sanitization easily because of the usage of (super)globals introducing static global state nearly everywhere.

You can not easily refactor such code.

Same for the database class. It has a long history, originally based on an early version of ezSQL. At that time there was not mysql_real_escape_string and when it was introduced, the WP devs had the problem that not all installation bases support it.

So don’t wonder about the coding practice you find inside the Wordpress code. You’ll learn how things could have been done years ago and with more or less outdated PHP versions. It’s not that long ago that Wordpress switched to PHP 5 for example.

  • Backwards compatibility.
  • Target a large amount of (technically more or less outdated) hosts.
  • Don’t break what works with defects.

This might not be your list of priorities (hopefully), projects differ here a lot. But having a legacy code-base alone is a burden regardless how project priorities are set. Wordpress is only one example.

[1] see Milestones of WordPress: Early Project Timeline (ca. 2000 to 2005))

NOTE: This answer was originally posted at StackOverflow.com by hakre

  • Jim answered 12 years ago
  • last active 12 years ago
Showing 2 results