Re: Concept: constructor overloading syntax sugar

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.php@rwec.co.uk>: > > > > On 17 February 2025 14:39:42 GMT, Viktor Khramov <dev.999.victor@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]