Comments 22
удаление индексированных массивов array_merge
Что то не понял, или пример такой
PHP постоянно развивается, и только что мир увидело их последнее обновление — PHP 7.4.
Предварительная загрузка — одно из самых ярких обновлений. Эта возможность позволяет значительно ускорить выполнение скрипта и делает код чище и быстрее ...
Чище?
Я, конечно, понимаю, что в php7.4 добились прироста производительности, но сколько можно сравнивать php7.* и php5.6? Имхо намного интереснее узнать прирост по сравнению с php7.3. А ещё лучше таблицей 5.6-7.4
Ещё одним преимуществом PHP 7.4 является функциии-генераторы.
Если не ошибаюсь, генераторы еще в 5 версии появились.
И вообще статья какая-то… даже не могу слово подходящее подобрать. Ничего особо нового не сообщает. Мутная что-ли.
P.S. Такое пишут, когда написать нечего, но хочется.
Подскажите, а как так вордпресс стал эталоном замера производительности пхп? Всегда в пример приводят в основном именно его.
Нет более популярного решения, которое в случае ускорения все заметят.
Я так понимаю, потому-что основная масса использует вордпресс
35% of the Internet is Powered by WordPress
$array = [‘dog, ‘cat’];
$array[2] = ‘cat’;
$array[1] = ‘giraffe’; //shifting
var_dump($array);
// prints
array(3) {
[0]=>
string(6) «dog»
[1]=>
string(5) «giraffe»
[2]=>
string(6) «cat»
чем это принципиально отличается от поведения в 7.3?
и какое это имеет отношение к array_merge?
P.S. помимо этого в примере синтаксическая ошибка
P.P.S. что за «shifting» упомянут в комментарии?
только здесь на лицо тупая перезапись индексов и никакого смещения не наблюдается, а про array_merge я вообще молчу хз каким боком он сюда притянут :)))
shifting — типа «giraffe» вклинился, а «cat» переместился на индекс «2»Это ошибочная интерпретация, на самом деле:
php > $array = ['dog', 'cat'];
php > $array = ['dog', 'cat'];
php > var_export($array);
array (
0 => 'dog',
1 => 'cat',
)
php > $array[2] = 'cat';
php > var_export($array);
array (
0 => 'dog',
1 => 'cat',
2 => 'cat',
)
php > $array[1] = 'giraffe'; //shifting
php > var_export($array);
array (
0 => 'dog',
1 => 'giraffe',
2 => 'cat',
)
php >
Давайте взглянем на пример ниже.
Класс PHP 7.3:
class User {
/** @var int $id */
private $id;
/** @var string $name */
private $name;
public function __construct(int $id, string $name) {
$this->id = $id;
$this->name = $name;
}
public function getId(): int {
return $this->id;
}
public function setId(int $id): void {
$this->id = $id;
}
public function getName(): string {
return $this->name;
}
public function setName(string $name): void {
$this->name = $name;
}
}В PHP 7.4 классы выглядят намного проще:
class User {
public int $id;
public string $name;
public function __construct(int $id, string $name) {
$this->id = $id;
$this->name = $name;
}
}А вот это что? Автор с переводчиком отменили инкапсуляцию?
Не стоит путать инкапсуляцию и бойлерплейт. Если придираться, то и и в первом и во втором случае она одинаково нарушается.
А не могли бы вы развернуть мысль
Если придираться, то и и в первом и во втором случае она одинаково нарушается
чуть шире?
Ну если примитивным языком, то инкапсуляция — это всё же сокрытие реализации. Можно даже утрированно (sic!) заявить, что когда понимаешь как реализовано по интерфейсу, то тогда инкапсуляция нарушена.
Более того, для данного DTO с примитивным get/set — ничего "скрывать" не нужно, т.к. это его задача — быть тупым типизированным контейнером для данных, а не реализовывать какую-то логику. Как раз добавление какой-либо лишней логики туда будет очень плохой затеей (никто не будет ожидать от setName отправку письма на почту с информированием о том, что "ваше имя поменялось").
Этого поведения можно ожидать от предметной области:
interface Renamable extends ProvidesName
{
public function rename(string $name): void;
}
class Article implements Identifiable, Renamable {}
class User implements Identifiable, Renamable, etc {}
// И вот уже в данном случае от User::rename можно ожидать чего угодно
// (что по логике приложения должно случаться при переименовывании),
// т.к. он описывает поведение, а не реализацию.Хотя подобная реализация/иерархия и именование интерфейсов тоже довольно спорна (на ходу пример прикидывал).
Так что грубо прикидывая — в тех случаях, когда для объекта может быть применён интерфейс (а скорее даже несколько поведенческих, а-ля ISP), то в тех случаях можно говорить об инкапсуляции.
При чем тут инкапсуляция? В 7.3 тип проверялся в сеттерах, в 7.4 он встроен и не смысла в сеттерах. Пример годный.
Но в PHP интерфейсы не позволяют описывать публичные поля и в языке нет свойств, так что при рефакторинге без IDE get/set проще в поддержке. Именно это может печалить (и из-за этого и не любят) наличие публичных полей в классах.
UPD. Хотя я с другой стороны есть `__get/__set` на крайний случай, а в нормальных случаях всё же стоит пользоваться IDE… Так что, возможно, да, вполне себе практичный пример.
Представляем PHP 7.4: Производительность, Возможности, Устаревший Функционал