Allows extending abstract implementation without forcing Status constants
Coming off our conversations at:
auraphp/Aura.Payload_Interface#2
auraphp/Aura.Payload_Interface#3
I think it makes sense to provide an Abstract implementation which allows us
to extends the basic functionality (setters and getters as defined in the
interface), but does not force the use of statuses which we may or may not
want to implement for any given domain.
As it stands, we can override the Status constants (as they are not in the
interface), but I do not believe we can remove them short of starting afresh.
This PR would allow us to extend the AbstractPayload and not get all the
Status constants, or continue to extends the Payload and still get all the
predefined statuses.
I think this might be a proper step in the direction of what I think we want
here, namely: Providing an essentially abstract base class to be extended and
implemented as per the requirements of a domain, while not forcing an onerous
amount of work on the implementor to "just get it up and running".
I'm not sure how this plays with your concern raised in the previously mentioned
thread in regards to type hinting against an Abstract payload. I think the
response, is just "don't do that", no? Why type hint against the Abstract class
when there's a perfectly good interface to type hint against?
Allows extending abstract implementation without forcing Status constants
Coming off our conversations at:
I think it makes sense to provide an
Abstractimplementation which allows us to extends the basic functionality (setters and getters as defined in the interface), but does not force the use of statuses which we may or may not want to implement for any given domain.As it stands, we can override the Status constants (as they are not in the interface), but I do not believe we can remove them short of starting afresh.
This PR would allow us to extend the
AbstractPayloadand not get all the Status constants, or continue to extends thePayloadand still get all the predefined statuses.I think this might be a proper step in the direction of what I think we want here, namely: Providing an essentially abstract base class to be extended and implemented as per the requirements of a domain, while not forcing an onerous amount of work on the implementor to "just get it up and running".
I'm not sure how this plays with your concern raised in the previously mentioned thread in regards to type hinting against an Abstract payload. I think the response, is just "don't do that", no? Why type hint against the Abstract class when there's a perfectly good interface to type hint against?
Thoughts?