Допустимо ли инициализировать функцию внутри другой?

Question

[Max Ba]

Вопрос, собственно в теме. Стиль процедурный.
Пример сайта за 5 минут.

function site(){
  header();
  
  //какой-то контент
  
  //вопрос касаемо этого участка
  require_once 'block/news_all.php';
  news_all();
  
  footer();
}

function header(){
  require_once 'theme/header.php';
}

function footer(){
  require_once 'theme/footer.php';
}

//block/news_all.php
function news_all(){
  echo 'Все новости';
}

Comments

[Max Ba]

Вопрос даже больше в том, если делается require внутри функции (со своей подключаемой функцией) получается, что видимость в рамках того места, где она подключилась?

[Moses Fender]

сразу после header() ничего происходить не станет. Попробуй.

[Max Ba]

Moses Fender, да это понятно))) Пардон. Смысл думал передам, а оно вон как)
Пусть будет site_header(); :)

[Moses Fender]

А всё остальное вполне нормально.
Скажу больше: у PHP есть ещё анонимные функции, которых можно заявлять и запускать внутри других функций сколько влезет. А если это методы класса, то в одном классе можно внутри метода запускать анонимно статичные методы другого класса.

[DanKud]

Max Ba, все подключения через require это просто вставка кода в указанное место из другого файла. Если вы вставляете его внутри функции, то и вставляется он непосредственно внутрь функции с соответствующей областью видимости.

[Max Ba]

Moses Fender, спасибо. я просто погуглил нормально так и понял, что require это как бы продолжение кода взятого из файла)
Получается некая нелогичная конструкция.

function site(){
  //...
  function news_all(){
    echo 'Все новости';
  }
  news_all();
  //...
}

Фигня какая-то) Ну это, если объявлять подключать внутри. Снаружи-то еще терпимо.

[Max Ba]

DanKud, опередил))

[Max Ba]

DanKud, а это вообще практикуется? Функция в области функции?
Опустим пока "нормальные" стили программирования.)))

[Евгений Иванов]

function site(){
  //...
  function news_all(){
    echo 'Все новости';
  }
  news_all();
  //...
}

А вот и вы подошли к ООП классу и методам. Ну ведь похоже )

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

Далее - стандартная ошибка
require_once __DIR__. '/theme/footer.php';
Пишем в пути __DIR__. Магия же!

Теперь про область видимости.
В связке функций, в функция в функции сложно понять что и где видно. А если ещё и global то будет такая неразбериха.

Поэтому делаем просто. Функция принимает параметры. Вот они и видны как снаружи (образно - при её вызове - мы передаем их в неё из вне), ну и внутри разумеется.
Этакая единая "точка входа". Удобно, логично.

Ну сказал вход - есть и выход. Т.е. return.
Ниже Имхо

Рекомендую делать так

function ololo($text)
{
if ($text=='azaza') $data='ololo!';
if ($text=='lol') $data='you troll me?';
return $data;
}

То есть одна точка входа - одна точка выхода.

А вот так не рекомендую

function ololo($text)
{
if ($text=='azaza') return 'ololo!';
if ($text=='lol') return 'troll me?';
}

Более 1 точки выхода. Более того трудно осуществить контроль/фильтрацию выходных данных.
А если функция (проект) большие, то будут проблемы.

[Max Ba]

Евгений Иванов, спасибо за такой расширенный ответ))) Я делаю в ооп обычно. Просто иногда при быстрой разработке приходится не заморачиваться, а прописать пару функция как блоков)

[Max Ba]

Евгений Иванов, кстати, а как именно подошел к ооп в конкретном примере?

[BoShurik]

Евгений Иванов, early return как раз наоборот повышает читаемость.

https://softwareengineering.stackexchange.com/ques...

public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
    int retval = SUCCESS;
    if (someCondition)
    {
        if (name != null && name != "")
        {
            if (value != 0)
            {
                if (perms.allow(name)
                {
                    // Do Something
                }
                else
                {
                    reval = PERM_DENY;
                }
            }
            else
            {
                retval = BAD_VALUE;
            }
        }
        else
        {
            retval = BAD_NAME;
        }
    }
    else
    {
        retval = BAD_COND;
    }
    return retval;
}

public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
    if (!someCondition)
        return BAD_COND;

    if (name == null || name == "")
        return BAD_NAME;

    if (value == 0)
        return BAD_VALUE;

    if (!perms.allow(name))
        return PERM_DENY;

    // Do something
    return SUCCESS;
}

[Евгений]

Max Ba, существует же рекурсия, хотя на мой взгляд это более странно, чем вызвать функцию в другой))

