Static method in interface?

[mindplay-dk]

Any particular reason why getHeadersFromServer is part of ServerRequestCreatorInterface?

It's not like you can call it as ServerRequestCreatorInterface::getHeadersFromServer() - you always have to reference the implementation of a static method... static methods in interfaces don't generally make any sense - possibly except when you're just trying to make sure you implement a static method in the same way in several classes, but even then, it doesn't serve as any kind of abstraction, and you only have one implementation here, so...?

[Zegnat]

Any particular reason why getHeadersFromServer is part of ServerRequestCreatorInterface?

This would be a question for @Nyholm.

Although I will take responsibility (the blame?) for making it static. Mostly as it didn’t make a lot of sense (to me) to have a method that is basically a polyfill for getallheaders() depend on a class being instantiated before calling it.

My thought process on this method was something along these lines:

1. Use of this class often requires access to the request header values,
2. it is impossible to rely on getallheaders() in many environments,
3. if the class needs to be useful in many environments a getallheaders() polyfill is required,
4. such a polyfill makes sense to be usable as a standalone piece of code.

That said, I do understand where you are coming from with its use in an interface.

What would be an intuitive way of requiring what is basically a polyfill? Preferably in such a way that it can easily be reused so people do not end up having multiple copies of the same polyfill in their code-base?

Of course it can be dropped from the interface completely. But I would expect implementations to often end up putting such code inside their fromGlobals() method anyway.

[mindplay-dk]

Although I will take responsibility (the blame?) for making it static

I don't have a problem with the fact that it's static - it's a pure functions, so that's fine.

What would be an intuitive way of requiring what is basically a polyfill?

A pure function, such as you have :-)

Of course it can be dropped from the interface completely.

That's all I'm suggesting :-)

My only point is that static methods in interfaces are generally meaningless - you can force somebody to implement a static method, but calling it in the abstract isn't really a thing.