You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is it possible to use this approach, so if one subclassed your class, constructors are returning also instances of the subclass instead of the original one? Otherwise, subclassing has limited usage.
Example: I wanted to subclass LocalDate to add a very simple "format" method, that will just return "YYYY-mm-dd", but there might be other use cases.
The text was updated successfully, but these errors were encountered:
I'm not fond of allowing subclassing in my libraries, unless some class is designed specifically for this purpose. Actually, I might even make the classes final at some point, for 2 reasons:
it adds a constraint for backward compatibility
I generally find that subclassing a library's classes does not make a good design: instead, if extensibility is required, an interface should be explicitly provided for this purpose; if not, then composition should be favoured over inheritance.
I'd rather then implement what you think is missing from the library (in this case, a custom format method), so I will close this issue as a duplicate of #3, which is asking for a custom format method as well.
As a final note, did you see that __toString() actually returns YYYY-mm-dd? So you should be able to use (string) $date and be set.
http://php.net/manual/en/language.oop5.late-static-bindings.php
Is it possible to use this approach, so if one subclassed your class, constructors are returning also instances of the subclass instead of the original one? Otherwise, subclassing has limited usage.
Example: I wanted to subclass LocalDate to add a very simple "format" method, that will just return "YYYY-mm-dd", but there might be other use cases.
The text was updated successfully, but these errors were encountered: