Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105351
Date: Tue, 23 Apr 2019 09:33:44 +0000
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Benjamin Morel <benjamin.morel@gmail.com>, PHP Internals <internals@lists.php.net>
Reply-To: azjezz <azjezz@protonmail.com>
Message-ID: <ftbzkkfpooub5mAzlwHOKw_V1WTlZ230gBzW0UD7Kl0gvlepqBBUVLVA2EzypT3yFyWIZ1AqE0M748d3SfTim0Unc4FEuZ7NsknNJD-01pk=@protonmail.com>
In-Reply-To: <CAF+90c-DNeV1+K=T9UCGaLwwQihkm7M+Fvqa83mQPdGDGFezVw@mail.gmail.com>
References: <CAG9XoMS3xwNEsSvFaad5ExK4o9dhrKG9yaP2enp+yRQDmpr4Ow@mail.gmail.com>
 <CAF+90c-DNeV1+K=T9UCGaLwwQihkm7M+Fvqa83mQPdGDGFezVw@mail.gmail.com>
Feedback-ID: 2QbNVvXqZX7F9J8FTDAv0u3ryua4T0_lfklxZ8hRMzvBUxf8m8U50Gi9tVWG9V2LePU31MFOrVnxPKYLJjZPXw==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Object Type Casting Reloaded
From: azjezz@protonmail.com (azjezz)

Hello Nikita,

I would love to hear your opinion on the `as` syntax from Hack, and whether=
 it can be used in PHP the same way or would it be an issue.

Cheers,

- Saif

Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Tuesday, April 23, 2019 10:16 AM, Nikita Popov <nikita.ppv@gmail.com> wr=
ote:

> On Mon, Apr 22, 2019 at 11:48 PM Benjamin Morel benjamin.morel@gmail.com
> wrote:
>
> > Hi internals,
> > I'd like to revive an old discussion https://externals.io/message/67131
> > about
> > object type casting.
> > The idea would be to allow (ClassName) casting:
> >
> >     $service =3D (EmailService) $diContainer->get('email.service');
> >
> >
> > The above code would throw a TypeError if the value is not an instance =
of
> > the given class. I see the following advantages:
> >
> > -   Type safety: we can be sure that the value is of the correct type o=
r that
> >     we'll get an Error. This syntax allows to fail early if the variabl=
e
> >     happens to not be of the expected type, and avoids much more verbos=
e
> >     checks;
> >
> > -   Static analysis: IDEs and static code analysis tools can now unders=
tand
> >     the type of the variable, without having to resort to `@var` annota=
tions.
> >
> >
> > These combine into a third advantage: readability. Today's equivalent o=
f
> > the above one-liner could be:
> >
> >     /** @var EmailService $service */
> >     $service =3D $diContainer->get('email.service');
> >     if (! $service instanceof EmailService) {
> >         throw new TypeError('Expected instance of EmailService, ...');
> >     }
> >
> >
> > Which is a lot of boilerplate code that could be easily avoided by
> > introducing this new syntax.
> > Before moving forward and working on a formal RFC, I'd like to hear you=
r
> > thoughts: what's your early feeling about this? Did I miss other
> > discussions around this subject? Are there any technical issues that co=
me
> > to mind? Could this feature help the upcoming JIT compiler produce more
> > efficient machine code by knowing the type of the variable at compile t=
ime?
> > etc.
> > Note: "casting" might not be the perfect name here as what we're really
> > doing is a type check, but this reuses the type casting syntax and
> > resembles Java's object casting.
> > Thank you,
> > Ben
>
> Without commenting on the rest of the proposal: It's not possible to use
> (ClassName) as a cast syntax, because it is ambiguous. For example (Foo)
> [$x] is already valid syntax (fetch constant Foo and take index $x), or
> (Foo) +$bar, etc.
>
> The only reason why (int) etc are okay is because we treat the whole (int=
)
> as a single token, something we can't do in general (because it would bre=
ak
> foo(Foo)).
>
> Nikita