Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

[Larry Garfield]

On Wed, Feb 21, 2024, at 11:02 PM, Matthew Weier O'Phinney wrote:
> On Wed, Feb 21, 2024 at 12:57 PM Larry Garfield  
> wrote:
>> After much on-again/off-again work, Ilija and I are back with a more 
>> polished property access hooks/interface properties RFC.  It’s 99% unchanged 
>> from last summer; the PR is now essentially complete and more robust, and we 
>> were able to squish the last remaining edge cases.
>> 
>> Baring any major changes, we plan to bring this to a vote in mid-March.
>> 
>> https://wiki.php.net/rfc/property-hooks
>> 
>> It’s long, but that’s because we’re handling every edge case we could think 
>> of.  Properties involve dealing with both references and inheritance, both 
>> of which have complex implications.  We believe we’ve identified the most 
>> logical handling for all cases, though.
>
> Once again in reading the proposal, the first thing I'm struck by are 
> the magic "$field" and "$value" variables inside accessors. The first 
> time they are used, they're used without explanation, and they're 
> jarring.
>
> Additionally, once you start defining the behavior of accessors... you 
> don't start with the basics, but instead jump into some of the more 
> esoteric usage, which does nothing to help with the questions I have.
>
> So, first:
>
> - Start with the most basic, most expected usage for each of reading 
> and writing properties.
> - I need a better argument for why the $field and $value variables 
> exist. Saying they're macros doesn't help those not deep into 
> internals. As a user, why do they exist?

For $field, it's not a requirement.  It's mostly for copy-paste convenience.  A 
number of people have struggled on this point so if the consensus is to leave 
out $field and just use $this->propName directly, we can accept that.  They can 
be re-added if reusable hook packages are added in the future (as noted in 
Future Scope).

For $value, it's to avoid boilerplate.  For the majority case, you'll be just 
operating on an individual value trivially.  Checking it's range, or 
uppercasing it, or whatever.  Requiring the developer to provide a name 
explicitly is just extra work; it's much the same as how PHP doesn't require 
you to pass $this as the first argument to a method explicitly, the way Python 
and Rust do.  It's just understood that $this exists, and once you learn that 
it's obvious.

On the occasions where you do want to specify an alternate name for some 
reason, or more likely you're providing a wider type, you can.  But in the 
typical case it would just be one more thing for the dev to have to type out.  
This is especially true in what I expect to be a common case, which is promoted 
constructor arguments with an extra validator set hook on them.

It also introduces some ambiguity.  If I specify only the name, does that mean 
I'm widening the type to mixed?  Or just that I'm omitting the name?  If 
specifying the name is rare, that's not really a big deal.  If it's required in 
every case, it's a confusion point  in every case.

In the interest of transparency. for comparison:

* Kotlin appears to require an argument name, but by convention recommends 
using "value".
* Swift makes it optional, with a default name of "newValue".  (Same logic as 
in the RFC.)
* C# ... as far as I can tell, doesn't support a custom name at all; it's 
always called "value", implicitly.

> Second: you don't have examples of defining BOTH get and set OTHER than 
> when using expressions for both accessors or a mix. I'm actually 
> unclear what the syntax is when both are defined. Is there supposed to 
> be a `;` terminating each? Or  a `,`? Or just an empty line? Again, 
> this is one of the more common scenarios. It needs to be covered early, 
> and clearly.

... huh.  I thought we had one in there somewhere.  I will add one, thanks.  
Though to clarify, there's no separator character.

public string $foo {
get {
// ...
}
set {
// ...
}
}

> Third: the caveats around usage with arrays... give me pause. While I'm 
> personally trying to not use arrays as much as possible, a lot of code 
> I see or contribute to still does, and the fact that an array property 
> that uses a write accessor doesn't allow the same level of access as a 
> normal array property is something I see leading to a lot of confusion 
> and errors. I don't have a solution, but I worry that this one thing 
> alone could be enough to prevent the passage of the RFC.

We completely agree that it's a suboptimal situation.  But as explained, it is 
the way it is because it's not possible (as far as we can tell) to fully 
support hooks on array properties.  If you can think of one, please share, 
because we'd love to make this part better.  I don't like it either, but we 
haven't found a way around it.  And that caveat doesn't seem like a good enough 
reason to not support hooks everywhere we actually can.


