Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126435
Feedback-ID: id5114917:Fastmail
Date: Tue, 18 Feb 2025 08:00:22 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Concept: constructor overloading syntax sugar
User-Agent: K-9 Mail for Android
In-Reply-To: <CAA0W4qKeJ-KXGmQFCsF6wMN746cbFhUF-D71zxdNtX2xrU_tCg@mail.gmail.com>
References: <CAA0W4qKeJ-KXGmQFCsF6wMN746cbFhUF-D71zxdNtX2xrU_tCg@mail.gmail.com>
Message-ID: <BB121A3F-789F-4FEA-B032-ABC455E1E56C@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 17 February 2025 14:39:42 GMT, Viktor Khramov <dev=2E999=2Evictor@gmail=
=2Ecom> wrote:
>Hi!
>
>The point is here:
>https://gist=2Egithub=2Ecom/vhood/665418835e65be26d5a818fded92ab75


>Static functions look awful and break the object's API=2E

Personally, I think quite the opposite: named constructors make a lot more=
 sense than type-based overloads=2E For instance, you might have both creat=
eFromJson and createFromYaml; their inputs are both going to be "string" as=
 far as the type system is concerned, so overloading would be useless=2E

Swift gets around this using "argument labels" which is sort of like requi=
ring named arguments and despatching based on those names, but I believe is=
 actually derived from SmallTalk's multipart method names=2E

Delphi is more explicit: a constructor is any class method marked with "co=
nstructor" in its declaration, and the name "Create" is just a convention=
=2E It does also support overloading on types, so other names are rarely us=
ed, which is a shame=2E

In your example, instead of this meaning different things based on what $a=
 happens to hold:

$decision =3D new Decision($a, $b);

You could write one of these to be clear:=20

$decision =3D Decision::createFromId($a, $b);
$decision =3D Decision::createFromMail($a, $b);


Even if someone were to come up with a working implementation of overloadi=
ng in PHP's type system, I would probably oppose it, because I think it mak=
es code harder to read and reason about=2E

Regards,
Rowan Tommins
[IMSoP]