Comments 29

Спасибо за очередной дайджест, вы делаете большую работу для всего PHP комьюнити!
В особенности, благодарю за ссылочки на плейлисты с Laravel EU 2019 и PHP.Barcelona 2019, пробежался глазами по названиям докладов — однозначно в закладки.

а чем таки он плох? тем более готовится 3 версия. Знаю вот одну контору, которая собралась переезжать именно на Yii со своего велосипеда.
Еще как пишут! Если речь о Yii2, конечно… Мы его используем с большим числом доработок, правда, с которыми он не чуть не хуже других фреймворков становится)
Мы пишем новые проекты исключительно на Yii.
Выбор обусловлен тем что у нас все проекты написаны на этой платформе и в России Yii пользуется большей популярностью. Легче найти и обучить разработчика.
Отличная документация на русском и активное адекватное комьюнити.

Ни в коем случае не хочу сказать что другие фреймворки хуже. С удовольствием бы их попробовали, но разводить зоопарк не можем себе позволить.
Yii2 вполне хорош, последний большой проект начали именно на нём. Много что удобно сделано, многие вещи позволяется сделать супербыстро, активно используем виджеты, коммьюнити живое и помогающее. Есть и другие фреймворки, тот же кодИгнайтер, та же Ларавель, но Йии вполне удобен и комфортен, чтобы не смотреть по сторонам, по крайней мере это справедливо внутри нашей компании)
> Как узнать равны ли два float в PHP
Заинтересовала статья на предмет корректности.

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

<?php
$a = 1e99;
$b = $a + 6.07e82;
$c = $a + 6.08e82;
var_dump($a == $b); // true
var_dump($a == $c); // false
var_dump(\abs($a - $b)); // 0
var_dump(\abs($a - $c)); // float(1.2141680576411E+83)
var_dump(PHP_FLOAT_EPSILON);
// float(1.2141680576411E+83)<float(2.2204460492503E-16) ?
var_dump(\abs($a - $c) < PHP_FLOAT_EPSILON); // false



Как видим, ненулевая дельта далека от PHP_FLOAT_EPSILON. Смысл последнего сравнения(взятого из статьи) от меня ускользает. Помогите понять, что это и зачем.

Нужно получить эти числа не путем ввода, а путем разнорообразных математических операций.

Ок, согласен.

$a = 1e99;
$b = 2e99;
$c = 3e99;
$ab = $a + $b;
var_dump($ab == $c); // false
var_dump(\abs($ab - $c) < PHP_FLOAT_EPSILON); // false


Оно и понятно, казалось бы.

На мой взгляд, необходимо привести порядок epsilon в соотвествие с порядком сравниваемых значений, например так:

  var_dump(\abs($ab - $c) < PHP_FLOAT_EPSILON * \min($ab, $c)); // true
Признаюсь меня бесит PhpStorm: его необходимость писать комментарии и код так чтоб «иде понимала что я хочу написать и подсказывала мне». Я считаю что код должен быть понятен людям, а не редактору в котором я пишу.
Один раз я работал в команде, где большинство писало в текстовых редакторах, а не в IDE. Постоянно были PR, в которых тесты валились из-за того что забыли сделать use классу. Или вызвали $this-> там, где это нельзя. И куча подобных вещей, которые юзеры шторма просто не поймут.
Для проверки на такие ошибки существуют phpmd, phpcs, phplint (проверку можно привязать по сохранению файла).
И я не про это, а например про написание комментариев с указанием типов атрибутов чтоб шторм понимал это для подсказки методов, в то время как указание типизации для них уже ввели в php.
PhpStorm вообще-то не нуждается в подсказках в тех случаях, когда типы указаны однозначно. Но как вы, например, укажете, что вы ожидаете массив объектов с конкретным классом/интерфейсом? В PhpDoc (который, кстати, придумали не в JetBrains) это можно указать как `Type[]`.
Нет, он не нуждается. По крайней мере, если сигнатура определена так:

public static function user(): User
{
    // ... body ...
}
В таком он действительно иногда нуждается, но только если тип вывести в общем случае невозможно.

Примеры:

 /** @var UserRepository $userRepo */
 $userRepo = $this->em->getRepository(User::class);

Или
 /** @var User $user */
 $user = $meta->newInstance();


Если это критично для вас, всегда можно выделить метод с нужной сигнатурой:
getUserRepository(): UserRepository

Скажите, а какой редактор/IDE может выдавать адекватные подсказки для autocomplete на метод, у которого не указан возвращаемый тип и отсутствует phpdoc?

Так я и писал про вендорские, со своими всё проще.
Метод getRepository — вполне себе вендорский от doctrine.

Использование своего адаптера для такого метода избавит Вас от необходимости помогать IDE с помощью phpdoc:
public function getUserRepository(): UserRepository
{
    return $this->em->getRepository(User::class);
}


Таким методом Вы перекладываете ответственность за то, что будет возвращён объект нужного класса на себя.
Это другая вариация решения той же задачи: код для того чтоб «иде понимала что я пишу».
А ваша претензия то в чем?
«меня бесит PhpStorm: его необходимость писать комментарии»
IDE как бы вас не обязывает phpDoc писать, наоборот, IDE научилась понимать phpDoc, чтоб иметь больше возможностей давать подсказки.

Всем бы хотелось не писать phpDoc и получать подсказки, но откуда IDE взять тип, если он непосредственно в коде не определен?

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

И в чем искажение…

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

Если этого мало то еще (что часто замечаю за пользователями пхпшторма) комментарии дублирующие уже указанные типы атрибутов метода либо его ответа.

IDE это не требует. Ни этого, ни вообще хоть каких то комментариев. Избыточность целиком на совести программиста.

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

да я могу не пользоваться этим, но идея приложения как раз в том чтоб пользовались(по этому претензии именно к пхпшторм) и это вырабатывает некий паттерн поведения: написания(излишнего на мой взгляд) кода который меня и бесит
А вы вообще пользуетесь PhpStorm'ом сам? Просто ваши речи наводят на мысль, что вы PhpStorm'ом не пользуетесь, но вас бесит, что те, кто пользуются, делают не нужные (с вашей точки зрения) комментарии. Я прав?
почти правы, но уже скоро месяц использую его на работе паралельно с другим редактором
Ок, я не собираюсь вас переубеждать, но мне уже просто любопытно, как вы видите решение проблемы на стороне IDE, что бы это вас не бесило?

Спрашиваю потому что если уже и бросать камень, то не понятно, почему в IDE, а не в огород к PHP. Ведь Type Hinting появился относительно недавно, типизированные свойства завезли в язык буквально на днях, Union Types только ожидаются в PHP8, описание массива типов (аналог Type[]) на уровне языка вроде пока не предлагается, плюс язык позволяет всякую магию. Всё это и породило потребность в phpdoc.
Примерно так:
function sendTypedArray(Typed ... $array): void
{
  // ...
}


Можно еще возвращать объект — коллекцию, реализующую итератор, но без дженериков все это выглядит кривовато.
Ну, начнем с того, что variadic parameter может быть только один и при этом должен быть последним. При этом даже если забыть про это ограничение, при передаче уже имеющегося массива нам его нужно развернуть в параметры функции (ок, для этого можно тоже многоточие использовать), а потом его интерпретатор обратно соберет в массив. Выглядит скорее как workaround в отсутствие полноценной поддержки.
Only those users with full accounts are able to leave comments. Log in, please.