Magiczne stałe

PHP zapewnia szeroki zakres predefiniowanych stałych każdemu skryptowi, który jest uruchamiany. Wiele z tych stałych jest jednak dostępnych dzieki różnym rozszerzeniom i można z nich korzystać jedynie, kiedy te rozszerzenia sa dostępne przez dynamiczne załadowanie, badź też zostały wkompilowane.

Istnieje dziewięć magicznych stałych, które zmieniają sie w zależności od tego, gdzie są użyte. Na przykład, wartość __LINE__ zależy od linii, w której ta stała została użyta w skrypcie. Wartość wszystkich "magicznych" stałych jest określana w trakcie kompilacji, w przeciwieństwie do normalnych stałych, które są ustalane w trakcie uruchamiania skryptu. All these "magical" constants are resolved Nazwy owych magicznych stałych są niezależne od wielkości liter:

Kilka "magicznych" stałych PHP
Nazwa Opis
__LINE__ Aktualna linia pliku.
__FILE__ Pełna scieżka i nazwa pliku z rozwiązanymi dowiązaniami symbolicznymi. Jeśli użyta wewnątrz dołączonego pliku, zwracana jest jego nazwa.
__DIR__ Nazwa katalogu pliku. Jeśli użyta wewnątrz dołączonego pliku, zwraca nazwę jego katalogu. Odpowiada dirname(__FILE__). Zwracana nazwa nie zawiera końcowego ukośnika, chyba że jest to katalog root.
__FUNCTION__ Nazwa funkcji lub (closure) dla funkcji anonimowych.
__CLASS__ Nazwa klasy. Zawiera przestrzeń nazw, w której została ona zadeklarowana (np. Foo\Bar). Zauważ, że od PHP 5.4.0 __CLASS__ działa także w traitach. Kiedy użyta w metodzie traita, __CLASS__ jest nazwą klasy, w której został użyty trait.
__TRAIT__ Nazwa traita. Zawiera przestrzeń nazw, w której został on zadeklarowany (np. Foo\Bar).
__METHOD__ Nazwa metody.
__NAMESPACE__ Nazwa aktualnej przestrzeni nazw.
NazwaKlasy::class W pełni wykwalifikowana nazwa klasy. Zobacz także ::class.

Zobacz także get_class(), get_object_vars(), file_exists() i function_exists().

Rejestr zmian

Wersja Opis
5.5.0 Dodano magiczną stałą ::class
5.4.0 Dodano stałą __TRAIT__
5.3.0 Dodano stałe __DIR__ i __NAMESPACE__
5.0.0 Dodano stałą __METHOD__
5.0.0 Przed tą wersją, wartości niektórych stałych magicznych były zapisane małymi literami. Teraz wszystkie uwzględniają wielkość znaków (zawierają nazwy, tak jak je zdeklarowano).
4.3.0 Dodano stałe __FUNCTION__ i __CLASS__
4.0.2 __FILE__ zawsze zawiera ścieżkę absolutną z rozwiązanymi linkami symbolicznymi, podczas gdy w starszych wersjach czasem zawierała ścieżkę relatywną

add a note add a note

User Contributed Notes 9 notes

up
285
vijaykoul_007 at rediffmail dot com
18 years ago
the difference between
__FUNCTION__ and __METHOD__ as in PHP 5.0.4 is that

__FUNCTION__ returns only the name of the function

while as __METHOD__ returns the name of the class alongwith the name of the function

class trick
{
      function doit()
      {
                echo __FUNCTION__;
      }
      function doitagain()
      {
                echo __METHOD__;
      }
}
$obj=new trick();
$obj->doit();
output will be ----  doit
$obj->doitagain();
output will be ----- trick::doitagain
up
38
Tomek Perlak [tomekperlak at tlen pl]
17 years ago
The __CLASS__ magic constant nicely complements the get_class() function.

Sometimes you need to know both:
- name of the inherited class
- name of the class actually executed

Here's an example that shows the possible solution:

<?php

class base_class
{
    function
say_a()
    {
        echo
"'a' - said the " . __CLASS__ . "<br/>";
    }

    function
say_b()
    {
        echo
"'b' - said the " . get_class($this) . "<br/>";
    }

}

