Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77185
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6E402FE8-119A-4BBB-B652-97A0DBEC8BC9@ajf.me>
References: <6893A97A-EC4C-4124-B804-96E2A26B953F@ajf.me>
	<20140914000718.GB14312@phcomp.co.uk>
	<3177B936-50C1-4E5D-8687-FD235C72B411@ajf.me>
	<54153692.7050500@sugarcrm.com>
	<9CE963B0-E624-4267-BC2A-0F8D1F985DAE@ajf.me>
	<6f2236e18c61d30b247e1c6bb2de10f1@mail.gmail.com>
	<CAPhkiZxU0TQp1zJ5GcuhTFAaEhcYJ6Wg0cGyAnqYhY85id7Q5w@mail.gmail.com>
	<8556C1E7-EDF3-47E2-9DA0-C9AB63DE56E6@ajf.me>
	<CAPhkiZy5EMJRRef3Q4MnnQUe-ufVcwioCUa9rFmHy_JBKh5F3Q@mail.gmail.com>
	<6E402FE8-119A-4BBB-B652-97A0DBEC8BC9@ajf.me>
Date: Sun, 14 Sep 2014 19:09:26 +0300
Message-ID: <CAPhkiZwsZ42f0sbdcbORZpBE+WeX5GqpDBxaFGUHRWYiLuz9MA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Zeev Suraski <zeev@zend.com>, Stas Malyshev <smalyshev@sugarcrm.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
From: narf@devilix.net (Andrey Andreev)

On Sun, Sep 14, 2014 at 6:47 PM, Andrea Faulds <ajf@ajf.me> wrote:
>
> On 14 Sep 2014, at 16:40, Andrey Andreev <narf@devilix.net> wrote:
>
>> ... and I responded to this in the next paragraph. Userland doesn't
>> case about internal differences, that's why they're called internal
>> and why people outside of php-internals have for so long been puzzled
>> why we only have array and object type hints.
>
> "Internal functions=E2=80=9D refers to functions from extensions. It has =
no relation to internal*s*, the mailing list.

I'm aware of that, hence why I said 'php-internals' to refer to the
mailing list. Again, userland devs don't care about that - PHP is
their language and they only care how we/they interact with it, not
what happens under the hood. Imagine for a moment that you've never
been involved in the development of PHP itself and you'll see how what
I say makes a lot of sense.

>> That's exactly what I'm talking about ... we already have a syntax for
>> strict typing, (and I want to put an emphais on this) *regardless of
>> the reasons why, we do have strict type hints*. I don't understand why
>> everybody is pretending that PHP doesn't have that feature just
>> because we're talking about scalars here.
>
> Nobody=E2=80=99s arguing we don=E2=80=99t already have strict type hints.=
 I=E2=80=99m arguing strict hints don=E2=80=99t make sense for scalars. Not=
e that we document strict (array, object) parameter types and non-strict (s=
calar) parameter types in the same way in our documentation.

And because you don't think it makes sense (and that might mean you
don't think it _now_), you're ignoring it. That's also a reason why
the documentation is done that way - nobody has thought of writing it
differently, because they didn't have to. The docs can always be
updated, but once the language changes, there's no going back.

>> Speaking strictly from a userland perspective, using that same syntax
>> for something different will be inconsistent and will cause confusion.
>> That another syntax could be used for strict typing in the future is
>> just not a serious thing to say.
>
> Why is it "not a serious thing to say=E2=80=9D? I don=E2=80=99t understan=
d.

Because it's obvious that you're not even thinking of that as a
possibility. What would that syntax be? "function foo([int] $bar)" ?

As I already said, we already have and use a syntax for strict typing.
This RFC uses that same syntax for something different and that's
wrong, hence why the RFC should be changed, not the other way around.

>> You can't say it's the worst of both worlds when you have both worlds
>> in their entirety.
>
> No, you can. Allowing both options can be =E2=80=9Cthe worst of both worl=
ds=E2=80=9D. This is just a trivial matter of semantics, though.

I'll ... just say that it's also the best of both worlds and agree to
disagree, I think you got the idea.

>> And most importantly, they have always been two
>> separate worlds because they just don't make sense otherwise.
>
> Have they? We already mix strict and non-strict typing in PHP. Functions =
taking objects, internal or not, will error if you pass the wrong type of o=
bject. Internal functions taking scalars will not error and instead cast, a=
t least most of the time.

I already noted multiple times that I'm talking as a userland
developer and that no userland developer (generally speaking, of
course) cares about internal functions.

Cheers,
Andrey.