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] <[email protected]>:
>
>
>
> On 17 February 2025 14:39:42 GMT, Viktor Khramov <[email protected]> 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]
Thread (10 messages)