Тонкости с include

[PHPCod3r]

в комментах вся соль.

Ну там вроде 155 коментов, читать не перечитать, причем тема не совсем та, обсуждают в основном какие то деревья, и как вывод
коментариев сделать лучше, вообщем совсем не ясно что вы имели ввиду своей фразой "в комментах вся соль.", единственое что нашлось по теме

Написали всего много, давайте теперь обратимся к теории
Что делает PHP интерпретатор когда встречает include?
ответ:
1. парсит код
2. строит дерево связей сущностей (мапинг адресов переменных и констант, деклараций классов и функций)
3. изменяет дерево исполнения.
4. исполняет.
что происходит при повторном подключении?
PHP смотрит на адреса при смене контекста и исполняет байт код собранный ранее. (если файл не меняли)
что происходит при повторном исполнении инклюда?
дерево связий есть, таблица адресов тоже, байт код даже есть, так что копируется кусок байт кода, подготовленного ранее и все (кстати в PHP4 глюки на этой почве народ ловил ^_^).
Теперь что произойдет при eval ??
тоже самое что и в случае с инклюдом, тока откроется внутренний поток ошибок.
что же происходит при повторном вызове eval ??
интерпритатор не может строить предполодений на природу кода который передан в eval поэтому проводит ВСЕ шаги заново.
Как меняет ситуацию акселератор?
в случае если у вас в подключаемом файле есть например такая конструкция echo "this"." my "." file" акселератор может заменить это на константу, убрать операции контененации, т.е. все стандартные фишки акселерации. В случае с eval код через акселератор не пропускается.

 

[TwistedAndy]

eval по большому счету зло. Я в своих проектах использую конструкции вроде:
$var = include('config.php');

В config.php примерно такой код с return:

<?php

return array('a' => 'hello', 'b' => 'world');

?>

В результате $var['a'] = 'hello', $var['b'] = 'world'. Такой трюк позволяет решить проблему с областями видимости переменных, а также более явно указать что и куда стоит загружать.

 

[PHPCod3r]

eval по большому счету зло. Я в своих проектах использую конструкции вроде:
$var = include('config.php');
В config.php примерно такой код с return:
<?php
return array('a' => 'hello', 'b' => 'world');
?>
В результате $var['a'] = 'hello', $var['b'] = 'world'. Такой трюк позволяет решить проблему с областями видимости переменных, а также более явно указать что и куда стоит загружать.

Полностью вас поддерживаю, вот кстати нашел еще такой финт, с инклюдом

<?php
function foo() {
  //some long block of code here producing $bar
  return $bar;
}
?>
//can be rewritten as:
<?php
function foo() {
  return include "foo.php";
}
?>
//where foo.php contains the following:
<?php
//long block of code producing $bar
return $bar;
?>
//The result is the function's body does not get loaded into memory until the function is actually called.

Взято из коментов к инклюду на пхп.нет, вообщем фишка в следущем, так как include может возвращать значения, то это можно использовать при описании функции, а то что сам файл не будет инклюдиться пока функция не будет использована, дает нам не большую возможность сэкономить ресурсы...
Вообщем то для меня это было новостью, кто как считает насколько это финт может быть полезным?
И насколько его уместо использовать при разработке скриптов?

 

[PHPCod3r]

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

 

[Miraage]

Полностью вас поддерживаю, вот кстати нашел еще такой финт, с инклюдом

<?php
function foo() {
  //some long block of code here producing $bar
  return $bar;
}
?>
//can be rewritten as:
<?php
function foo() {
  return include "foo.php";
}
?>
//where foo.php contains the following:
<?php
//long block of code producing $bar
return $bar;
?>
//The result is the function's body does not get loaded into memory until the function is actually called.

Взято из коментов к инклюду на пхп.нет, вообщем фишка в следущем, так как include может возвращать значения, то это можно использовать при описании функции, а то что сам файл не будет инклюдиться пока функция не будет использована, дает нам не большую возможность сэкономить ресурсы...
Вообщем то для меня это было новостью, кто как считает насколько это финт может быть полезным?
И насколько его уместо использовать при разработке скриптов?

Насколько - зависит от количества конфигураций и размера, точные цифры у всех разные, но да - прирост будет, даже небольшой.
Лично я считаю, что именно таким способом надо организовывать конфигурации в файлах.

for example

registry.php

// как было
require_once('config.php');
self::$config = $CONFIG;
// как стало
self::$config = require_once('config.php');

config.php

// как было
$CONFIG = array('host'=>'localhost','user'=>'root','pass'=>'super');
// как стало
return array('host'=>'localhost','user'=>'root','pass'=>'super');