Comments 22
Ну что за дичь опять?
public:private int $id;
public:protected string $name;
public private(set) int $id;
public protected(set) string $name;
+5
Что-то похожее есть в C#, но у него куда более элегантный вид:
private string birthday;
public string Name { get; set; }
public string SecondName { get; }
public string Birthday {
get;
set {
birthday = String.Trim(value);
}
}
Как по мне — изменения в целом стоящее, но не в этом вот виде, который предлагается.
0
Такой вариант как раз предлагался https://wiki.php.net/rfc/propertygetsetsyntax-v1.2, но не прошел голосование на тот момент.
0
В питоне так
или декоратором
«private public» это что-то за гранью.
class C:
def __init__(self):
self._x = None
def getx(self):
return self._x
def setx(self, value):
self._x = value
def delx(self):
del self._x
x = property(getx, setx, delx, "I'm the 'x' property.")
или декоратором
class C:
def __init__(self):
self._x = None
@property
def x(self):
"""I'm the 'x' property."""
return self._x
@x.setter
def x(self, value):
self._x = value
@x.deleter
def x(self):
del self._x
«private public» это что-то за гранью.
+1
Странно сравнивать с пайтоном, учитывая то, что в нем все свойства/методы публичные
+1
Так и в php щас можно
/** @property string x */
class С
{
public function __get($name)
{
return $name;
}
public function __set($name, $value)
{
$this->x = $value;
}
public function __unset($name)
{
unset($this->x);
}
}
0
А как в шарпе сделать протектед на чтение и приват на запись?
+1
Тоже подгорает от такого. Сначала атрибуты абы как сделали, но ладно, на практике еще не использовали, но это за гранью уже. Чем им readonly properties не угодили? Тоже самое ж, читать читай, писать нельзя.
0
Ридонли возможно будут в виде атрибута https://wiki.php.net/rfc/readonly_and_immutable_properties (ранний черновик)
0
Жаль что ссылаются на шарп, а делают через атрибуты.
почему не сделать так же?!
Чтобы в конечном итоге иметь возможность работать в таком виде:
И с классами так же
почему не сделать так же?!
<?php
class Person
{
public readonly string $name;
}
Чтобы в конечном итоге иметь возможность работать в таком виде:
<?php
class Person
{
public function __construct(
public readonly string $name,
) {}
}
И с классами так же
<?php
readonly class Person
{
//
}
+3
А мне самая идея показалось толковой. Не придется делать какие-то левые свойства вроде $_id или геттеры/сеттеры, если ты хочешь менять свойство только внутри класса, но при этом сделать его public на чтение. В типичной entity таких полей будет большинство.
+1
Я за то, чтобы добавить гет/сет, это удобно, но синтаксис в таком виде — это ИМХО адъ.
+1
И во-вторых, разрешить пробельные символы в конце числовых строк, то есть чтоб «123 » == " 123" было true и все прочие операции работали, как и для строк с начальными пробелами.
Мне кажется это будет скорее вредное поведение, чем полезное. Лучше приучать разработчиков делать trim явно, где это требуется.
+2
Согласен. Скрытое поведение при работе с данными обожгло уже кучу народа, казалось бы, magic_quotes должны были кого-то чему-то научить. А вот это:
… вполне может скрыто и очень плохо переломать чертову кучу вычислительного кода (включая финансы). Если уж делать такие изменения, то бросать E_ERROR, чтобы не было возможности втихую продолжить исполнение с неожиданным результатом операции. Само собой, это тоже слом совместимости, но хотя бы открытый.
Например в таком случае echo '2str' + 2; результат будет не 4, а 2 и вместо E_NOTICE “A non well formed numeric value encountered” будет брошен E_WARNING “A non-numeric value encountered”.
… вполне может скрыто и очень плохо переломать чертову кучу вычислительного кода (включая финансы). Если уж делать такие изменения, то бросать E_ERROR, чтобы не было возможности втихую продолжить исполнение с неожиданным результатом операции. Само собой, это тоже слом совместимости, но хотя бы открытый.
+3
Спасибо за подборку
+3
Синтаксис новых фич удручает.
Прям представляю как будет кипеть мозг когда массово начнут это использовать.
В том же Kotlin, C# всё на порядок очевидней, удобней и в целом не напрягает глаза.
Прям представляю как будет кипеть мозг когда массово начнут это использовать.
В том же Kotlin, C# всё на порядок очевидней, удобней и в целом не напрягает глаза.
0
match
напоминает оператор из Rust, было бы очень удобно иметь подобную реализацию в PHP 0
Sign up to leave a comment.
PHP-Дайджест № 183 (22 июня – 5 июля 2020)