# STH and the 3 RFCs

- Thread: https://externals.io/message/84708
- Original archive: https://news-web.php.net/php.internals/84708
- Started by guilhermeblanco@gmail.com on 2015-03-13T18:53:35+00:00
- Messages: 9
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #84708 — guilhermeblanco@gmail.com — 2015-03-13T18:53:35+00:00

URL: https://externals.io/message/84708#84708

Hi internals,

I carefully read all 3 proposed RFCs related to scalar type hints.
As an end user and enthusiast of the language, I want PHP to always
improve. STH is *the* major inclusion for PHP 7 and no matter how many
people say about phpng performance, STH is the one that will impact mostly
everyone on a day by day basis.

Now I also understand the rush of getting this feature in PHP considering
the voted and approved deadline for feature freeze of PHP 7. However, we're
not in a mission critical, losing millions or facing a world collapse if it
takes an extra day or two to figure it out what people want, specially such
an important feature. That said, I consider the feature freeze date a soft
deadline than a hard one, and again, keeping in mind we could be
potentially delaying the freeze due to the importance of what we're
deciding.

Back to the subject. I am a a strict camper, but I understand the nature of
PHP and its loose type.
Considering the 3 RFCs, and also counting the number of WTFs each one adds,
I hereby describe my choice.

By considering PHP's nature, having a dual mode is a WTF. I can see myself
asking multiple times a day "is this file strict or not?" to trace
potential bugs or type juggling. I do want strict, but I don't think it's
the right time for PHP to make this move. Userland would have strictness,
but all internal functions are a weird WTF type juggling mode. I originally
switched my vote many times in the v3 of the RFC, mainly because PHP
developers are the ones that would suffer by these configurability on a
daily basis. I ended up with a YES vote because when considering STH or
nothing at all, I prefer to have some.
Coercive STH already added a WTH by not being inline with ZPP. It also have
a timely migration path to turn them in sync, which would bring more
breakage, more refactoring and more headache.
Basic STH is the only one inline with ZPP, and the mostly natural for every
PHP developer. They understand how internal PHP functions work and they
know what to do. It also does not have the duality mode as v5 RFC.
Therefore, this is where I'd place my vote.

However, I do think that ZPP needs to migrate as Coercive STH partially
defined to a stricter conversion scenario. That is what Basic STH should
follow, but at the same time pace, not creating a discrepancy now and a WTF
to userland. Ideally, Basic STH should also reuse ZPP support, meaning that
any updates to ZPP would also benefit the STH.


That said, I'll place my vote as YES in Basic STH and vote NO for the other
ones.


Regards,

-- 
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

---

## #84713 — Lester Caine — 2015-03-13T19:41:21+00:00

URL: https://externals.io/message/84708#84713 · In reply to: #84708

> By considering PHP's nature, having a dual mode is a WTF. I can see myself
> asking multiple times a day "is this file strict or not?" to trace
> potential bugs or type juggling. I do want strict, but I don't think it's
> the right time for PHP to make this move. Userland would have strictness,
> but all internal functions are a weird WTF type juggling mode. I originally
> switched my vote many times in the v3 of the RFC, mainly because PHP
> developers are the ones that would suffer by these configurability on a
> daily basis. I ended up with a YES vote because when considering STH or
> nothing at all, I prefer to have some.

The bigger WTF is perhaps that moving forward one has no idea just what
a third party library is using internally. A case has been made that
this does not matter since calling that library from a non-strict site
will simply work as now, but in that case the library is not designed to
handle non-strict input. It assumes that the strict check happens, where
a well designed 'weak' library will be handling the edge cases properly.
It not simply a matter of "is this file strict or not?" but rather "what
happens when I pass the wrong data?".

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #85034 — David Muir — 2015-03-16T11:54:37+00:00

URL: https://externals.io/message/84708#85034 · In reply to: #84713

> > […]
> 
> The bigger WTF is perhaps that moving forward one has no idea just what
> a third party library is using internally. A case has been made that
> this does not matter since calling that library from a non-strict site
> will simply work as now, but in that case the library is not designed to
> handle non-strict input. It assumes that the strict check happens, where
> a well designed 'weak' library will be handling the edge cases properly.
> It not simply a matter of "is this file strict or not?" but rather "what
> happens when I pass the wrong data?".

If I've understood the RFC's correctly, your point is moot. With any scalar type hints, a library will not be able to tell how it is being called. All it knows is that it has received an int, string, float, or boolean where it has asked for one. A library written in weak or strict mode will have no bearing on its public API. This is the case with all of the STH RFCs. 

So no, a weak mode library is not better off. It is actually worse off because it has more edge cases where things could go wrong (internally), while a strict library will not function at all until the edge cases are actually taken care of.

As far as being a user of the library itself, the strictness or weakness of the library code is irrelevant. You can use a weak library in strict mode, and the library would never know or care.

