php return в функции
Возврат значений
Использование выражения return
Пример #1 Использование конструкции return
Функция не может возвращать несколько значений, но аналогичного результата можно добиться, возвращая массив.
Пример #2 Возврат нескольких значений в виде массива
Для того, чтобы функция возвращала результат по ссылке, вам необходимо использовать оператор & и при описании функции, и при присвоении переменной возвращаемого значения:
Пример #3 Возврат результата по ссылке
Для получения более детальной информации о ссылках обратитесь к разделу документации Подробно о ссылках.
Объявление типов возвращаемых значений
В PHP 7 добавлена возможность объявлять тип возвращаемого значения. Аналогично объявлению типов аргументов можно задать тип значения, которое будет возвращаться функцией. Типы, которые можно объявить для возвращаемых значений те же, что и для аргументов фукнций.
Режим строгой типизации также работает для объявлении типа возвращаемого значения. В обычном режиме слабой типизации возвращаемое из функции значение приводится к корректному типу. При строгой типизации возвращаемое значение должно быть заданного типа, иначе будет выброшено исключение TypeError.
Если переопределяется родительский метод, возвращаемое значение дочернего метода должно быть того же типа, что и родительского. Если в родительском методе не задан тип возвращаемого значения, то и дочерний метод этот тип может не объявлять.
Примеры
Пример #4 Обычное объявление типа возвращаемого значения
Результат выполнения данного примера:
Пример #5 То же в режиме строгой типизации
declare( strict_types = 1 );
Результат выполнения данного примера:
Пример #6 Возврат объектов
function getC (): C <
return new C ;
>
Новый PHP, часть 1: Return types
Каждый мажорный релиз PHP добавляет ряд новых возможностей, некоторые из которых действительно имеют значение. Для PHP 5.3 — это были пространства имен и анонимные функции. Для PHP 5.4 — трейты. Для PHP 5.5 — генераторы. Для 5.6 — списки аргументов переменной длины.
PHP 7 имеет большое количество новшеств и улучшений, делающих жизнь разработчика легче. Но я считаю, что самым важным и долгосрочным изменением является работа с типами. Совокупность новых фич изменит взгляд на PHP разработку в лучшую сторону.
Почему поддержка строгой типизации так важна? Она предоставляет программе — компилятору или рантайму и другим разработчикам ценную информацию о том, что вы пытались сделать, без необходимости исполнять код. Это дает три типа преимуществ:
Возвращаемые типы
Первым дополнением к уже существующей системе типизации будет поддержка возвращаемых типов. Теперь можно указывать в функциях и методах тип возвращаемого значения в явном виде. Рассмотрим следующий пример:
Постфиксный синтаксис для возвращаемых типов может показаться странным для разработчиков, привыкших к C/C++ или Java. Однако, на практике подход с префиксным объявлением не подходит для PHP, т.к. перед именем функции может идти множество ключевых слов. Во избежание проблем с парсером PHP выбрал путь схожий с Go, Rust и Scala.
А теперь создадим наш репозиторий. (В качестве заглушки добавим фиктивные данные прямо в конструктор, но на практике, конечно же, необходимо иметь источник данных для нашего репозитория).
Большинство читателей быстро заметит, что `findById()` имеет баг, т.к. в случае, если мы попросим несуществующий идентификатор сотрудника PHP будет возвращать `null` и наш вызов `getAddress()` умрет с ошибкой «method called on non-object». Но на самом деле ошибка не там. Она заключается в том, что `findById()` должен возвращать сотрудника. Мы указываем возвращаемый тип `Employee`, чтобы было ясно чья это ошибка.
Что же делать, если действительно нет такого сотрудника? Есть два варианта: первый — исключение; если мы не можем вернуть то, что мы обещаем — это повод для особой обработки за пределами нормального течения кода. Другой — указание интерфейса, имплементация которого и будет возвращена (в том числе и «пустая»). Таким образом, оставшаяся часть кода будет работать и мы сможем контролировать происходящее в «пустых» случаях.
Выбор подхода зависит от варианта использования и также определяется рамками недопустимости последствий в случае невозвращения правильного типа. В случае репозитория, я бы поспорил с выбором в пользу исключений, поскольку шансы попасть именно в такую ситуацию минимальны, а работа через исключения является довольно дорогостоящей по производительности. Если бы мы имели дело со скалярной переменной, то обработка «пустого значения» было бы приемлемым выбором. Модифицируем наш код соответственно (для краткости показаны только измененные части):
Теперь getStreet() будет отдавать хорошее пустое значение.
Одно важное примечание о возвращаемых типах: при наследовании тип не может быть изменен, даже нельзя сделать его более конкретным (подклассом, например). Причина в особенностях ленивой загрузки PHP.
Возвращаемые типы являются большой, но далеко не единственной новой особенностью, расширяющей систему типов PHP. Во второй части мы рассмотрим другое, пожалуй даже более важное изменение: декларирование скалярных типов.
Php return в функции
Конструкция return
Конструкция rerurn возвращает значения, преимущественно из пользовательских функций, как параметры функционального запроса. При вызове return исполнение пользовательской функции прерывается, а конструкция return возвращает определенные значения.
Если конструкция return будет вызвана из глобальной области определения (вне пользовательских функций), то скрипт также завершит свою работу, а return также возвратит определенные значения.
Преимущественно, конструкция return используется для возврата значений пользовательскими функциями.
Возвращаемые значения могут быть любого типа, в том числе это могут быть списки и объекты. Возврат приводит к завершению выполнения функции и передаче управления обратно к той строке кода, в которой данная функция была вызвана.
Пример использования конструкции return для возврата значений типа integer:
function retfunct ()
<
return 7 ;
>
echo retfunct (); // выводит ‘7’.
?>
Пример возврата конструкцией return массивов:
Для того, чтобы функция возвращала результат по ссылке, вам необходимо использовать оператор & и при описании функции, и при присвоении переменной возвращаемого значения:
Как мы видим, конструкция return весьма удобна для применения в пользовательских функциях.
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Применение на практике
Доброго
Модуль юнга. Применение на практике
Из полученной в нэте информации вынес, что модуль Юнга есть одно из проявлений свойств упругости.
Применение принципов ООП на практике (мнение о приведенном коде)
для ленивых: 1й абзац можно пропустить ) В силу обстоятельств я начал работать, изучать.
Куда: в твой код
Зачем: для дальнейшей обработки
Хуже чего? Оператора return? 
Biggie, поробую сказать вам по-другому, оператор ретУрн, нужен для того чтобы ретурнить и если вам это не понятно, просто откажитесь от его использования вот и все.
Это очень помогает в решении различных задач. Потому что перед тем как что-то писать, ты должен четко представить себе алгоритм, по которому будет все работать.
Например простой пример:
Есть уравнение: у=7*(5+х*3). И тут сразу можно составить алгоритм простой: просим ввести Х, потом обрабатываем Х. Умножаем его на 3, прибавляем 5. И это все умножаем на 7. Так же все и в более сложных задачах.
Революция PHP7: Типы возвращаемых значений и удаление артефактов
Планируемая дата выпуска PHP7 стремительно приближается, внутренняя группа усиленно работает, пытаясь исправить наш любимый язык, сделать его как можно лучше, будут удалены артефакты прошлых версий и добавлено несколько столь желанных фич. Есть много RFC, которые можно изучить и обсудить, но в этом посте я хотел бы сосредоточиться на трех самых важных.
PHP 5.7 vs. PHP7
Также необходимо предупредить о некоторых ключевых словах, которые будут зарезервированы в PHP7, чтобы люди могли быстро привести свой код в соответствие с помощью какой-нибудь «автоматической» проверки совместимости версий PHP. Однако, как я писал в рассылке, большинство людей, которые достаточно компетентны, чтобы соблюдать совместимость своего кода с последней версией PHP, на самом деле и не используют конструкции, которые может сломать PHP7.
Обратите внимание, что пока голосование неоднозначно, это говорит о том, что идея окончательно не похоронена. Участники высказываются против 5.7 из-за отсутствия значительных изменений, но с учетом новых голосов на других RFC, они вполне могут изменить свое решение. Давайте посмотрим что произойдет.
Типы возвращаемого значения (Return Types)
С подавляющим большинство голосов «за», PHP, наконец, получил типы возвращаемых значений. Результаты голосования еще свежи, но определенны. Начиная с PHP7, мы, наконец, сможем указать правильный тип возвращаемых значений функции:
Улучшение? Однозначно. Но идеальное ли? К сожалению, нет:
Некоторые люди также жаловались на объявления типа после закрывающей скобки списка аргументов, а не перед именем функции, но для меня это придирки. Популярные языки, такие как современный C++, используют “пост”-синтаксис, при этом сохраняется возможность поиска «function foo» без какой-либо необходимости прибегать к regex-модификациям. Более того, это согласуется с тем, что использует HHVM, таким образом получается непредвиденный бонус в совместимости.
Другие жаловались на «строгость» PHP, но, как заявил один из комментаторов, вы действительно должны знать что хотите получить еще до начала кодирования, через интерфейсы и наследование чужого кода. Кроме того, пока указание возвращаемых типов необязательно, и его наличие никак не влияет на общую производительность или стабильность PHP, не нужно раздувать из этого проблему. Жаловаться на такую фичу, все равно что жаловаться на наличие ООП в PHP в те времена, когда процедурные спагетти были хорошим способом решить задачу. Языки эволюционируют, и это один из шагов в правильном направлении.
Удаление артефактов
Пост очень хорошо написан и, несмотря на очевидный гнев, заставляет меня задаться вопросом — если у вас такая кодовая база живет настолько долго, то стоит ли вообще обновляться до PHP7? И если уж настолько хочется, то стоит ли тащить все это с собой, разве не проще выявить поломанные классы и исправить их конструкторы? Вы даже можете делегировать эту задачу джуниорам, при условии достаточного покрытия кода тестами вы всегда сможете убедиться, что ничего не сломалось. И даже если тестов нет, если ваше приложение — это кусок кода непонятного качества, то вы действительно надеетесь получить выгоду от переезда на PHP7? Не лучше ли обновить ваше приложение в первую очередь?
Приговор «код, который я написал 10 лет назад, по-прежнему должен запускаться сегодня и должна быть возможность выполнить его через 10 лет» — для меня безумие — вы, безусловно, не должны ожидать подобного ни от одного популярного языка в рамках перехода от одной основной его версии к другой. Проведите параллель с реальным миром, вы не должны ожидать разрешения иметь рабов сегодня, только потому, что когда-то давно закон это разрешал. Да, был кровавый переход, но когда большинство сторонников рабства либо покаялись либо умерли, настал мир.
Стоит отдать должное Тони, он прав в том, что отстаивает свое мнение и прилагает большое количество усилий, чтобы его твердое «нет» было услышано. Но в долгосрочной перспективе это займет больше коллективных усилий по устранению проблем с конструкторами, чем если просто избавиться от проблемы прямо сейчас.
Мой совет тем, кто опасается PHP7 — стоп. Если вы не хотите обновляться, то и не делайте этого. Если вы сидели на 5.3 или 5.2 так долго (привет, любители CodeIgniter), то посидите на 5.6 еще десяток лет, не мешайте PHP быть современным. Оставьте прогресс для тех, кто готов принять его.
Что думаете вы по этому поводу? Вся эта затея с удалением артефактов бред или действительно нужный шаг?
В сторону: изменения Extension API
В качестве интересной заметки на полях, есть некоторые изменения в PHP7, которые могут стать причиной небольшой задержки с портированием расширений на версию 7. API для создания расширений попало под рефакторинг (чистку) и все может поменяться, тем не менее этот провакационный твит от Sara Golemon собрал немного внимания.
Damn. There are some serious surprises in the PHP7 Extension API changes. Not for nothin’, but it’s a good time to switch to HHVM.
— SaraMG (@SaraMG) January 3, 2015
Она в основном говорит о том, что изменения в создании расширений при переходе от 5.6 до 7 будет настолько большими, что проще узнать как делать расширения под HHVM. А затем она продолжает развивать тему серией статей на тему как создать HHVM extension.
Вы разрабатываете расширения? Изучали ли вы изменения и как вы относитесь к всему этому, не слишком ли рано сейчас говорить о будущем эффекте?
Edit: Мое внимание обратили на то, что Сара уже после всего этого начала документировать новое API расширений, совместимое и с HHVM и с PHP7. Похоже, можно делать расширения, совместимые с обоими рантаймами!
Вывод
Как обычно, недостатка в драме PHP-мир не испытывает. Как и во всех крупных революциях, на протяжении всей истории PHP7 также будет проливаться кровь, прежде чем произойдет что-то удивительное. PHP7 еще далек, так что даже если вы попали под перекрестный огонь мушкетных выстрелов, есть достаточно времени, чтобы добраться до выхода. Если ты спишь под гусеницей танка, то обе стороны могут мало что сделать, чтобы помочь тебе.
Что вы думаете об этих RFC? Как вы относитесь PHP7 в целом? Движется ли он в правильном направлении? Дайте нам знать — мы хотим услышать ваши мысли!