[Евгений Иванов]

BoShurik, в предоставленном коде выше (куча условий), проблема не в return, а в огромной вложенности.

Во втором же коде (с несколькими return) мы не можем как либо управлять возвращаемым значением. Пока пример прост и возвращается константа - выглядит вроде неплохо. Но как только это будет что то посложнее, начнется дублирование кода и прочие нехорошие вещи.

Простой пример

public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
$data='SUCCESS';

if (!someCondition) $data=BAD_COND;
if (name == null || name == "") $data=BAD_NAME;
if (value == 0) $data=BAD_VALUE;
if (!perms.allow(name)) $data=PERM_DENY;

//Ну например надо что то представить в виде json
if (cond1==true)  $data=json_encode( $data);

return $data;
}

Ну как читаемость? А всё почти тоже самое. Но в конце, вон как можно.
С множественным же return у вас пойдет множественное json_encode.
И это только верхушка айсберга.

Один вход - один выход. Управляем "потоком" информации.
Кстати, "вход" в функцию тоже может быть не один. Образно. Вот такой php.

public int SomeFunction(bool cond1=true, string name='', int value=0)

Аргументы по умолчанию. Удобно? Конечно.

SomeFunction(true); //а остальное будет по умолчанию

И тут мы, пускай не так явно, но увеличиваем неопределенность. Мы указали только 1 параметр.
Остальные не определили. Своего рода потеря управления. И, увеличение количества возможных состояний объекта. Звучит странно. Но для небольших функций - вполне приемлимо.
Для больших, взаимосвязанных функций, больших и многомодульных проектов - уже как то не очень.

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

[BoShurik]

Евгений Иванов,

в предоставленном коде выше (куча условий), проблема не в return, а в огромной вложенности.

Дык соль как раз в том, что ваш подходит заставляет писать с большой вложенностью. И чем больше условий - тем сложнее.
И тот код, который вы привели - не эквивалент моему приему. В моем случае при !someCondition мы получаем BAD_COND, а
в вашем случае мы пройдем по всем остальным условиям и, весьма вероятно, значение $data перезапишется.

А теперь представим что под // Do something скрывается, к примеру $data = $data / $value,
т.о. ваш код вывалится с ошибкой, так что без вложенности не обойтись

Я не говорю, что подход с early return нужно использовать всегда, но для ситуаций, когда надо сначала отбросить невалидные значения, использовать early return - оптимально и читается такой код на порядок легче

Но как только это будет что то посложнее, начнется дублирование кода и прочие нехорошие вещи.

Если вдруг понадобится, то код конечно перепишется под новые нужды.
А до тех пор, как вы сами сказали, "выглядит вроде неплохо.", почему бы так не делать?

С множественным же return у вас пойдет множественное json_encode.

В этой ситуации логичней использовать декорацию, но это тема отдельной дискуссии :)

[Max Ba]

Парни, я разобрался, но вы ушли совсем от темы)))
Смысл был в том, что каждый блок сайта оборачивать в функцию.
типа

function site(){
  echo site_header();
  //...
}

function site_header(){
  echo logo();
  echo menu();
  echo phones();
  //и тд.
}

function logo(){
  return '123-45-67';
}

Может это даже паттерн какой???))))) Этих паттернов пол интернета вон на любой вкус.

[Max Ba]

Просто подключались они не в файле, например - bootstrap, а по ходу дела, ну то есть в функциях)

[BoShurik]

Max Ba, паттерн называется "шаблонизатор" :)

[Max Ba]

BoShurik, )))))))

[Евгений Иванов]

BoShurik, не принципиально, каждый делает как хочет.
Не буду писать недостатки множественного ruturn. Основное - нет контроля потока данных.
Что также порождает неправильный подход к безопасности.
Ну это ИМХО сложившееся из какого - никакого опыта.
(Может когда нибудь даже напишу статью на эту тему...хотя кому это надо.)

[BoShurik]

Евгений Иванов, вот кстати есть статья по поводу раннего return

Основное - нет контроля потока данных.

Предлагается раньше возвращать только невалидные/пограничные результаты. Т.о. этот недостаток нивелируется и, я бы даже сказал, поток становится контролировать легче.

[Max Ba]

Евгений Иванов,

Основное - нет контроля потока данных.

А что контролировать на примере в стартпосте?)
Может звучит и глупо, но тк все параметры из вне передаются аргументами в функции (на примере я не стал этого делать), то как раз всё четко видно, что и откуда пришло. А не так, что открыл кусок кода, а там уже инициализировано тонна переменных. И откуда они пришли - ищи давай.