Pull to refresh
1
Send message

Что-то похожее есть в C#, но у него куда более элегантный вид:


private string birthday;

public string Name { get; set; }
public string SecondName { get; }
public string Birthday { 
    get; 
    set {
        birthday = String.Trim(value);
    }
}

Как по мне — изменения в целом стоящее, но не в этом вот виде, который предлагается.

try-blocks на уровне функций — весьма не плохое предложение — чем меньше кода — тем лучше.

Еще бы что-то типа try с ресурсами из Java/C# и вообще была бы сказка :)
Ровно такая же ситуация, как Вы описали. Смотришь и диву даешься. Все пишут в шторме, у всех под рукой автоформатирование, которое можно легко настроить даже из predefined списка (psr1/psr2 как минимум). Так нет же, нужно писать так, как будто пробелы сами по себе в рандомное время появляются.

Деморализует ужасно — реально доходит до того, что я когда сажусь разбираться в таком куске кода — сразу накатывает уныние и желание пойти сменить место работы.
Тем не менее, к сожалению, я вынужден ней пользоватся.

К сожалению, мы все вынуждены ей пользоваться. Но Вы ведь понимаете, что union types не сделает SPL лучше?
Как говорили выше — куда лучше выбрасывать ошибку в непонятной ситуации, а не false.
Ну и как бы там ни было — ни того ни другого скорее всего в SPL не будет, твит на тему.

PHPDoc комменты нужны также для автокомплита в IDE, например где то в теле метода я получил обьект, но у метода не было return-type и IDE не знает что это, ну я и пишу

Опять таки, ну и чем Вам здесь поможет union types?

Как бы то ни было, я просто хочу подрезюмировать свое отношение к данному предложению — строго отрицательное. И вот почему: жизнь это не упростит аж никак (ну хочется прогеру поговнокодить, вернуть несколько различных типов — никто же не заставляет писать m():types), а вот потенциальных неприятных вещей добавит уж точно.
Бывают ситуации, когда нужно вернуть/передать какой-то тип вместе с другим

Возможно Вы имеете в виду «вернуть несколько аргументов из метода» — так для этого Union Types не нужен — с этим вполне справляется и массив (как минимум):
return [$val1, $val2];

В C# для этого завезли кортежи, в Java можно часто встретить что-то типа:
class Pair<T, U> { ... }

Что к слову тоже не является примером отличного кода — ведь как так? Вы не знаете какой тип Вы должны вернуть и прибегаете к обобщенному коду?
(например, ?string)

Ну так это влияние других ЯП e.g., Java/C#, что к слову не самое топовое решение, почитайте про null pointer hell.
Еще, к примеру, много встроенных функций языка возвращают комбинированные типы.

А вот это вообще отдельная песня. SPL уж точно не является примером для подражания. Нашумевшая, хоть уже и несколько устаревшая статья «PHP — fractal of bad design» является отличной иллюстрацией моих слов.
Насколько будет проще, когда не нужно будет писать PHPDoc комменты с пояснением, что за тип будет у переменной.

Я возможно скажу что-то новое для Вас, но PHPDoc комменты нужны скорее для того, чтобы понять зачем «интерфейсу» метода нужны те или иные параметры. Типы PHPDoc'a уже не так нужны, если Вы не работаете со старым legacy кодом конечно.
Некачественный код получается не тогда, когда в языке есть возможность, а тогда, когда эти возможности используют бездумно. И сейчас язык вполне себе помогает писать некачественный код, даже без Union Types.

Согласен, вот только сама возможность использовать Union Types не будет помагать с решением этой проблемы ничем — только усугублять.

Information

Rating
Does not participate
Registered
Activity