class
derived_class extends base_class
{
    function
say_a()
    {
       
parent::say_a();
        echo
"'a' - said the " . __CLASS__ . "<br/>";
    }

    function
say_b()
    {
       
parent::say_b();
        echo
"'b' - said the " . get_class($this) . "<br/>";
    }
}

$obj_b = new derived_class();

$obj_b->say_a();
echo
"<br/>";
$obj_b->say_b();

?>

The output should look roughly like this:

'a' - said the base_class
'a' - said the derived_class

'b' - said the derived_class
'b' - said the derived_class
up
12
david at thegallagher dot net
12 years ago
You cannot check if a magic constant is defined. This means there is no point in checking if __DIR__ is defined then defining it. `defined('__DIR__')` always returns false. Defining __DIR__ will silently fail in PHP 5.3+. This could cause compatibility issues if your script includes other scripts.

Here is proof:

<?php
echo (defined('__DIR__') ? '__DIR__ is defined' : '__DIR__ is NOT defined' . PHP_EOL);
echo (
defined('__FILE__') ? '__FILE__ is defined' : '__FILE__ is NOT defined' . PHP_EOL);
echo (
defined('PHP_VERSION') ? 'PHP_VERSION is defined' : 'PHP_VERSION is NOT defined') . PHP_EOL;
echo
'PHP Version: ' . PHP_VERSION . PHP_EOL;
?>

Output:
__DIR__ is NOT defined
__FILE__ is NOT defined
PHP_VERSION is defined
PHP Version: 5.3.6
up
10
php at kenman dot net
10 years ago
Just learned an interesting tidbit regarding __FILE__ and the newer __DIR__ with respect to code run from a network share: the constants will return the *share* path when executed from the context of the share.

Examples:

// normal context
// called as "php -f c:\test.php"
__DIR__ === 'c:\';
__FILE__ === 'c:\test.php';

// network share context
// called as "php -f \\computerName\c$\test.php"
__DIR__ === '\\computerName\c$';
__FILE__ === '\\computerName\c$\test.php';

NOTE: realpath('.') always seems to return an actual filesystem path regardless of the execution context.
up
10
Sbastien Fauvel
8 years ago
Note a small inconsistency when using __CLASS__ and __METHOD__ in traits (stand php 7.0.4): While __CLASS__ is working as advertized and returns dynamically the name of the class the trait is being used in, __METHOD__ will actually prepend the trait name instead of the class name!
up
11
chris dot kistner at gmail dot com
13 years ago
There is no way to implement a backwards compatible __DIR__ in versions prior to 5.3.0.

The only thing that you can do is to perform a recursive search and replace to dirname(__FILE__):
find . -type f -print0 | xargs -0 sed -i 's/__DIR__/dirname(__FILE__)/'
up
4
meindertjan at gmail dot spamspamspam dot com
10 years ago
A lot of notes here concern defining the __DIR__ magic constant for PHP versions not supporting the feature. Of course you can define this magic constant for PHP versions not yet having this constant, but it will defeat its purpose as soon as you are using the constant in an included file, which may be in a different directory then the file defining the __DIR__ constant. As such, the constant has lost its *magic*, and would be rather useless unless you assure yourself to have all of your includes in the same directory.

Concluding: eye catchup at gmail dot com's note regarding whether you can or cannot define magic constants is valid, but stating that defining __DIR__ is not useless, is not!
up
0
public at taliesinnuin dot net
3 years ago
If you're using PHP with fpm (common in this day and age), be aware that __DIR__ and __FILE__ will return values based on the fpm root which MAY differ from its actual location on the file system.

This can cause temporary head-scratching if deploying an app where php files within the web root pull in PHP files from outside of itself (a very common case). You may be wondering why __DIR__ returns "/" when the file itself lives in /var/www/html or whathaveyou.

You might handle such a situation by having NGINX explicitly add the necessary part of the path in its fastcgi request and then you can set the root on the FPM process / server / container to be something other than the webroot (so long as no other way it could become publicly accessible).

Hope that saves someone five minutes who's moving code to FPM that uses __DIR__.
up
-39
Anonymous
12 years ago
Further clarification on the __TRAIT__ magic constant.

<?php
trait PeanutButter {
    function
traitName() {echo __TRAIT__;}
}

trait
PeanutButterAndJelly {
    use
PeanutButter;
}

class
Test {
    use
PeanutButterAndJelly;
}

(new
Test)->traitName(); //PeanutButter
?>
To Top