if you decide to make all your own code strict, you're not changing the behavior of the library. If you make all your own code weak, you're not changing the behavior of the library. Even if you strips out all the declare strict statements, it will not change the behavior of the library (except in the case where the code was broken and wasn't even working previously!).

I think the best way to explain the dual mode RFC is to think of it like this:
Imagine PHP threw a COERCIBLE_TYPE_MISMATCH notice whenever you pass the wrong type to a function. In weak mode, the type gets coerced, the notice is ignored, and we truck along as if nothing happened. Strict mode is basically where you've set up a custom, per-file error handler where COERCIBLE_TYPE_MISMATCH notices are turned into fatal errors. It is your code that decides which error handler to use.

Cheers,
David

---

## #85052 — Lester Caine — 2015-03-16T13:20:27+00:00

URL: https://externals.io/message/84708#85052 · In reply to: #85034

> > […]
> If I've understood the RFC's correctly, your point is moot. With any scalar type hints, a library will not be able to tell how it is being called. All it knows is that it has received an int, string, float, or boolean where it has asked for one. A library written in weak or strict mode will have no bearing on its public API. This is the case with all of the STH RFCs. 
> 
> So no, a weak mode library is not better off. It is actually worse off because it has more edge cases where things could go wrong (internally), while a strict library will not function at all until the edge cases are actually taken care of.
> 
> As far as being a user of the library itself, the strictness or weakness of the library code is irrelevant. You can use a weak library in strict mode, and the library would never know or care.
> 
> if you decide to make all your own code strict, you're not changing the behavior of the library. If you make all your own code weak, you're not changing the behavior of the library. Even if you strips out all the declare strict statements, it will not change the behavior of the library (except in the case where the code was broken and wasn't even working previously!).
> 
> I think the best way to explain the dual mode RFC is to think of it like this:
> Imagine PHP threw a COERCIBLE_TYPE_MISMATCH notice whenever you pass the wrong type to a function. In weak mode, the type gets coerced, the notice is ignored, and we truck along as if nothing happened. Strict mode is basically where you've set up a custom, per-file error handler where COERCIBLE_TYPE_MISMATCH notices are turned into fatal errors. It is your code that decides which error handler to use.

Thank you for that David ...
It makes sense of a number of points.
I think that what I really need is a simple crib sheet of 'just' weak
typing in this RFC and if that conflicts with my own current program
flow. I simply don't subscribe to the implication that type hinting is
essential to make PHP better. I just prefer in-line error handling to
exception handlers.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #85060 — Thomas Punt — 2015-03-16T14:33:18+00:00

URL: https://externals.io/message/84708#85060

Hey David,
> A library written in weak or strict mode will have no bearing on its public API.

Strictly speaking (pun intended), this is not true. A library can easily expose a
facade that enforces a user of that library (who is in weak mode) to have to write
in strict mode [1]. Once more, this can be done unintentionally [2] because of the
caller-deciding semantics. These examples can be further extended into wrapper
classes, nested library dependencies, etc.

Sure, you could argue that this could easily be turned off by simply removing the
top declare() statement of that library, but modifying the library in itself introduces
complications - especially when using dependency managers like Composer.

[1] https://gist.github.com/tpunt/4830d18d47e2df021c2f
[2] https://gist.github.com/tpunt/eecfed2495bdccb73632

-Tom

---

## #85079 — Dennis Birkholz — 2015-03-16T18:29:43+00:00

URL: https://externals.io/message/84708#85079 · In reply to: #85060

Hi Thomas,

Am 16.03.2015 um 15:33 schrieb Thomas Punt:
> A library can easily expose a facade that enforces a user of that library
> (who is in weak mode) to have to write in strict mode [1]. Once more,
> this can be done unintentionally [2] because of the
> caller-deciding semantics. These examples can be further extended into wrapper
> classes, nested library dependencies, etc.

if the library author wants to fuck up his or her users, that library
will be forgotten very fast. And exposing a non hinted interface and
then using the received variables in strict mode is either fucking up
the user or just a bug.

Greets
Dennis

---

## #85086 — David Muir — 2015-03-16T20:06:34+00:00

URL: https://externals.io/message/84708#85086 · In reply to: #85060

> 
> 
> Hey David,
> > […]
> 
> Strictly speaking (pun intended), this is not true. A library can easily expose a
> facade that enforces a user of that library (who is in weak mode) to have to write
> in strict mode [1]. Once more, this can be done unintentionally [2] because of the
> caller-deciding semantics. These examples can be further extended into wrapper
> classes, nested library dependencies, etc.
> 
> Sure, you could argue that this could easily be turned off by simply removing the
> top declare() statement of that library, but modifying the library in itself introduces
> complications - especially when using dependency managers like Composer.
> 
> [1] https://gist.github.com/tpunt/4830d18d47e2df021c2f
> [2] https://gist.github.com/tpunt/eecfed2495bdccb73632
> 
> -Tom               

No, your example would blow up regardless of the caller being in strict mode or weak mode. The calls made in the library are strict, and will always fail with bad input. All you've shown is that poor code will blow up with poor input validation.

If you had:
<?php
declare(strict_types=1);
require 'library.php';
(new LibraryFacade)->test('1');

It would still error just as before.

Cheers,
David

---

## #85089 — Thomas Punt — 2015-03-16T20:51:50+00:00

URL: https://externals.io/message/84708#85089

> No, your example would blow up regardless of the caller being in strict mode or weak mode.

That was the point in my hypothetical example - the library can decide
what mode it wants the user to use (strict or weak) if it wants to.

-Tom

---

## #85096 — padraic.brady@gmail.com — 2015-03-16T22:01:52+00:00

URL: https://externals.io/message/84708#85096 · In reply to: #85089

Hi Thomas,


>
> > […]
>
> That was the point in my hypothetical example - the library can decide
> what mode it wants the user to use (strict or weak) if it wants to.

Sticking with that as a theory...

function foo ($i) {
    if(!is_int($i)) {
        throw ToysOutOfPramException('I need an integer!');
    }
}

We can already do this. Indeed, we do do this. Yes, it *might* be seen
as a dick move employing any sort of trick to push strict type hints
specifically, but being explicit is quite acceptable. I have code
stuffed full of those gems and deployed === checks. So while I
appreciate it looks bad, it's nothing all that new to find people
taking steps to enforce a strict view of acceptable values. There's a
reason why type hints, in some form, have support from the community.

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com