Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Tue, Feb 27, 2024, at 00:11, Frederik Bosch wrote:
> Hi Rowan,
>
> On 26-02-2024 23:46, Rowan Tommins [IMSoP] wrote:
>> On 26/02/2024 20:21, Frederik Bosch wrote:
>>> I do note that $this->propName might suggest that the backing value is
>>> accessible from other locations than only the property's own get/set
>>> methods, because of $this usage.
>>
>>
>> Yes, I actually stumbled over that confusion when I was writing some of the
>> examples in my lengthy e-mail in this thread. As I understand it, this would
>> work:
>>
>> public string $foo {
>> get { $this->foo ??= 0; $this->foo++; return $this->foo; }
>> set { throw new Exception; }
>> }
>>
>> Outside the hooks, trying to write to $this->foo would throw the exception,
>> because it refers to the hooked property as a whole; but inside, the same
>> name refers to something different, which isn't accessible anywhere else.
>>
>> Now that I've looked more at how Kotlin uses "field", I understand why it
>> makes sense - it's not an alias for the property itself, but the way to
>> access a "backing store" which has no other name.
>>
>> Using $this->foo as the name is tempting if you think of hooks as happening
>> "on top of" the "real" property; but that would be a different feature, like
>> Switft's "property observers" (willSet and didSet). What's really happening
>> is that we're declaring two things at once, and giving them the same name;
>> almost as if we'd written this:
>>
>> public string $foo {
>> get { static $_foo; $_foo ??= 0; $_foo++; return $_foo; }
>> set { throw new Exception; }
>> }
>>
>> Kotlin's "field" is kind of the equivalent of that "static $_foo"
>>
>>
> And what happens in the following situation, how are multiple get calls
> working together?
>
> public string $fullName {
> get => $this->first . ' ' . $this->last; // is this accessing the backed
> value, or is it accessing via get
> set($value) => $this->fullName = $value;
> }
>
> public string $first {
> get => explode(' ', $this->fullName)[0], // is this accessing the backed
> value, or is it accessing via get
> set($value) => $value;
> }
>
> Isn't it weird that $this->propName gives different results from one get
> function, compared to the other. I would say $this->prop should always follow
> the same semantics as explained in the RFC (first __get/__set, then the
> accessor).
>
>>
>>> Regarding returning void=null, this is something that IDE and static
>>> analyzers already pick-up as an error. I think being stricter on that in
>>> this RFC would actually make sense, and treat void not as null.
>>
>> What would happen if a setter contained both "return 42;" and "return;"? The
>> latter is explicitly allowed in "void" functions, but is also allowed in a
>> non-void function as meaning "return null;"
> return 42; // returns (int)42
> return; // early return, void, same as no return
> return null; // returns null
>>
>>
>>> And why yield is magic, I do not get that. The word and the expression
>>> actually expresses that something is, well, yielded.
>>
>> But yielded to where? My mental model of "return to set" is that this:
>>
>> public string $name { set($value) { $x = something($value); return $x + 1; }
>> }
>>
>> Is effectively:
>>
>> private function _name_set($value) { $x = something($value); return $x + 1;
>> } }
>> plus:
>> $this->name = $this->_name_set($value);
>>
>> With "yield", I can't picture that simple translation; the "magic" is
>> whatever translates the "yield" keyword into "$this->name ="
> You would picture it by explaining how it works from the source side. A set
> function that contains a yield turns the set function into a directly
> consumed generator. Considering the following:
>
>
> public string $first {
> set($value) => {
> yield 'First name';
> yield 'Given name';
> return 'My name';
> }
> }
>
> the pseudo-code from the PHP source side would look as follows.
>
> $generator = setCall($class, 'first', $value);
> foreach ($generator as $value) {
>writeProperty($class, 'first', $value);
> }
> if ($generator->hasReturn()) {
> writeProperty($class, 'first', $generator->getReturn());
> }
>
The yield is much more intuitive than magic fields and $this->prop (which feels
like an infinite loop). Yield is remarkably simple.
Looking at this, I'm still not sure what would happen here, though (maybe it is
covered in the RFC, and I missed it) -- going to use yield here to try it out:
public string $name {
set => {
if(strlen($value) < 5) {
yield 'invalid';
yield $this->invalidName($value);
}
yield $value;
}
}
public function invalidName($name) {
return $this->name = str_pad($name, 5);
}
This is probably an infinite loop in this particular example, but more
importantly, do setters allow reentry while executing?
>>
>> I would file it with the type widening in the RFC: seems kind of
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Hi Rowan,
On 26-02-2024 23:46, Rowan Tommins [IMSoP] wrote:
On 26/02/2024 20:21, Frederik Bosch wrote:
I do note that $this->propName might suggest that the backing value
is accessible from other locations than only the property's own
get/set methods, because of $this usage.
Yes, I actually stumbled over that confusion when I was writing some
of the examples in my lengthy e-mail in this thread. As I understand
it, this would work:
public string $foo {
get { $this->foo ??= 0; $this->foo++; return $this->foo; }
set { throw new Exception; }
}
Outside the hooks, trying to write to $this->foo would throw the
exception, because it refers to the hooked property as a whole; but
inside, the same name refers to something different, which isn't
accessible anywhere else.
Now that I've looked more at how Kotlin uses "field", I understand why
it makes sense - it's not an alias for the property itself, but the
way to access a "backing store" which has no other name.
Using $this->foo as the name is tempting if you think of hooks as
happening "on top of" the "real" property; but that would be a
different feature, like Switft's "property observers" (willSet and
didSet). What's really happening is that we're declaring two things at
once, and giving them the same name; almost as if we'd written this:
public string $foo {
get { static $_foo; $_foo ??= 0; $_foo++; return $_foo; }
set { throw new Exception; }
}
Kotlin's "field" is kind of the equivalent of that "static $_foo"
And what happens in the following situation, how are multiple get calls
working together?
public string $fullName {
get => $this->first . ' ' . $this->last; // is this accessing the
backed value, or is it accessing via get
set($value) => $this->fullName = $value;
}
public string $first {
get => explode(' ', $this->fullName)[0], // is this accessing the
backed value, or is it accessing via get
set($value) => $value;
}
Isn't it weird that $this->propName gives different results from one get
function, compared to the other. I would say $this->prop should always
follow the same semantics as explained in the RFC (first __get/__set,
then the accessor).
Regarding returning void=null, this is something that IDE and static
analyzers already pick-up as an error. I think being stricter on that
in this RFC would actually make sense, and treat void not as null.
What would happen if a setter contained both "return 42;" and
"return;"? The latter is explicitly allowed in "void" functions, but
is also allowed in a non-void function as meaning "return null;"
return 42; // returns (int)42
return; // early return, void, same as no return
return null; // returns null
And why yield is magic, I do not get that. The word and the
expression actually expresses that something is, well, yielded.
But yielded to where? My mental model of "return to set" is that this:
public string $name { set($value) { $x = something($value); return $x
+ 1; } }
Is effectively:
private function _name_set($value) { $x = something($value); return $x
+ 1; } }
plus:
$this->name = $this->_name_set($value);
With "yield", I can't picture that simple translation; the "magic" is
whatever translates the "yield" keyword into "$this->name ="
You would picture it by explaining how it works from the source side. A
set function that contains a yield turns the set function into a
directly consumed generator. Considering the following:
public string $first {
set($value) => {
yield 'First name';
yield 'Given name';
return 'My name';
}
}
the pseudo-code from the PHP source side would look as follows.
$generator = setCall($class, 'first', $value);
foreach ($generator as $value) {
writeProperty($class, 'first', $value);
}
if ($generator->hasReturn()) {
writeProperty($class, 'first', $generator->getReturn());
}
I would file it with the type widening in the RFC: seems kind of cool,
but probably isn't worth the added complexity.
Regards,
--
Frederik Bosch
Partner
Genkgo logo
Mail: f.bo...@genkgo.nl
Web: support.genkgo.com
Entrada 123
Amsterdam
+31 20 244 1920
Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder nummer
56501153
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On 26/02/2024 20:21, Frederik Bosch wrote:
I do note that $this->propName might suggest that the backing value is
accessible from other locations than only the property's own get/set
methods, because of $this usage.
Yes, I actually stumbled over that confusion when I was writing some of
the examples in my lengthy e-mail in this thread. As I understand it,
this would work:
public string $foo {
get { $this->foo ??= 0; $this->foo++; return $this->foo; }
set { throw new Exception; }
}
Outside the hooks, trying to write to $this->foo would throw the
exception, because it refers to the hooked property as a whole; but
inside, the same name refers to something different, which isn't
accessible anywhere else.
Now that I've looked more at how Kotlin uses "field", I understand why
it makes sense - it's not an alias for the property itself, but the way
to access a "backing store" which has no other name.
Using $this->foo as the name is tempting if you think of hooks as
happening "on top of" the "real" property; but that would be a different
feature, like Switft's "property observers" (willSet and didSet). What's
really happening is that we're declaring two things at once, and giving
them the same name; almost as if we'd written this:
public string $foo {
get { static $_foo; $_foo ??= 0; $_foo++; return $_foo; }
set { throw new Exception; }
}
Kotlin's "field" is kind of the equivalent of that "static $_foo"
Regarding returning void=null, this is something that IDE and static
analyzers already pick-up as an error. I think being stricter on that
in this RFC would actually make sense, and treat void not as null.
What would happen if a setter contained both "return 42;" and "return;"?
The latter is explicitly allowed in "void" functions, but is also
allowed in a non-void function as meaning "return null;"
And why yield is magic, I do not get that. The word and the expression
actually expresses that something is, well, yielded.
But yielded to where? My mental model of "return to set" is that this:
public string $name { set($value) { $x = something($value); return $x +
1; } }
Is effectively:
private function _name_set($value) { $x = something($value); return $x +
1; } }
plus:
$this->name = $this->_name_set($value);
With "yield", I can't picture that simple translation; the "magic" is
whatever translates the "yield" keyword into "$this->name ="
I would file it with the type widening in the RFC: seems kind of cool,
but probably isn't worth the added complexity.
Regards,
--
Rowan Tommins
[IMSoP]
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Mon, Feb 26, 2024, at 7:39 PM, Rowan Tommins [IMSoP] wrote:
> On 26/02/2024 19:02, Frederik Bosch wrote:
>>
>> That's how it always has been, no? So in your example, short code
>> abbreviated form would not work. One has to write a block.
>>
>> public string$fullName {
>> set=> [$this->first, $this->last] = explode
>> (' ', \ucfirst
>> ($value)); // error, $fullName is a string,
>> returning array
>> }
>>
>> public string$fullName {
>> set{
>> [$this->first, $this->last] = explode
>> (' ', \ucfirst
>> ($value)); // no error, not returning
>> }
>> }
>
>
> I think the intention is that both the block and the arrow syntax would
> have any return value ignored, as happens with constructors, for
> example. Note that in PHP, there is actually no such thing as "a
> function not returning a value", even a "void" function actually returns
> null; so if the return value was treated as meaningful, your second
> example would give an error "cannot assign null to property of type string".
This correct. Given a function test():
$ret = test('Larry Garfield');
There's no way to tell if $ret is a possibly-null value we should do something
with, or null by side-effect. The RFC right now takes the stance of "it's null
by side effect, always, so we never do anything with the return so it's
consistent."
> However, as noted in a previous message, I agree that the short form
> meaning "the value returned is saved to the backing field" is both more
> expected and more useful.
You're the first person to comment on it, but I'm glad you agree. :-) I like
it, but Ilija is still unsure about it.
> The "yield" idea is ... interesting. I think personally I find it a bit
> too magic, and too cryptic to be more readable than an explicit
> assignment. Opinions may vary, though.
>
> Regards,
Mixing in syntax only used for generators here seems like it's asking for
trouble. It wouldn't actually be a coroutine, so using coroutine like syntax
would just be confusing. It's confusing to me whether this implies the hook
becomes a generator or not, which means it's likely to confuse a lot of other
people.
--Larry Garfield
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Hi Rowan,
Thanks for clearing up that the return value will be ignored. I
understand better why that is (void = null). I do like the updated RFC
better than the one with the $field variable to write to. My yield
suggestion was an idea derived from that earlier $field write proposal,
but I wanted to share it anyhow.
I do note that $this->propName might suggest that the backing value is
accessible from other locations than only the property's own get/set
methods, because of $this usage. I would rather have a $field in get
referring to the current value, and a $value in set referring to the
passed value. So with the full name example:
public string $fullName {
get ($field): string => $field;
set ($value): string {
[$this->first, $this->last] = explode(' ', $value);
return $value;
}
}
I think it would make absolutely clear that the backing value is only
accessible in the local get/set scope. Regarding returning void=null,
this is something that IDE and static analyzers already pick-up as an
error. I think being stricter on that in this RFC would actually make
sense, and treat void not as null. So with a slightly different full
name example:
public string $fullName {
get ($field): string => $this->first . ' ' . $this->last;
set ($value): void {
[$this->first, $this->last] = explode(' ', $value); // real
void, no value returned
}
}
And why yield is magic, I do not get that. The word and the expression
actually expresses that something is, well, yielded. yield is a word
that is reserved in the language that serves the purpose of the problem.
I would use it. It is even explainable that the set function is treated
as a generator function.
Regards,
Frederik
On 26-02-2024 20:39, Rowan Tommins [IMSoP] wrote:
On 26/02/2024 19:02, Frederik Bosch wrote:
That's how it always has been, no? So in your example, short code
abbreviated form would not work. One has to write a block.
public string$fullName { set=> [$this->first,
$this->last] = explode (' ', \ucfirst
($value)); // error, $fullName is a
string, returning array
}
public string$fullName { set{
[$this->first, $this->last] = explode
(' ', \ucfirst
($value)); // no error, not returning
}
}
I think the intention is that both the block and the arrow syntax
would have any return value ignored, as happens with constructors, for
example. Note that in PHP, there is actually no such thing as "a
function not returning a value", even a "void" function actually
returns null; so if the return value was treated as meaningful, your
second example would give an error "cannot assign null to property of
type string".
However, as noted in a previous message, I agree that the short form
meaning "the value returned is saved to the backing field" is both
more expected and more useful.
The "yield" idea is ... interesting. I think personally I find it a
bit too magic, and too cryptic to be more readable than an explicit
assignment. Opinions may vary, though.
Regards,
--
Frederik Bosch
Partner
Genkgo logo
Mail: f.bo...@genkgo.nl
Web: support.genkgo.com
Entrada 123
Amsterdam
+31 20 244 1920
Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder nummer
56501153
Re: [PHP-DEV] is this thing on?
Hi On 2/26/24 14:25, Daniil Gentili wrote: And no, I don't like discussion forums like reddit or Discord either. Discord should be completely out of question, given that it is Agreed. non-indexable by search engines (btw, technically this mailing list isn't indexable either without projects like externals.io). This is false. There is an official web-accessible archive of the list: https://news-web.php.net/php.internals Best regards Tim Düsterhus
Re: [PHP-DEV] is this thing on?
Hi On 2/26/24 10:56, Daniil Gentili wrote: even ignoring all the deliverability issues, I don't think using a mailing list is a good idea for a modern programming language, seeking And neither is GitHub Discussions. When I have the choice between GitHub Discussions and a mailing list, I'd take a mailing list all day, every day. See also this previous email of mine: https://news-web.php.net/php.internals/120010 exclusively github issues and pull request discussions, I believe that the mailing list is nothing more than a redundant relic of the past. Mailing lists are fine and PHP is not the only project using them. The Linux kernel successfully uses them, the HAProxy project does as well and so does Debian. Best regards Tim Düsterhus
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On 26/02/2024 19:02, Frederik Bosch wrote:
That's how it always has been, no? So in your example, short code
abbreviated form would not work. One has to write a block.
public string$fullName {
set=> [$this->first, $this->last] = explode (' ', \ucfirst ($value)); // error, $fullName is a string, returning array
}
public string$fullName {
set{
[$this->first, $this->last] = explode ('
', \ucfirst ($value)); // no error, not returning
}
}
I think the intention is that both the block and the arrow syntax would
have any return value ignored, as happens with constructors, for
example. Note that in PHP, there is actually no such thing as "a
function not returning a value", even a "void" function actually returns
null; so if the return value was treated as meaningful, your second
example would give an error "cannot assign null to property of type string".
However, as noted in a previous message, I agree that the short form
meaning "the value returned is saved to the backing field" is both more
expected and more useful.
The "yield" idea is ... interesting. I think personally I find it a bit
too magic, and too cryptic to be more readable than an explicit
assignment. Opinions may vary, though.
Regards,
--
Rowan Tommins
[IMSoP]
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On 23-02-2024 16:58, Larry Garfield wrote:
On Fri, Feb 23, 2024, at 8:33 AM, Stephen Reay wrote:
On 23 Feb 2024, at 06:56, Larry Garfield wrote:
Hi Larry,
It's good to see this idea still progressing.
I have to agree with the other comment(s) that the implicit
`$field`/`$value` variables seem odd to me. I understand the desire for
brevity and the potential future scope of reused hooks, but this
concept seems to fly in the face of many years of PHP reducing "magic"
like this.
The "magic" that PHP has been removing is mostly weird and illogical type casting. As
noted, neither of these variables are any more "magic" than $this.
However, since it seems no one likes $field, we have removed it from the RFC. Of
note, to respond to your comment further down, $this->{__PROPERTY__} will not
work. The virtual-property detection looks for the AST representation of
$this->propName, and only that. Dynamic versions that turn into that at runtime
cannot work, as it needs to be known at compile time.
For $value, however, we feel strongly that having the default there is a
necessary part of the ergonomic picture. In particular, given your comments
here:
To give one answer to your question about ambiguity if the `$value`
parameter is required - I don't believe this is actually ambiguous, in
the context of PHP:
- method parameters in child classes don't implicitly 'inherit' the
parent method parameter's type if they don't define one (they widen to
mixed);
- method return types have no implicit inheritance, they must declare a
compatible return type;
- typed class properties don't implicitly inherit the parent type when
the type left off a child property - they must declare the same type.
AFAIK there is no existing behaviour in PHP where omitting a type would
mean "the type is implicitly inherited from X", it either means the
same as mixed, or it's an error.
That to me suggests that IF a custom variable name is provided, we should
require also specifying the type. In which case, in the 95% case, if we
require the full argument signature then the 95% case would need to
double-specify the type, which is a hard-no from an ergonomic standpoint.
Especially combined with the suggestion yesterday to allow return-to-set in the
short-set version, that would mean comparing this:
public string $phone {
set(string $phone) => $this->phone = $this->sanitizePhone($phone);
}
To this:
public string $phone {
set => $this->sanitizePhone($value);
}
And to me, there's absolutely no contest. The latter has about 1/3 as many
places for me to make a typo repeating the same information over again. Now
imagine comparing the above in a property that's used with constructor
promotion.
public function __construct(
public string $phone { set(string $phone) => $this->phone =
$this->sanitizePhone($phone); }
public string $phone { set => $this->sanitizePhone($value); }
) {}
Again, it's absolutely no contest for me. I would detest writing the longer
version every time.
If PHP has been moving away from weird and inexplicable magic, it's also been
moving away from needless boilerplate. (Constructor promotion being the best
example, but not the only; types themselves are a factor here, as are arrow
functions.) As the whole point of this RFC is to make writing common code
easier, requiring redundant boilerplate for it to work is actively
counter-productive.
So what I'd suggest instead is "specify the full signature if you want a custom name OR wider
type; or omit the param list entirely to get a same-type $value variable, which 99% of the time is
all you need." We get that in return for documenting "$value is the default", which
for someone who has already figured out $this, should be a very low effort to learn.
Also, a small nitpick: The link to your attributeutils repo in the
examples page, is broken, and it would be nice to see a few examples
showing the explicit version of the hooks.
Link fixed, thanks. What do you mean explicit version of the hooks?
--Larry Garfield
Hi Larry,
Great to see you pick up on this proposal again. Rather than "just use
$this->propName directly", you might want to consider yield to commit
the property value, as a solution to "to assign and confirm the property
write while still allowing code to run after it". But then return would
be also be a logical consequence.
public string$propName {
set($value) {
yield $value;
$this->doSomething();
yield $value;
return $this->doSomethingElse(); // final commit, not required
}
}
If I read your remarks on why not using return I do not get why this
proposal wants to deviate from a normal function syntax.
function test(string $name) {
return [$first, $last] = explode(' ', $name);
}
var_dump(test("Larry Garfield")); // returns ["Larry", "Garfield"]
That's how it always has been, no? So in your example, short code
Re: [PHP-DEV] is this thing on?
On Mon, Feb 26, 2024, at 19:01, Rowan Tommins wrote: > On 26/02/2024 16:14, Rob Landers wrote: > > There wasn’t any mention about issues FROM Gmail TO the list. I sent > > this email because it didn’t seem like ANYONE was aware of the issue > > (otherwise someone would have mentioned it, so people would stop > > hammering the server trying to send emails that couldn’t be sent). > > Even emailing people like Derrick directly was failing to be sent. > > > Absolutely, it wasn't my intention to criticise you for asking, just to > reassure you that it is a known issue - I only know myself because I > reached out on a different forum, and was reassured in my turn. > > The mention of the other problems was just in case you hadn't spotted > that thread. Oh no worries! I’m just glad people know that they know. > > Hopefully all will be resolved soon, and we can get back to our > regularly scheduled bikeshedding ;) Looking forward to it! I have a very long question I sent to the list a few minutes after it broke, mostly about a bug with traits that has been fixed and broken at least once and I’m not sure if it is intentionally broken. I can open a PR to fix it, but if it’s intentionally broken and needs an RFC to fix, it probably won’t happen (at least by me). > Regards, > > -- > Rowan Tommins > [IMSoP] > > — Rob
Re: [PHP-DEV] is this thing on?
On Monday, 26 February 2024 at 11:53, Daniil Gentili wrote: > > IMO sending an email is not a gigantic barrier to entry, as can be seen by > the often low (technical and overall) quality of the replies to many of the > threads on this list. Yet people complain about it being a barrier to entry, and a barrier to contributing to the project. > I really don't think that a modern discussion system can afford to randomly > loose messages: mailing lists should not be used in 2024. This is a take and a half, a lot of self-hosted modern discussion system still require an email server and list. Moreover, internals is far from the only mailing list that contributors/core devs rely on. > Large projects like PHP will still inevitably attract attention, regardless > of whether github or mailing lists are used; I personally dislike mailing > lists not because they are difficult to use, but because they are simply > broken: every time I had to deal with any mailing list, including this one, I > had both incoming and outgoing deliverability issues related either to > DKIM/DMARC, or some other issue caused by modern anti-spam measures that > mailing lists do not account for. I'm sorry this has been your experience, but I never really had any issues with mailing lists, and they have always just worked TM Part of the issue is that we were forced to migrate the mailing list on short notice. And I do agree that certain things the list does about DKIM/DMARC is less than optimal. However, demanding to change the workflow of core developers for _your_ convenience is, not a good way of moving change forward. I find it akin to being a new hire at a large, established company and storming into a meeting of the board of directors within your first week of working to demand change because the way it is currently being operated is "shit". I can let you imagine the fallout of such an action if attempted in real life. Yes, the list is far from ideal, but it is an established process that has somewhat worked and people have integrated this into their workflow. Are there better options? Sure. But shouting "just use GitHub discussion", or whatever $myPreferedPlatformOrMethod is not conducive to change. For us to move away from the internals list you *must* have core developer endorsement for the new solution. And, with people I have talked to, me included, find GitHub discussions to be ill-suited. It probably works perfectly for a library, tooling, or projects built with PHP and I'm happy for projects where it is a good fit. What is the purpose of the list, and internals? I'm not exactly sure, as it seems to have morphed and shifted over the course of its existence. Is the objective is to have core developers interact on it willingly by having technical discussion which might go over most people head? Is the objective just for people to be able spit ball ideas as an initial stage on a wide-reaching platform with minimal interaction from core developers? Is the objective to just propose, announce, and discuss RFCs and vote on them? etc. Probably each of these objectives require different solutions, and this would probably be a more useful conversation to have. Best regards, Gina P. Banyard
Re: [PHP-DEV] is this thing on?
On Mon, Feb 26, 2024, at 12:03, Rowan Tommins [IMSoP] wrote: > On Sun, 25 Feb 2024, at 20:02, Rob Landers wrote: > > Before I get to the meat of this email, first of all, IMHO, anyone should > > be able to email the list, even if they are not a > > member of the list. I've had to email ubuntu lists about bugs before and I > > really have no desire to join those lists, but > > I was always able to just send the email to the list just fine. > > The biggest problem with an open list is how to manage spam - if you don't > catch the spam on the list server, it not only ends up in hundreds of > inboxes, but in multiple archives and mirrors of the list. I don't know how > the lists you mentioned handle that. https://lists.ubuntu.com/mailman/listinfo/Ubuntu-devel-discuss You can send an email and ask :) no subscription required. > > This has also come up in the past regarding moving from e-mail to > $currently_fashionable_technology - having some barrier to entry is actually > quite useful, since we want people to put some effort into their > contributions beyond "me too" or "I had this crazy idea in the pub". > > Note that this is exactly why bugs.php.net was abandoned: there was too much > spam and low-quality content. > > > > Now for the issue: > > > > gmail is failing to send emails to the list (hence why it has probably been > > a bit quite around here). Here is the error: > > > > The response from the remote server was: > > 451 4.3.0 : Temporary lookup failure > > People are aware of this issue, and looking into it. In case you missed the > previous thread, two things have unfortunately happened at once: > > - The mailing list was moved to a new server > - GMail rolled out a much tighter set of anti-spam rules > > It's not immediately clear which of these is responsible for the 451 errors, > but as I say, people are working on it. There wasn’t any mention about issues FROM Gmail TO the list. I sent this email because it didn’t seem like ANYONE was aware of the issue (otherwise someone would have mentioned it, so people would stop hammering the server trying to send emails that couldn’t be sent). Even emailing people like Derrick directly was failing to be sent. > > > Now, to go figure out how to unsubscribe this email from the list... > > Exactly the same way you subscribed, I believe: via the web form, or using > +unsubscribe in the to address. > > Regards, > -- > Rowan Tommins > [IMSoP] > P.S. I have no idea if this email is sent via html or plain text or how to switch it. I apologize for the shenanigans if this is html. — Rob
Re: [PHP-DEV] is this thing on?
Am 26.02.2024 um 14:25 schrieb Daniil Gentili : > I really don't think that a modern discussion system can afford to randomly > loose messages: mailing lists should not be used in 2024. Just because Gmail decided to tighten the rules about SPF/DKIM just now does not mean email is broken or loses messages on a regular basis. Repeating it does not make it true, let's agree to disagree. Regards, - Chris
Re: [PHP-DEV] is this thing on?
And no, I don't like discussion forums like reddit or Discord either. Discord should be completely out of question, given that it is non-indexable by search engines (btw, technically this mailing list isn't indexable either without projects like externals.io). Writing to the amount of people following php internals should be done with some consideration and more social media type of platforms unfortunately - in my experience - tend to encourage noise. As I mentioned in my other reply in this thread, IMO sending an email is not a gigantic barrier to entry, as can be seen by the often low (technical and overall) quality of the replies to many of the threads on this list. Personally, I do not think that gatekeeping (!) and spam-prevention are a good reason to keep using a broken and outdated system like mailing lists in 2024. Large projects like PHP will still inevitably attract attention, regardless of whether github or mailing lists are used; I personally dislike mailing lists not because they are difficult to use, but because they are simply broken: every time I had to deal with any mailing list, including this one, I had both incoming and outgoing deliverability issues related either to DKIM/DMARC, both on gmaill and zoho mail on a custom domain, or some other issue caused by modern anti-spam measures that mailing lists do not account for. I really don't think that a modern discussion system can afford to randomly loose messages: mailing lists should not be used in 2024. Regards, Daniil Gentili.
Re: [PHP-DEV] is this thing on?
Am 26.02.2024 um 10:56 schrieb Daniil Gentili : >> gmail is failing to send emails to the list (hence why it has probably been >> a bit quite around here). Here is the error: > +1, personally I would just switch to github issues and discussions, even > ignoring all the deliverability issues, I don't think using a mailing list is > a good idea for a modern programming language, seeking new contributors and > new ideas in 2024. > VCS was already moved to github after the recent hack of the php VCS, a lot > of technical internals-related discussion is already using exclusively github > issues and pull request discussions, I believe that the mailing list is > nothing more than a redundant relic of the past. I very much disagree as I still prefer email to having discussions in issues or PRs. It is still the sweet spot for me with easy of use and feature support from a modern email client. Issues and PRs are IMHO suited for bugs, feature requests and other code changes, not for discussions. And no, I don't like discussion forums like reddit or Discord either. Writing to the amount of people following php internals should be done with some consideration and more social media type of platforms unfortunately - in my experience - tend to encourage noise. Just my $.02, - Chris
Re: [PHP-DEV] is this thing on?
This has also come up in the past regarding moving from e-mail to $currently_fashionable_technology - having some barrier to entry is actually quite useful, since we want people to put some effort into their contributions beyond "me too" or "I had this crazy idea in the pub". IMO sending an email is not a gigantic barrier to entry, as can be seen by the often low (technical and overall) quality of the replies to many of the threads on this list. Personally, I do not think that gatekeeping (!) and spam-prevention are a good reason to keep using a broken and outdated system like mailing lists in 2024. Large projects like PHP will still inevitably attract attention, regardless of whether github or mailing lists are used; I personally dislike mailing lists not because they are difficult to use, but because they are simply broken: every time I had to deal with any mailing list, including this one, I had both incoming and outgoing deliverability issues related either to DKIM/DMARC, or some other issue caused by modern anti-spam measures that mailing lists do not account for. I really don't think that a modern discussion system can afford to randomly loose messages: mailing lists should not be used in 2024. Regards, Daniil Gentili.
Re: [PHP-DEV] is this thing on?
On 26 February 2024 11:03:05 GMT, "Rowan Tommins [IMSoP]" wrote: >On Sun, 25 Feb 2024, at 20:02, Rob Landers wrote: >> Before I get to the meat of this email, first of all, IMHO, anyone should be >> able to email the list, even if they are not a >> member of the list. I've had to email ubuntu lists about bugs before and I >> really have no desire to join those lists, but >> I was always able to just send the email to the list just fine. That's not true. There was a complex pre-auth system in use that you had to do once (the "confirmed list"). >The biggest problem with an open list is how to manage spam Exactly. See the results of that on the php-announce list which was open for a few hours. We can't make this an open list. >Exactly the same way you subscribed, I believe: via the web form, or using >+unsubscribe in the to address. Correct. cheers Derick
Re: [PHP-DEV] is this thing on?
On Sun, 25 Feb 2024, at 20:02, Rob Landers wrote: > Before I get to the meat of this email, first of all, IMHO, anyone should be > able to email the list, even if they are not a > member of the list. I've had to email ubuntu lists about bugs before and I > really have no desire to join those lists, but > I was always able to just send the email to the list just fine. The biggest problem with an open list is how to manage spam - if you don't catch the spam on the list server, it not only ends up in hundreds of inboxes, but in multiple archives and mirrors of the list. I don't know how the lists you mentioned handle that. This has also come up in the past regarding moving from e-mail to $currently_fashionable_technology - having some barrier to entry is actually quite useful, since we want people to put some effort into their contributions beyond "me too" or "I had this crazy idea in the pub". Note that this is exactly why bugs.php.net was abandoned: there was too much spam and low-quality content. > Now for the issue: > > gmail is failing to send emails to the list (hence why it has probably been a > bit quite around here). Here is the error: > > The response from the remote server was: > 451 4.3.0 : Temporary lookup failure People are aware of this issue, and looking into it. In case you missed the previous thread, two things have unfortunately happened at once: - The mailing list was moved to a new server - GMail rolled out a much tighter set of anti-spam rules It's not immediately clear which of these is responsible for the 451 errors, but as I say, people are working on it. > Now, to go figure out how to unsubscribe this email from the list... Exactly the same way you subscribed, I believe: via the web form, or using +unsubscribe in the to address. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] is this thing on?
gmail is failing to send emails to the list (hence why it has probably been a bit quite around here). Here is the error: +1, personally I would just switch to github issues and discussions, even ignoring all the deliverability issues, I don't think using a mailing list is a good idea for a modern programming language, seeking new contributors and new ideas in 2024. VCS was already moved to github after the recent hack of the php VCS, a lot of technical internals-related discussion is already using exclusively github issues and pull request discussions, I believe that the mailing list is nothing more than a redundant relic of the past. Regards, Daniil Gentili
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Thu, 22 Feb 2024, at 23:56, Larry Garfield wrote:
> However, I just had a long discussion with Ilija and there is one
> possibility we could consider: Use the return value only on the
> shorthand (arrow-function-like) syntax.
>
> So you could do either of these, which would be equivalent:
>
> set {
> $this->phone = $this->santizePhone($value);
> }
>
> set => $this->santizePhone($value);
Regarding this point, I've realised that the current short-hand set syntax
isn't actually any shorter:
set { $this->phone = $this->santizePhone($value); }
set => $this->phone = $this->santizePhone($value);
It also feels weird to say both "the right-hand side must be a valid
expression" and "the value of the expression is ignored".
So I think making the short-hand be "expression to assign to the implicit
backing field" makes a lot more sense.
Regards,
--
Rowan Tommins
[IMSoP]
