Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 29

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

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

Ни в коем случае не хочу сказать что другие фреймворки хуже. С удовольствием бы их попробовали, но разводить зоопарк не можем себе позволить.
Всего голосов 2: ↑2 и ↓0+2
Yii2 вполне хорош, последний большой проект начали именно на нём. Много что удобно сделано, многие вещи позволяется сделать супербыстро, активно используем виджеты, коммьюнити живое и помогающее. Есть и другие фреймворки, тот же кодИгнайтер, та же Ларавель, но Йии вполне удобен и комфортен, чтобы не смотреть по сторонам, по крайней мере это справедливо внутри нашей компании)
Всего голосов 1: ↑1 и ↓0+1
> Как узнать равны ли два 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. Смысл последнего сравнения(взятого из статьи) от меня ускользает. Помогите понять, что это и зачем.
Всего голосов 1: ↑1 и ↓0+1

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

Всего голосов 1: ↑1 и ↓0+1
Ок, согласен.

$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
Всего голосов 1: ↑1 и ↓0+1
Признаюсь меня бесит PhpStorm: его необходимость писать комментарии и код так чтоб «иде понимала что я хочу написать и подсказывала мне». Я считаю что код должен быть понятен людям, а не редактору в котором я пишу.
Всего голосов 12: ↑0 и ↓12-12
Один раз я работал в команде, где большинство писало в текстовых редакторах, а не в IDE. Постоянно были PR, в которых тесты валились из-за того что забыли сделать use классу. Или вызвали $this-> там, где это нельзя. И куча подобных вещей, которые юзеры шторма просто не поймут.
Всего голосов 4: ↑4 и ↓0+4
Для проверки на такие ошибки существуют phpmd, phpcs, phplint (проверку можно привязать по сохранению файла).
И я не про это, а например про написание комментариев с указанием типов атрибутов чтоб шторм понимал это для подсказки методов, в то время как указание типизации для них уже ввели в php.
Всего голосов 1: ↑0 и ↓1-1
PhpStorm вообще-то не нуждается в подсказках в тех случаях, когда типы указаны однозначно. Но как вы, например, укажете, что вы ожидаете массив объектов с конкретным классом/интерфейсом? В PhpDoc (который, кстати, придумали не в JetBrains) это можно указать как `Type[]`.
Всего голосов 2: ↑2 и ↓0+2
он нуждается в таком
        /**
         * @var User $user
         */
        $user = Auth::user();
Всего голосов 4: ↑0 и ↓4-4
Нет, он не нуждается. По крайней мере, если сигнатура определена так:

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

Примеры:

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

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


Если это критично для вас, всегда можно выделить метод с нужной сигнатурой: 
getUserRepository(): UserRepository
Всего голосов 1: ↑1 и ↓0+1
Для своего метода. Но не для вендорских?
Всего голосов 4: ↑0 и ↓4-4

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

Всего голосов 3: ↑3 и ↓0+3
Так я и писал про вендорские, со своими всё проще.
Метод getRepository — вполне себе вендорский от doctrine.

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


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

Всем бы хотелось не писать phpDoc и получать подсказки, но откуда IDE взять тип, если он непосредственно в коде не определен?
Всего голосов 2: ↑2 и ↓0+2

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

Всего голосов 3: ↑0 и ↓3-3
И в чем искажение…

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

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

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

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

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

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


Можно еще возвращать объект — коллекцию, реализующую итератор, но без дженериков все это выглядит кривовато.
Комментарий пока не оценивали0
Ну, начнем с того, что variadic parameter может быть только один и при этом должен быть последним. При этом даже если забыть про это ограничение, при передаче уже имеющегося массива нам его нужно развернуть в параметры функции (ок, для этого можно тоже многоточие использовать), а потом его интерпретатор обратно соберет в массив. Выглядит скорее как workaround в отсутствие полноценной поддержки.
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr