I don't see this as worth the b/c break. Good docs is better to explain clearly what it means

I don't see this as worth the b/c break.

It do not break old code.
The backward compatibility here we can extend untill Joomla 7 or 10 or anything.

At some point people have to migrate. And it's these naming convention changes that annoy developers more than anything else.

Yeah, I hate it too ?
This is also an argument to make it now, or never.

Because currently in j4 ~40 event classes,
And upcomming 5.0 will have ~170 event classes. And after it will be released there will be no easy way to change it.

Not like I very want to work on it, but I found many people confused by these naming very much. Especialy when trying to do a public setFoobar(...) {$this->setArgument('foobar', ...)}, and wonder why they get infinity loop.

I'm in favor for this change, only question for b/c, what happen if someone extends a core event (what not should be done) and override an existing setXXX method, this would be in the new version converted to onSetXXX() but the override will no longer work right?

For existing (in 4.x), we just do "proxy" call, example this

will be:

// add @deprecation tag
protected function setSubject($value){
  //... old code 
}

protected function onSetSubject($value) {
  return $this->setSubject($value);
}

There around 40 of such methods.

And all new events in 5.0, we just have to edit to use new onSetFoobar.

I have prepared PR for all new event classes in 5.0 #41830

What about having a generic function prepare($key, $value) function instead of all these duplicated code. onGet/Set sounds for me like the good old PHP 4 days.

Or if a generic one is not ok, then like prepareFoo().

And here is the update for existing 4.x events #41831

What about having a generic function prepare($key, $value)

With this you need to have a switch case or if else.
And in the result much more complex code I think.
But in general also can work.

Or if a generic one is not ok, then like prepareFoo().

Naming can be any. To me onSet/onGet is fine.

I would change the naming to something more meaningfull as onSet says nothing what the function actually does. But I leave here the decision to @HLeithner, as you guys did the heavy work on the events conversion in 5. If you think it is ok, fee free to merge.

After a longer discussion on mattermost, we didn't find a better name and it fits the "event" naming a bit, so I merge this for 4.4 and we will change the names as described by @Fedik in #41831