> Fourth: the syntax around inheritance is not intuitive, as it does not 

Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type

[Gina P. Banyard]

Hello internals,

I updated the RFC to encompass all the feedback:
https://wiki.php.net/rfc/deprecate-implicitly-nullable-types

Let me know if there are any final remarks before we start the vote sometime 
next week.

Best regards,

Gina P. Banyard

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

[Tim Düsterhus]

Hi

1. I believe there is an error in the "Final Hooks" section:

> // But this is NOT allowed, because beforeSet is final in the parent.

I believe it should be s/beforeSet/set/.

2. In the same section this sentence is probably grammatically incorrect.

> Declaring hooks final on a property that is declared final is 
redundant will throw an error.


3. Regarding the same sentence I also don't see why that should be 
disallowed, even if it is redundant. It's also legal to define 'final' 
functions within a 'final' class. Which also brings me to the question: 
Is defining 'final' properties and 'final' hooks within a 'final' class 
equally disallowed?


4. Since the RFC was last discussed, the #[\Override] RFC was accepted 
and implemented (https://wiki.php.net/rfc/marking_overriden_methods). A 
short section on the interaction with #[\Override] would probably be 
helpful.


5. Not sure if I've asked it before, but have you considered making the 
parameter for ReflectionProperty::getHook() an enum?


On 2/21/24 19:55, Larry Garfield wrote:

There’s one outstanding question, which is slightly painful to ask: Originally, 
this RFC was called “property accessors,” which is the terminology used by most 
languages.  During early development, when we had 4 accessors like Swift, we 
changed the name to “hooks” to better indicate that one was “hooking into” the 
property lifecycle.  However, later refinement brought it back down to 2 
operations, get and set.  That makes the “hooks” name less applicable, and 
inconsistent with what other languages call it.

However, changing it back at this point would be a non-small amount of grunt 
work. There would be no functional changes from doing so, but it’s lots of 
renaming things both in the PR and the RFC. We are willing to do so if the 
consensus is that it would be beneficial, but want to ask before putting in the 
effort.



Calling it hooks is fine and allows for future extension without 
renaming, should the need arise.


Best regards
Tim Düsterhus

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

[Tim Düsterhus]

Hi

On 2/22/24 00:02, Matthew Weier O'Phinney wrote:

Once again in reading the proposal, the first thing I'm struck by are the
magic "$field" and "$value" variables inside accessors. The first time they
are used, they're used without explanation, and they're jarring.

[…]

Second: you don't have examples of defining BOTH get and set OTHER than
when using expressions for both accessors or a mix. I'm actually unclear
what the syntax is when both are defined. Is there supposed to be a `;`
terminating each? Or  a `,`? Or just an empty line? Again, this is one of
the more common scenarios. It needs to be covered early, and clearly.



On a similar topic with regard to syntax and shorthands, I'd like to 
quote myself from my previous year's email (Message-ID: 
17d7983b-68b7-e273-a445-f8399c251...@bastelstu.be, 
https://externals.io/message/120213#120216):



(5) I strongly dislike the doubly abbreviated form of public string $fullName => 
$this->first . " " . $this->last;. Having just the extra
'>' in there to distinguish it from a regular property feels non-obvious.


It's always possible to follow-up with syntax that allows for additional 
brevity, the inverse is not true and I believe for such a semantically 
complex feature, having clear and syntax syntax would be beneficial.


Best regards
Tim Düsterhus

Re: [PHP-DEV] ArrayAccess and array_key_exists function

[Tim Düsterhus]

Hi

(Robert, Ondrej, please apologize the duplicate mail, the list rejected 
my first attempt, because the previously used alias tim@ is no longer 
accepted as a valid sender, I'll need to update my subscription)


On 2/20/24 14:21, Robert Landers wrote:

I'd love to see all array_* functions accept iterators/objects instead
of only just arrays. Yes, I know the name says "array" but often we
just mean "do this operation on this thing that looks enough like an
array for now."



This is probably a good opportunity to point out this mailing list 
thread once more:


https://externals.io/message/118896#118896

Best regards
Tim Düsterhus

Re: [PHP-DEV] What's up with emails?

[Alain D D Williams]

On Thu, Feb 22, 2024 at 07:45:41PM +0100, Tim Düsterhus wrote:
> Hi
> 
> On 2/22/24 16:29, Alain D D Williams wrote:
> > • SPF for lists.php.net is "v=spf1 a mx a:osu1php.osuosl.org. 
> > ip4:45.112.84.5 ip6:2a02:cb43:8000::1102"
> > Change to "v=spf1 a mx -all"
> > 
> > •• If you make the MX change that I suggest then the
> > following are redundant: ip4:45.112.84.5 ip6:2a02:cb43:8000::1102
> 
> I disagree with that. An MX is the receiver for inbound mail. It does not
> follow that emails are sent out via the MX. Removing the explicit listing of
> the IP addresses will just cause accidents in the future, if the MX no
> longer happens to also send email.

If the setup changes and the MX no longer send email then the SPF record can be
updated. For now it is a quick way of saying a:php-smtp4.php.net.

> If anything the 'a' within the SPF record could be removed, because that's
> the HTTP box on DigitalOcean.

"a" allows lists.php.net. to send email for the domain. I do not know if it
does but could easily believe that administrative/error/... type messages come
from there.

Regards

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: External Message: Re: [PHP-DEV] What's up with emails?

[Tim Düsterhus]

Hi

On 2/22/24 15:44, Michael Kliewe wrote:

1. Don't change the content or the DKIM-signed headers of the email (do
not prepend something in the subject). Then the original DKIM signature
stays valid and the From:-header can stay untouched



Strong +1 for that one. I've suggested the same in the past, 
unfortunately without much success so far.


Best regards
Tim Düsterhus

Re: [PHP-DEV] What's up with emails?

[Tim Düsterhus]

Hi

On 2/22/24 16:29, Alain D D Williams wrote:

• SPF for lists.php.net is "v=spf1 a mx a:osu1php.osuosl.org. ip4:45.112.84.5 
ip6:2a02:cb43:8000::1102"
Change to "v=spf1 a mx -all"

•• If you make the MX change that I suggest then the
following are redundant: ip4:45.112.84.5 ip6:2a02:cb43:8000::1102


I disagree with that. An MX is the receiver for inbound mail. It does 
not follow that emails are sent out via the MX. Removing the explicit 
listing of the IP addresses will just cause accidents in the future, if 
the MX no longer happens to also send email.


If anything the 'a' within the SPF record could be removed, because 
that's the HTTP box on DigitalOcean.


Best regards
Tim Düsterhus

Re: [PHP-DEV] What's up with emails?

[Andreas Heigl]

On 22 February 2024 17:49:10 CET, Derick Rethans  wrote:
> On Thu, 22 Feb 2024, mjec wrote:
> 
> > On Thu, 2024-02-22 at 10:29 -05:00, Alain D D Williams  
> > wrote:
> >> On Thu, Feb 22, 2024 at 09:05:22AM -0500, Derick Rethans wrote:
> >> 
> >>> Gmail is rejecting emails after we moved the servers without telling us 
> >>> why, in enough detail to do anything about it.
> >> 
> >> I run other mail lists and have had similar problems with gmail recently.
> > 
> > Gmail explicitly tightened their requirements for senders this month, so 
> > while it's likely the server change is related, it may not be the entire 
> > cause.
> > 
> > Specifically, they require:
> > 
> > - valid spf, with specific rules for quarantining email that has @gmail.com 
> > From but doesn't pass spf
> > - valid dkim
> > - dmarc configured if the server sends more than 5k emails to Gmail
> 
> We should have all of that though?
> 
> > 
> > They also equivocally indicate a requirement for ARC and a List-Id header.
> 
> We have a List-Id header, but I've not even heard of ARC. It is on our list 
> to investigate though. Our SMTP logs definitely don't say anything about this 
> though.
> 
> > This is all at https://support.google.com/a/answer/81126.
> > 
> > I think ARC is a must; without it we'll never get to passing dkim at least, 
> > even if we rewrite from so spf passes.
> 
> But SPF is now passing? The postmaster tools show this:
> 
> Date  DKIM success rate   SPF success rateDMARC success rate
> 15 Feb 2024   100.0%  100.0%  0.0%
> 16 Feb 2024   100.0%  100.0%  0.0%
> 17 Feb 2024   100.0%  100.0%  0.0%
> 18 Feb 2024   100.0%  100.0%  0.0%
> 19 Feb 2024   100.0%  100.0%  100.0%
> 20 Feb 2024   100.0%  100.0%  100.0%
> 
> > I'm happy to pitch in to help getting this configured if that's helpful, 
> > though I'm also very conscious that too many cooks is often a greater harm 
> > than good when it comes to administration. But reach out if you think I can 
> > be helpful.
> 
> We could definitely use some people that now email delivery.

The main issue is that the things came together:

Us moving to a new listserver and
Gmail introducing new ways of fighting spam.

The later is what makes life hars now and would also have caused trouble on the 
old server.

We are currently in the process of implementig all of the stuff that gmail 
expects us to have.

The last ones are ARC and one-click unsubscribe.

If you want to know more about the hoops we have to jump in addition to moving 
the list to a new server check out 
https://blog.google/products/gmail/gmail-security-authentication-spam-protection/

Cheers

Andreas


--
Andreas Heigl

Re: [PHP-DEV] What's up with emails?

[Alain D D Williams]

On Thu, Feb 22, 2024 at 04:46:04PM +, Derick Rethans wrote:

> > Make the From: address internals@lists.php.net
> 
> We don't want to change the From address, as that means that replies go to
> the list, rather than the original sender. We never had to do any of that
> before.

I understand that, it also means that someone looking at a list of emails in a
mail box sees who (ie individuals) they are from rather than an email list.

> Fingers crossed to see if any of this is helping.

If things do not improve - change the From address - just for a day to see if
that makes things better.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: [PHP-DEV] What's up with emails?

[Derick Rethans]

On Thu, 22 Feb 2024, mjec wrote:


On Thu, 2024-02-22 at 10:29 -05:00, Alain D D Williams  
wrote:

On Thu, Feb 22, 2024 at 09:05:22AM -0500, Derick Rethans wrote:

Gmail is rejecting emails after we moved the servers without telling 
us why, in enough detail to do anything about it.


I run other mail lists and have had similar problems with gmail 
recently.


Gmail explicitly tightened their requirements for senders this month, 
so while it's likely the server change is related, it may not be the 
entire cause.


Specifically, they require:

- valid spf, with specific rules for quarantining email that has @gmail.com 
From but doesn't pass spf
- valid dkim
- dmarc configured if the server sends more than 5k emails to Gmail


We should have all of that though?



They also equivocally indicate a requirement for ARC and a List-Id header.


We have a List-Id header, but I've not even heard of ARC. It is on our 
list to investigate though. Our SMTP logs definitely don't say anything 
about this though.



This is all at https://support.google.com/a/answer/81126.

I think ARC is a must; without it we'll never get to passing dkim at 
least, even if we rewrite from so spf passes.


But SPF is now passing? The postmaster tools show this:

Date	DKIM success rate	SPF success rate	DMARC success 
rate

15 Feb 2024 100.0%  100.0%  0.0%
16 Feb 2024 100.0%  100.0%  0.0%
17 Feb 2024 100.0%  100.0%  0.0%
18 Feb 2024 100.0%  100.0%  0.0%
19 Feb 2024 100.0%  100.0%  100.0%
20 Feb 2024 100.0%  100.0%  100.0%

I'm happy to pitch in to help getting this configured if that's 
helpful, though I'm also very conscious that too many cooks is often a 
greater harm than good when it comes to administration. But reach out 
if you think I can be helpful.


We could definitely use some people that now email delivery.

cheers,
Derick

Re: [PHP-DEV] What's up with emails?

[Derick Rethans]

On Thu, 22 Feb 2024, Alain D D Williams wrote:


On Thu, Feb 22, 2024 at 09:05:22AM -0500, Derick Rethans wrote:


Gmail is rejecting emails after we moved the servers without telling us why, in 
enough detail to do anything about it.


I run other mail lists and have had similar problems with gmail recently.

The problem seems to be SPF. This says which IP addresses can be used for
sending email for particular domains. gmail has recently become much stricter.

List emails are sent from php-smtp4.php.net (45.112.84.5).

However the 'From' address is still that of the original sender -- which is OK
for the email that I am replying to as it is
From: Derick Rethans 

and the MX for php.net is php-smtp4-ip4.php.net. which has address 45.112.84.5

However I suspect that *this* email (the one that I am typing now) will get
bounced by gmail as my address is: a...@phcomp.co.uk and 45.112.84.5 is not
allowed (by SPF) to send email for phcomp.co.uk.

So: how to fix ?

Make the From: address internals@lists.php.net


We don't want to change the From address, as that means that replies go 
to the list, rather than the original sender. We never had to do any of 
that before.



The envelope address is already, something like
internals+bounces-122457-addw=phcomp.co...@lists.php.net

This means a fix to whatever list processor that you are using.

Other recommendations:

• MX for lists.php.net is php-smtp4-ip4.php.net.
Change to php-smtp4.php.net.


Done


• SPF for lists.php.net is "v=spf1 a mx a:osu1php.osuosl.org. ip4:45.112.84.5 
ip6:2a02:cb43:8000::1102"
Change to "v=spf1 a mx -all"


Done, but I kept it as ~all.


•• osu1php.osuosl.org. does not seem to exist - so zap it


Done


•• If you make the MX change that I suggest then the
following are redundant: ip4:45.112.84.5 ip6:2a02:cb43:8000::1102


Done


•• -all means no other addresses accepted. gmail started making that implicit in
the last few months, it is this that is causing the current problems.


I've added ~all instead.

Once that has settled down you should enable sending email from (& 
thus to) IPv6 addresses. This is the way that the world is moving. It 
is not hard.


Done that now too.

Fingers crossed to see if any of this is helping.

cheers,
Derick

Re: [PHP-DEV] What's up with emails?

[mjec]

On Thu, 2024-02-22 at 10:29 -05:00, Alain D D Williams  
wrote:
> On Thu, Feb 22, 2024 at 09:05:22AM -0500, Derick Rethans wrote:
>
>> Gmail is rejecting emails after we moved the servers without telling us why, 
>> in enough detail to do anything about it.
>
> I run other mail lists and have had similar problems with gmail recently.

Gmail explicitly tightened their requirements for senders this month, so while 
it's likely the server change is related, it may not be the entire cause.

Specifically, they require:

 - valid spf, with specific rules for quarantining email that has @gmail.com 
From but doesn't pass spf
 - valid dkim
 - dmarc configured if the server sends more than 5k emails to Gmail

They also equivocally indicate a requirement for ARC and a List-Id header.

This is all at https://support.google.com/a/answer/81126.

I think ARC is a must; without it we'll never get to passing dkim at least, 
even if we rewrite from so spf passes.

I'm happy to pitch in to help getting this configured if that's helpful, though 
I'm also very conscious that too many cooks is often a greater harm than good 
when it comes to administration. But reach out if you think I can be helpful.

mjec

Re: [PHP-DEV] What's up with emails?

[Alain D D Williams]

On Thu, Feb 22, 2024 at 09:05:22AM -0500, Derick Rethans wrote:

> Gmail is rejecting emails after we moved the servers without telling us why, 
> in enough detail to do anything about it.

I run other mail lists and have had similar problems with gmail recently.

The problem seems to be SPF. This says which IP addresses can be used for
sending email for particular domains. gmail has recently become much stricter.

List emails are sent from php-smtp4.php.net (45.112.84.5).

However the 'From' address is still that of the original sender -- which is OK
for the email that I am replying to as it is
From: Derick Rethans 

and the MX for php.net is php-smtp4-ip4.php.net. which has address 45.112.84.5

However I suspect that *this* email (the one that I am typing now) will get
bounced by gmail as my address is: a...@phcomp.co.uk and 45.112.84.5 is not
allowed (by SPF) to send email for phcomp.co.uk.

So: how to fix ?

Make the From: address internals@lists.php.net

The envelope address is already, something like
internals+bounces-122457-addw=phcomp.co...@lists.php.net

This means a fix to whatever list processor that you are using.

Other recommendations:

• MX for lists.php.net is php-smtp4-ip4.php.net.
Change to php-smtp4.php.net.

• SPF for lists.php.net is "v=spf1 a mx a:osu1php.osuosl.org. ip4:45.112.84.5 
ip6:2a02:cb43:8000::1102"
Change to "v=spf1 a mx -all"

•• osu1php.osuosl.org. does not seem to exist - so zap it
•• If you make the MX change that I suggest then the
following are redundant: ip4:45.112.84.5 ip6:2a02:cb43:8000::1102
•• -all means no other addresses accepted. gmail started making that implicit in
the last few months, it is this that is causing the current problems.

Once that has settled down you should enable sending email from (& thus to)
IPv6 addresses. This is the way that the world is moving. It is not hard.

Regards

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: [PHP-DEV] What's up with emails?

[tag Knife]

On Thu, 22 Feb 2024 at 14:12, Derick Rethans  wrote:

> On 22 February 2024 08:52:49 GMT-05:00, Robert Landers <
> landers.rob...@gmail.com> wrote:
> >I have noticed quite a number of emails appearing on externals but not
> >appearing in my inbox. I randomly get an email saying:
> >
> >Hi, this is the Mlmmj program managing the 
> >mailing list.
> >
> >Some messages to you could not be delivered. If you're seeing this
> >message it means things are back to normal, and it's merely for your
> >information.
> >
> >Here is the list of the bounced messages:
> >- 122446
> >- 122448
> >
> >But I can clearly see far more than that in externals that are never
> received.
> >
> >IIRC from the email spec and internet customs, soft-bounces should be
> >retried for a number of days (though I have no idea why gmail
> >soft-bounced the messages, maybe rate-limiting?).
> >
> >If I'm using gmail and not getting emails, how many other people are
> >also not getting emails on this list?
>
>
> Lots.
>
> Gmail is rejecting emails after we moved the servers without telling us
> why, in enough detail to do anything about it.
>
> We can put a delay in delivering to Gmail, but that means mails get
> delayed for days.
>
> So my advice would for now to not rely on Gmail while we figure out how to
> improve this.
>
> cheers
> Derick
>

This could be related to the new servers new ip not being trusted. Did you
do any sort of IP Warming
 for
the new server?
As without this, Google sees a new IP sending thousands of emails out of
nowhere and it triggers spam filters. We have
to do this at work when we onboard a new client, since we give all clients
apps there own IP, we have to run a 14 day warming
system before we can let the client go live, since without it, their emails
will most likely be blocked for spam from various inbox
providers.

Re: External Message: Re: [PHP-DEV] What's up with emails?

[Michael Kliewe]

Am 22.02.2024 um 15:14 schrieb Jeffrey Dafoe:

Gmail is rejecting emails after we moved the servers without telling us why, in
enough detail to do anything about it.

It's not just gmail.


I guess it's because of a wrong setting in the mailinglist server.

The content of the original email is changed (the subject is prepended 
by "[PHP-DEV]"), which breaks the original DKIM signature by the sender.


A new DKIM-signature is added by php.net, but it's not aligned to the 
From:-header domain (which is still the original sender).


So the email doesn't have a valid ALIGNED DKIM signature.

SPF is valid for the envelope from, but is not aligned to the From:-header.

The result is:

There is no aligned SPF nor aligned DKIM, which results in a dmarc=fail.

Providers which honor DMARC will quarantine or reject these 
unauthorized/forged emails.


There are 2 solutions:

1. Don't change the content or the DKIM-signed headers of the email (do 
not prepend something in the subject). Then the original DKIM signature 
stays valid and the From:-header can stay untouched


2. If you change the the email and break the original DKIM signature, 
also change the From:-header to a domain which matches the new DKIM 
signature, in this case set the From:-header to internals@lists.php.net. 
This is called "munging" in mailinglist software.


Michael

Re: [PHP-DEV] What's up with emails?

[Daniil Gentili]

> If I'm using gmail and not getting emails, how many other people are
> also not getting emails on this list?
>

Same here, with both gmail and zoho mail.

Personally I would switch to github issues and discussions, even ignoring all 
the deliverability issues which I had even before the switch to the new mailing 
list server on my zoho mail dan...@daniil.it account, 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: External Message: Re: [PHP-DEV] What's up with emails?

[Jeffrey Dafoe]

> Gmail is rejecting emails after we moved the servers without telling us why, 
> in
> enough detail to do anything about it.

It's not just gmail.

-Jeff

RE: External Message: [PHP-DEV] What's up with emails?

[Jeffrey Dafoe]

I had an email to the list bounce due to SpamCop adding a sizeable portion of 
Outlook's IP space into a block (as they've been erroneously doing for 25 years 
now). Emailed syst...@php.net about it, never heard back. I'm also receiving 
next-to-no list traffic and receiving similar bounce messages as what is shown 
below.

-Jeff

> -Original Message-
> From: Robert Landers 
> Sent: Thursday, February 22, 2024 8:53 AM
> To: internals 
> Subject: External Message: [PHP-DEV] What's up with emails?
> 
> I have noticed quite a number of emails appearing on externals but not
> appearing in my inbox. I randomly get an email saying:
> 
> Hi, this is the Mlmmj program managing the  mailing
> list.
> 
> Some messages to you could not be delivered. If you're seeing this message it
> means things are back to normal, and it's merely for your information.
> 
> Here is the list of the bounced messages:
> - 122446
> - 122448
> 
> But I can clearly see far more than that in externals that are never received.
> 
> IIRC from the email spec and internet customs, soft-bounces should be retried
> for a number of days (though I have no idea why gmail soft-bounced the
> messages, maybe rate-limiting?).
> 
> If I'm using gmail and not getting emails, how many other people are also not
> getting emails on this list?
> 
> Robert Landers
> Software Engineer
> Utrecht NL

Re: [PHP-DEV] What's up with emails?

[Derick Rethans]

On 22 February 2024 08:52:49 GMT-05:00, Robert Landers 
 wrote:
>I have noticed quite a number of emails appearing on externals but not
>appearing in my inbox. I randomly get an email saying:
>
>Hi, this is the Mlmmj program managing the 
>mailing list.
>
>Some messages to you could not be delivered. If you're seeing this
>message it means things are back to normal, and it's merely for your
>information.
>
>Here is the list of the bounced messages:
>- 122446
>- 122448
>
>But I can clearly see far more than that in externals that are never received.
>
>IIRC from the email spec and internet customs, soft-bounces should be
>retried for a number of days (though I have no idea why gmail
>soft-bounced the messages, maybe rate-limiting?).
>
>If I'm using gmail and not getting emails, how many other people are
>also not getting emails on this list?


Lots.

Gmail is rejecting emails after we moved the servers without telling us why, in 
enough detail to do anything about it.

We can put a delay in delivering to Gmail, but that means mails get delayed for 
days.

So my advice would for now to not rely on Gmail while we figure out how to 
improve this.

cheers
Derick

Re: [PHP-DEV] What's up with emails?

[Erick de Azevedo Lima]

> If I'm using gmail and not getting emails, how many other people are
> also not getting emails on this list?

