Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105355
Return-Path: <azjezz@protonmail.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 66256 invoked from network); 23 Apr 2019 14:09:21 -0000
Received: from unknown (HELO mail-40136.protonmail.ch) (185.70.40.136)
  by pb1.pair.com with SMTP; 23 Apr 2019 14:09:21 -0000
Date: Tue, 23 Apr 2019 11:09:41 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1556017783;
	bh=oQiCFon6XwsMlnFomwLWYIE1M/cXqBgkXHrJ1+9QDe0=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	 Feedback-ID:From;
	b=yHT9aRC8d7nWrdLofLp+id7G3oOeFvxpeir87qAciDtQPgiwHJbz9SRR65kLdOafY
	 tnIbD9DuUQDnWcHuPiWO3omKmkb2X0C900Umqw8WdtvZkwT6+HX856A6spspkCnI6v
	 WEpekSBnIHGJ5aw8st6Pt50DnoD0xNyfx76baaZw=
To: Andrey Hristov <php@hristov.com>
Cc: PHP Internals <internals@lists.php.net>
Reply-To: azjezz <azjezz@protonmail.com>
Message-ID: <uh4nAvEf3DJbzT217Ag1qSfy4mDjuRpj7c5EH91prN7jNZEh3UV0dZmL0ioAiQKb2HUiw65m7C5E3rBtivuVDBmDp1Aa5MIjyU8bbKFCDQM=@protonmail.com>
In-Reply-To: <9fee0f79-a77d-c0f1-ec24-efa4dd587f91@hristov.com>
References: <CAG9XoMS3xwNEsSvFaad5ExK4o9dhrKG9yaP2enp+yRQDmpr4Ow@mail.gmail.com>
 <CA+kxMuS7DV-iPyEBcaC0-d3W5LmsaawjF=U+ySND59L+dZ9F7Q@mail.gmail.com>
 <HscPQyDDQ0TcOQk9Ljmp2Ebf7fmL1DJnxYxmryg7A2XeKLUh--8H6YQNNJ_U418pVdNCW_6QZuJ55FBtMlPtLpY8_uNfNXd7NZrydANpHKc=@protonmail.com>
 <9fee0f79-a77d-c0f1-ec24-efa4dd587f91@hristov.com>
Feedback-ID: 2QbNVvXqZX7F9J8FTDAv0u3ryua4T0_lfklxZ8hRMzvBUxf8m8U50Gi9tVWG9V2LePU31MFOrVnxPKYLJjZPXw==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM autolearn=ham
	autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch
Subject: Re: [PHP-DEV] Object Type Casting Reloaded
From: azjezz@protonmail.com (azjezz)

Hello Andery.

yes that's possible, but would need a function for each type, or we can do =
: https://3v4l.org/6B3hA

but this is still not type-safe, as we won't be able to type hint it correc=
tly without using generics + `typename` type that exists in Hack.


using generics + `typename` : `function check<T>(mixed $var, typename<T> $t=
ype): T`


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 11:51 AM, Andrey Hristov <php@hristov.com> wrote=
:

> Hi,
> On 23.04.19 =D0=B3. 13:44 =D1=87., azjezz wrote:
>
> > Hello Dan,
> > I don' think this a problem relating to just one use case, some PHP bui=
ltin functions have weird union return types, where static analysis tools w=
ould warn you about the return type being `string|bool`, when you are expec=
ting `string`.
> > using type constrain :
> >
> >     $foo =3D substr($foo, 1, 3) as string;
> >     // there's no need to check if `$foo` is false here.
> >
>
> this is easily solvable with the following (considering strict_types is
> enabled)
>
> function tostr(string $in) : string { return $in; }
>
> $foo =3D tostr($foo);
>
> Put it in a convenience namespace and that's it.
>
> Cheers,
> Andrey
>
> > 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 Origina=
l Message =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 11:33 AM, Dan Ackroyd Danack@basereality.com=
 wrote:
> >
> > > HI Benjamin,
> > > Similar to the nullable casting idea, you're taking a problem caused
> > > by your own code/framework, and then thinking it should be solved in
> > > core, when a simple solution is available in user-land.
> > > If you changed what you currently have:
> > > $service =3D $diContainer->get('email.service');
> > > to also take the expected class:
> > > $service =3D $diContainer->get('email.service', EmailService::class);
> > > And then check inside your 'DI container' whether the expected type i=
s
> > > returned, this solves the problem without needing new syntax.
> > > btw I'm sure you're already aware of it, but this is using a
> > > 'dependency injector' as a service locator. If your current DI librar=
y
> > > isn't powerful enough for you, rather than abusing it like this, I'd
> > > recommend looking at a different one, like
> > > https://github.com/rdlowrey/Auryn
> > > Also, similar:
> > >
> > > > By the way, this RFC is a special case of something that could be f=
ar
> > > > more generic. If it was possible to register callbacks to be used w=
hen
> > > > casting, ...
> > >
> > > Apparently this might not be possible as it's ambiguous....which is a=
 shame.
> > > cheers
> > > Dan
> > > Ack
> > > On Mon, 22 Apr 2019 at 22:47, Benjamin Morel benjamin.morel@gmail.com=
 wrote:
> > >
> > > > Hi internals,
> > > > I'd like to revive an old discussion https://externals.io/message/6=
7131 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 insta=
nce of
> > > > the given class. I see the following advantages:
> > > >
> > > > -   Type safety: we can be sure that the value is of the correct ty=
pe or that
> > > >     we'll get an Error. This syntax allows to fail early if the var=
iable
> > > >     happens to not be of the expected type, and avoids much more ve=
rbose checks;
> > > >
> > > > -   Static analysis: IDEs and static code analysis tools can now un=
derstand
> > > >     the type of the variable, without having to resort to `@var` an=
notations.
> > > >
> > > >
> > > > These combine into a third advantage: readability. Today's equivale=
nt of
> > > > 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=
 your
> > > > thoughts: what's your early feeling about this? Did I miss other
> > > > discussions around this subject? Are there any technical issues tha=
t come
> > > > to mind? Could this feature help the upcoming JIT compiler produce =
more
> > > > efficient machine code by knowing the type of the variable at compi=
le time?
> > > > etc.
> > > > Note: "casting" might not be the perfect name here as what we're re=
ally
> > > > doing is a type check, but this reuses the type casting syntax and
> > > > resembles Java's object casting.
> > > > Thank you,
> > > > Ben
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php