Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101423
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <88921EA7-EB68-4630-AA9E-DE0C04342F0B@heigl.org>
References: <72392123-d37b-26df-6886-218f48205f8a@fleshgrinder.com>
 <5171148a-3554-35a3-ab72-370e1aac4a3f@php.net> <88921EA7-EB68-4630-AA9E-DE0C04342F0B@heigl.org>
Date: Tue, 26 Dec 2017 19:20:55 +0300
Message-ID: <CAEbg-4Z43ZAixhutNdyd3_MjOLPRy2FQWQJ6nO8gLiNjK4UywA@mail.gmail.com>
To: Andreas Heigl <andreas@heigl.org>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="f403045f1466431a1a056140adec"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
From: lisachenko.it@gmail.com (Alexander Lisachenko)

--f403045f1466431a1a056140adec
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

In some distant future it could be implemented in more natural way with
classes for primitive types and automatic boxing/unboxing for primitive
built-in types:

Php\Type\Object
Php\Type\Scalar
   =E2=8C=8A Php\Type\String
   =E2=8C=8A Php\Type\Integer
   =E2=8C=8A Php\Type\Float
   =E2=8C=8A Php\Type\Boolean
Php\Type\Array

And it will be easy to typehint all scalars via common parent class:

public function acceptsScalar(Scalar $scalarValue).

But all scalar objects in this case should be implemented as immutable or
should be passed as copy (like arrays). So, I would vote no for adding
special scalar typehint without mapping it to the common class or
interface, like iterable =3D> Traversable, callable =3D> Closure, etc

Best regards, Alexander

2017-12-26 18:59 GMT+03:00 Andreas Heigl <andreas@heigl.org>:

> Hey All.
>
> > Am 26.12.2017 um 14:38 schrieb Sebastian Bergmann <sebastian@php.net>:
> >
> >> Am 24.12.2017 um 15:34 schrieb Fleshgrinder:
> >> I prepared a PR to add the `scalar` pseudo-type to PHP after the
> >> discussions around adding a `mixed` pseudo-type. I strongly believe th=
at
> >> it makes sense to provide the most common primitive union types with
> >> handy aliases even if we are going to add union types in the future to
> PHP.
> >
> > Thank you, Richard, for working on this.
> >
> > I spent a lot of time this year introducing scalar type declarations in=
to
> > existing code bases. In quite a few cases I was not able to do so becau=
se
> > the existing code works with parameters that can be of two or more scal=
ar
> > types. With PHP 7.2, I can only document this outside of the code using
> > @param annotations (until the code has been refactored to work with onl=
y
> > one parameter type).
> >
> > With a "scalar" type declaration I would not have to fall back to @para=
m
> > annotations and could express the type in actual syntax.
>
> Just a stupid question from someone that isn't following all the
> discussions here. So forgive me if the question was already asked and
> answered.
>
> What would be wrong with a "composed type hint"? Something like
> int|float|double $numeric. Or array|Traversable $iterator?
>
> It would allow people to add "mixed" typehints without having to introduc=
e
> multiple typehints that combine different scalar typehints. And it could
> even allow typehinting different Objects in one function.
>
> Yes, it allows people to shoot themselfes into their own feet.
>
> And I'd only allow that for parameter types and never ever for return
> types.
>
> But it might be an idea.
>
> Cheers
>
> Andreas
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f403045f1466431a1a056140adec--