Same here.

[PHP-DEV] What's up with emails?

[Robert Landers]

I have noticed quite a number of emails appearing on externals but not
appearing in my inbox. I randomly get an email saying:

Hi, this is the Mlmmj program managing the 
mailing list.

Some messages to you could not be delivered. If you're seeing this
message it means things are back to normal, and it's merely for your
information.

Here is the list of the bounced messages:
- 122446
- 122448

But I can clearly see far more than that in externals that are never received.

IIRC from the email spec and internet customs, soft-bounces should be
retried for a number of days (though I have no idea why gmail
soft-bounced the messages, maybe rate-limiting?).

If I'm using gmail and not getting emails, how many other people are
also not getting emails on this list?

Robert Landers
Software Engineer
Utrecht NL

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

[Deleu]

On Thu, Feb 22, 2024 at 8:25 AM tag Knife  wrote:

> A few things i was interested to get the idea around.
> Was it thought about for the set{} for it to return the value to set the
> property to
> instead implicitly setting its own field?
>
> eg
>
> ```
> public string $name {
> set {
> return usfirst($value);
> }
> }
> ```
> Where the value returned in the set is what the property will be set to?
>

The answer to this question is best described on the RFC FAQ:
https://wiki.php.net/rfc/property-hooks#why_do_set_hooks_not_return_the_value_to_set

