Decision::createFromId($uuid, $comment); Decision::createFromMail($subject, $body); Decision::createFromSome($a, $b, $c); Decision::createFromAnother($a);
This doesn't look like constructors. It will be hard to read the class, it will take time to come up with a name, it's not right. I have different colors for functions and magic methods in my IDE, __construct is always in focus. new Decision($uuid, $comment); new Decision($subject, $body); This makes it much easier to quickly understand what is going on. вт, 18 февр. 2025 г. в 11:03, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk>: > > > > On 17 February 2025 14:39:42 GMT, Viktor Khramov <dev.999.vic...@gmail.com> > wrote: > >Hi! > > > >The point is here: > >https://gist.github.com/vhood/665418835e65be26d5a818fded92ab75 > > > >Static functions look awful and break the object's API. > > Personally, I think quite the opposite: named constructors make a lot more > sense than type-based overloads. For instance, you might have both > createFromJson and createFromYaml; their inputs are both going to be "string" > as far as the type system is concerned, so overloading would be useless. > > Swift gets around this using "argument labels" which is sort of like > requiring named arguments and despatching based on those names, but I believe > is actually derived from SmallTalk's multipart method names. > > Delphi is more explicit: a constructor is any class method marked with > "constructor" in its declaration, and the name "Create" is just a convention. > It does also support overloading on types, so other names are rarely used, > which is a shame. > > In your example, instead of this meaning different things based on what $a > happens to hold: > > $decision = new Decision($a, $b); > > You could write one of these to be clear: > > $decision = Decision::createFromId($a, $b); > $decision = Decision::createFromMail($a, $b); > > > Even if someone were to come up with a working implementation of overloading > in PHP's type system, I would probably oppose it, because I think it makes > code harder to read and reason about. > > Regards, > Rowan Tommins > [IMSoP]
