Fix AbstractPlatform::EventManager property phpdoc

[mvorisek]

Q	A
Type	improvement
BC Break	no
Fixed issues	no

[mvorisek]

should that two Psalm warnings be fixed by allowing to set null in setEventManager method?

[greg0ire]

IMO no. I'd rather have people check with a hasEventManager method, and I think people should get an exception in 3.0.x when calling getEventManager and it returns null.

[mvorisek]

IMO no. I'd rather have people check with a hasEventManager method, and I think people should get an exception in 3.0.x when calling getEventManager and it returns null.

because too much assertions needed in static analysis?

https://github.com/doctrine/dbal/blob/master/src/Platforms/AbstractPlatform.php#L112 this is how it looks at master

[greg0ire]

because too much assertions needed in static analysis?

Yes, and also because people that don't use SA should get a better error message than "call to method foo() on null", and they should get the error message as soon as possible as opposed to when they attempt to call the method on null. That's only my opinion though, and since it is like you pointed out on master, maybe it would be great to get @morozov 's opinion too.

[morozov]

This is already fixed in 3.0.x (#3932) and enforced by the strict PHPStan rules. I don't think we should be making or backporting any type changes that are not enforced by static analysis (see #4346 which should have been part of #4319).

[morozov]

I'd rather have people check with a hasEventManager method, and I think people should get an exception in 3.0.x when calling getEventManager and it returns null.

This get/set/has approach is just a glorified global variable. Object methods should be worded in terms of "do".

[mvorisek]

Closing, because:

• get/set/has - 3.0.x is not named that way
• 2.12.x - is annotated not correctly, but you do not want to update