-- 
Marco Deleu

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

[tag Knife]

On Wed, 21 Feb 2024 at 18:56, Larry Garfield  wrote:

> Hello again, fine Internalians.
>
> After much on-again/off-again work, Ilija and I are back with a more
> polished property access hooks/interface properties RFC.  It’s 99%
> unchanged from last summer; the PR is now essentially complete and more
> robust, and we were able to squish the last remaining edge cases.
>
> Baring any major changes, we plan to bring this to a vote in mid-March.
>
> https://wiki.php.net/rfc/property-hooks
>
> It’s long, but that’s because we’re handling every edge case we could
> think of.  Properties involve dealing with both references and inheritance,
> both of which have complex implications.  We believe we’ve identified the
> most logical handling for all cases, though.
>
> Note the FAQ question at the end, which explains some design choices.
>
> There’s one outstanding question, which is slightly painful to ask:
> Originally, this RFC was called “property accessors,” which is the
> terminology used by most languages.  During early development, when we had
> 4 accessors like Swift, we changed the name to “hooks” to better indicate
> that one was “hooking into” the property lifecycle.  However, later
> refinement brought it back down to 2 operations, get and set.  That makes
> the “hooks” name less applicable, and inconsistent with what other
> languages call it.
>
> However, changing it back at this point would be a non-small amount of
> grunt work. There would be no functional changes from doing so, but it’s
> lots of renaming things both in the PR and the RFC. We are willing to do so
> if the consensus is that it would be beneficial, but want to ask before
> putting in the effort.
>
> --
>   Larry Garfield
>   la...@garfieldtech.com


I remember the previous RFC. cant remeber why it was decline, but i hope
this
one passes, I know the PHP community has been asking for native
getter/setters
instead of __get __set for a while, since 7.0 was released at least.

A few things i was interested to get the idea around.
Was it thought about for the set{} for it to return the value to set the
property to
instead implicitly setting its own field?

eg

```
public string $name {
set {
return usfirst($value);
}
}
```
Where the value returned in the set is what the property will be set to?

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

[Robert Landers]

On Wed, Feb 21, 2024 at 7:59 PM Larry Garfield  wrote:
>
> Hello again, fine Internalians.
>
> After much on-again/off-again work, Ilija and I are back with a more polished 
> property access hooks/interface properties RFC.  It’s 99% unchanged from last 
> summer; the PR is now essentially complete and more robust, and we were able 
> to squish the last remaining edge cases.
>
> Baring any major changes, we plan to bring this to a vote in mid-March.
>
> https://wiki.php.net/rfc/property-hooks
>
> It’s long, but that’s because we’re handling every edge case we could think 
> of.  Properties involve dealing with both references and inheritance, both of 
> which have complex implications.  We believe we’ve identified the most 
> logical handling for all cases, though.
>
> Note the FAQ question at the end, which explains some design choices.
>
> There’s one outstanding question, which is slightly painful to ask: 
> Originally, this RFC was called “property accessors,” which is the 
> terminology used by most languages.  During early development, when we had 4 
> accessors like Swift, we changed the name to “hooks” to better indicate that 
> one was “hooking into” the property lifecycle.  However, later refinement 
> brought it back down to 2 operations, get and set.  That makes the “hooks” 
> name less applicable, and inconsistent with what other languages call it.
>
> However, changing it back at this point would be a non-small amount of grunt 
> work. There would be no functional changes from doing so, but it’s lots of 
> renaming things both in the PR and the RFC. We are willing to do so if the 
> consensus is that it would be beneficial, but want to ask before putting in 
> the effort.
>
> --
>   Larry Garfield
>   la...@garfieldtech.com

This is a reply to Marco (https://externals.io/message/122445#122449)
for which I didn't actually receive the email but got an email from
the list that I didn't receive the email -- seems like it would have
been simpler and more correct to resend the email. That is a bit
weird, but whatever.

> Given the extensive work of this RFC, it seems pretty obvious that
> this syntax will not work, I just don't know why.

I feel like the syntax is natural, coming from other languages with
this feature. However, I really do appreciate the example Marco gives
as it feels very idiomatically PHP with all the getters/setters we are
used to writing. It also means a pretty simple "just add a space and
downcase" to switch from traditional methods to getters/setters to
hooks, which could be really nice.