# Improving PHP's type system

- Thread: https://externals.io/message/92252
- Original archive: https://news-web.php.net/php.internals/92252
- Started by Levi Morrison on 2016-04-13T16:50:53+00:00
- Messages: 94
- Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/92252.md?page=2
- 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

---

## #92252 — Levi Morrison — 2016-04-13T16:50:53+00:00

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

First, some background: several versions of PHP ago authors of
functions and methods could only restrict types to the array type or a
class/interface type. We slowly added some other types such as
callable and primitive types. These tools have been invaluable to
those who care about restricting the types of their inputs and
outputs. This type information reduces the code each author has to
write if they want to restrict to working with certain types and it
also provides a form of documentation. Overall these features have
been well received and are considered a good thing to do.

However, as we have added these new restrictions we still cannot
express exactly what types are permitted in some common cases.

  1. Return types cannot specify the function will return only type T or Null.
  2. Parameter types cannot express that an iterable type is required.
It's common for functions to work a stream of data and it is
irrelevant if it is an array or a Traversable object.
  3. Parameter types cannot express that that the parameter must
implement two different interfaces. For example, requiring a parameter
to implement both Countable and Traversable cannot be done.

There are some common work-arounds to these issues:

  - Omit the type information and rely on documentation.
  - Check the parameter type inside the function (eg
`assert(is_array($x) || $x instanceof Traversable)`)
  - Introduce a new type that embodies the restrictions. If this in an
interface it must be implemented by every object you hope to use the
restriction with.

In some cases these work-arounds are tolerable. However, some of them
are really painful.

  - Requiring a new supertype is intrusive. Code cannot always be
changed to use the new supertype. For example:
    - Upstream projects that would not benefit from your changes.
    - Primitives cannot be extended except by altering the engine.
    In these cases a new type has to be introduced that proxies
behavior to the underlying object/primitive.
  - Relying on documentation can lead to subtle and hard to diagnose
issues when it is used incorrectly. Erroring immediately is sometimes
preferable.

All of these issues I've outlined can be nicely resolved by adding two
new kinds of types to our system: union and intersection types. A
union type requires the variable to match at least one of the types.
An intersection type requires the variable to match all of the types.
The vertical par symbol (OR) is used for unions and ampersand (AND) is
used for intersections. For example:

    function (A | B $var); would require $var to be either type A or type B.
    function (A & B $var); would require $var to be type A and type B.

To accommodate the common use-case of returning some type or Null we
would need to formally allow `Null` as an explicit type:

    function (): T | Null;

Since this is a common use case some languages have a short-hand
notation to represent a union with Null:

---

## #92253 — Levi Morrison — 2016-04-13T16:53:13+00:00

URL: https://externals.io/message/92252#92253 · In reply to: #92252

Continued (hit send by hotkey accident):


> First, some background: several versions of PHP ago authors of
> functions and methods could only restrict types to the array type or a
> class/interface type. We slowly added some other types such as
> callable and primitive types. These tools have been invaluable to
> those who care about restricting the types of their inputs and
> outputs. This type information reduces the code each author has to
> write if they want to restrict to working with certain types and it
> also provides a form of documentation. Overall these features have
> been well received and are considered a good thing to do.
>
> However, as we have added these new restrictions we still cannot
> express exactly what types are permitted in some common cases.
>
>   1. Return types cannot specify the function will return only type T or Null.
>   2. Parameter types cannot express that an iterable type is required.
> It's common for functions to work a stream of data and it is
> irrelevant if it is an array or a Traversable object.
>   3. Parameter types cannot express that that the parameter must
> implement two different interfaces. For example, requiring a parameter
> to implement both Countable and Traversable cannot be done.
>
> There are some common work-arounds to these issues:
>
>   - Omit the type information and rely on documentation.
>   - Check the parameter type inside the function (eg
> `assert(is_array($x) || $x instanceof Traversable)`)
>   - Introduce a new type that embodies the restrictions. If this in an
> interface it must be implemented by every object you hope to use the
> restriction with.
>
> In some cases these work-arounds are tolerable. However, some of them
> are really painful.
>
>   - Requiring a new supertype is intrusive. Code cannot always be
> changed to use the new supertype. For example:
>     - Upstream projects that would not benefit from your changes.
>     - Primitives cannot be extended except by altering the engine.
>     In these cases a new type has to be introduced that proxies
> behavior to the underlying object/primitive.
>   - Relying on documentation can lead to subtle and hard to diagnose
> issues when it is used incorrectly. Erroring immediately is sometimes
> preferable.
>
> All of these issues I've outlined can be nicely resolved by adding two
> new kinds of types to our system: union and intersection types. A
> union type requires the variable to match at least one of the types.
> An intersection type requires the variable to match all of the types.
> The vertical par symbol (OR) is used for unions and ampersand (AND) is
> used for intersections. For example:
>
>     function (A | B $var); would require $var to be either type A or type B.
>     function (A & B $var); would require $var to be type A and type B.
>
> To accommodate the common use-case of returning some type or Null we
> would need to formally allow `Null` as an explicit type:
>
>     function (): T | Null;
>
> Since this is a common use case some languages have a short-hand
> notation to represent a union with Null:

    function (): ?T;

Examples of such languages include Swift, C#, OCaml and Hack (though
the symbol is sometimes in the front and sometimes in the back.

Later today I will be submitting RFCs for each of these proposals.
Although they can work independently it is helpful to understand the
overall goal and how they fit together, which has been the purpose of
this email. Feedback for each RFC will belong in the thread for that
piece, but discussion about the ideas overall is better suited here.

---

## #92257 — Fleshgrinder — 2016-04-13T19:10:36+00:00

URL: https://externals.io/message/92252#92257 · In reply to: #92253

Nothing to add other than +1, however, didn't you already write those?

https://wiki.php.net/rfc/nullable_types
https://wiki.php.net/rfc/union_types

Or is this just an announcement that these will be finalized now?

Btw. I am in favor of having the question mark as a suffix and not as a
prefix because it is more readable and more natural to type.

function fn(string? $str): bool?;

Declare a function with the name fn that takes a string argument that is
nullable which will return a bool or null.

That is exactly how I would think about the above while writing and
reading. :)

-- 
Richard "Fleshgrinder" Fussenegger

---

## #92261 — Levi Morrison — 2016-04-13T19:57:41+00:00

URL: https://externals.io/message/92252#92261 · In reply to: #92257

> Nothing to add other than +1, however, didn't you already write those?
>
> https://wiki.php.net/rfc/nullable_types
> https://wiki.php.net/rfc/union_types
>
> Or is this just an announcement that these will be finalized now?
>
> Btw. I am in favor of having the question mark as a suffix and not as a
> prefix because it is more readable and more natural to type.
>
> function fn(string? $str): bool?;
>
> Declare a function with the name fn that takes a string argument that is
> nullable which will return a bool or null.
>
> That is exactly how I would think about the above while writing and
> reading. :)
>
> --
> Richard "Fleshgrinder" Fussenegger
>

I have written them but later they will be formally moved to Under
Discussion and will create new threads for them here on the mailing
list.

---

## #92262 — Fleshgrinder — 2016-04-13T20:02:51+00:00

URL: https://externals.io/message/92252#92262 · In reply to: #92261

> 
> > […]
> 
> I have written them but later they will be formally moved to Under
> Discussion and will create new threads for them here on the mailing
> list.
> 

Awesome, let me know if I can be of any help, even if it is only proof
reading. This is an extremely valuable addition that I want to have.

May I suggest you the following article (more of a starting point into
Ceylon actually) regarding this topic:

http://ceylon-lang.org/documentation/tour/types/

Ceylon is very nicely designed regarding union and intersection types
and I think it can add value to learn from these people too. I am not
handing out this because I think that you don't know what you are doing.
The opposite is the case. However, Ceylon is very young and I don't
think many people know of it; while you probably already know all the
oldies who support union and intersection types. ;)

-- 
Richard "Fleshgrinder" Fussenegger

---

## #92263 — Stephen Coakley — 2016-04-13T20:12:10+00:00

URL: https://externals.io/message/92252#92263 · In reply to: #92253

> Continued (hit send by hotkey accident):
> 
> 
> > […]
> 
>     function (): ?T;
> 
> Examples of such languages include Swift, C#, OCaml and Hack (though the
> symbol is sometimes in the front and sometimes in the back.
> 
> Later today I will be submitting RFCs for each of these proposals.
> Although they can work independently it is helpful to understand the
> overall goal and how they fit together, which has been the purpose of
> this email. Feedback for each RFC will belong in the thread for that
> piece, but discussion about the ideas overall is better suited here.

COOLNESS!! +10

I really like this mindset of a general solution to these stricter types. 
I think it will present a more consistent "interface" for using types 
across PHP in the future.

In general, this is a more general and elegant solution to nullable type 
in properties, hints, and return types.

I am eager to see what you have in those RFCs. ?

-- 
Stephen

---

## #92265 — Stanislav Malyshev — 2016-04-13T20:24:45+00:00

URL: https://externals.io/message/92252#92265 · In reply to: #92262

Hi!

> May I suggest you the following article (more of a starting point into
> Ceylon actually) regarding this topic:

There was a time where PHP was considered a good beginner's language.
Now it seems we want to pivot and target category theory PhDs instead? :)
-- 
Stas Malyshev
smalyshev@gmail.com

---

## #92266 — Fleshgrinder — 2016-04-13T20:42:29+00:00

URL: https://externals.io/message/92252#92266 · In reply to: #92265

> Hi!
> 
> > […]
> 
> There was a time where PHP was considered a good beginner's language.
> Now it seems we want to pivot and target category theory PhDs instead? :)
> 

Hahaha funny how many people consider Ceylon to be too academic. :)

I personally just want to make the language more consistent, secure (in
terms of introduction of bugs and error handling), and better suited for
real enterprise and high performance usage. And of course learn a
shitload about language design along the way. ;)

-- 
Richard "Fleshgrinder" Fussenegger

---

## #92267 — Bob Weinand — 2016-04-13T20:52:48+00:00

URL: https://externals.io/message/92252#92267 · In reply to: #92265

> Am 13.04.2016 um 22:24 schrieb Stanislav Malyshev <smalyshev@gmail.com>:
> 
> Hi!
> 
> > […]
> 
> There was a time where PHP was considered a good beginner's language.
> Now it seems we want to pivot and target category theory PhDs instead? :)
> -- 
> Stas Malyshev
> smalyshev@gmail.com

PHP has and will retain the invaluable capability of not requiring types.

If you have weak types, which you have by default, it's just about as easy as it was the last 15 years.
The only thing which changed is that not only internal functions but also user functions can impose some limits on what is being accepted. I could understand your complains if it were completely new and not even internal functions ever rejected inputs based on types [or rather how well-formed numeric strings they are].

The only thing a bit harder (requiring a little understanding of types), is when you edit files with strict types active. But still, if that's too much of pain for a beginner, he's free to disable them.

Types are designed in a way enhancing the languages experience while avoiding nearly every impact for people who want to ignore them.

And that's great.

And that's why we shall continue on improving our *optional* type system.

Thanks,
Bob

---

## #92268 — Stanislav Malyshev — 2016-04-13T21:06:39+00:00

URL: https://externals.io/message/92252#92268 · In reply to: #92267

Hi!

> Types are designed in a way enhancing the languages experience while
> avoiding nearly every impact for people who want to ignore them.

This is not true. If it's in language, you have to understand it to be
able to use the language. Nobody writes code in vacuum - there are
libraries, communities, teams, best practices, tutorials, etc. So if
(hypothetically) you want to introduce algebraic types in PHP, then
since that moment you can not really be a PHP programmer if you don't
understand algebraic types. Otherwise you would not be able to
communicate with the rest of the community, understand and use code
written by others, contribute to projects, etc.

> And that's why we shall continue on improving our *optional* type
> system.

That's a very broad statement which which everybody agrees - who's
against improving? Who'd want to make the type system *worse*? Nobody.
The specifics are more complicated - do we really need complex type
expressions in PHP to the point of inventing micro-language with its own
syntax to just specify a type? I don't think so.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #92270 — Larry Garfield — 2016-04-13T21:13:34+00:00

URL: https://externals.io/message/92252#92270 · In reply to: #92265

> Hi!
>
> > […]
> There was a time where PHP was considered a good beginner's language.
> Now it seems we want to pivot and target category theory PhDs instead? :)

A language that is usable primarily by beginners will only be useful for 
beginners.  Non-beginners will shun it, or simply grow out of it and leave.

A language that is usable only by PhDs will be useful only for PhDs.  
Beginners won't be able to comprehend it.

A language that is usable by both beginners and PhDs, and can scale a 
user from beginner to PhD within the same language, will be used by both.

Doing that is really hard. And really awesome. And the direction PHP has 
been trending in recent years is in that direction.  Which is pretty 
danged awesome. :-)

-- 
--Larry Garfield

---

## #92272 — Zeev Suraski — 2016-04-13T23:43:02+00:00

URL: https://externals.io/message/92252#92272

> 
> 
> > […]
> 
> A language that is usable primarily by beginners will only be useful for beginners.  Non-beginners will shun it, or simply grow out of it and leave.
> 
> A language that is usable only by PhDs will be useful only for PhDs.  Beginners won't be able to comprehend it.
> 
> A language that is usable by both beginners and PhDs, and can scale a user from beginner to PhD within the same language, will be used by both.
> 
> Doing that is really hard. And really awesome. And the direction PHP has been trending in recent years is in that direction.  Which is pretty danged awesome. :-)

I would argue that PHP was already doing that almost since inception.  I think we have ample evidence that we've been seeing a lot of different types of usage - both beginners' and ultra advanced going on in PHP for decades.
I would also argue that in recent years, the trending direction has been focusing on the "PhDs", while neglecting the simplicity seekers (which I wouldn't necessarily call beginners).  Making PHP more and more about being like yet-another-language, as opposed to one that tries to come up with creative, simplified ways of solving problems.
Last, I'd argue that a language that tries to be everything for everybody ends up being the "everything's and the kitchen sink", rather than somethings that is truly suitable for everyone.

We also seemed to have dumped some of our fundamental working assumptions - that have made PHP extremely successful to begin with:

- Emphasis on simplicity
- Adding optional features makes the language more complex regardless of whether everyone uses them or not

It does seem as if we're trying to replicate other languages, relentlessly trying to "fix" PHP, which has been and still is one of the most successful languages out there - typically a lot more so than the languages we're trying to replicate.

Zeev

---

## #92275 — Peter Lind — 2016-04-14T06:13:54+00:00

URL: https://externals.io/message/92252#92275 · In reply to: #92272

>
> > […]
> wrote:
> > […]
> :)
> > […]
> beginners.  Non-beginners will shun it, or simply grow out of it and leave.
> > […]
> Beginners won't be able to comprehend it.
> > […]
> user from beginner to PhD within the same language, will be used by both.
> > […]
> been trending in recent years is in that direction.  Which is pretty danged
> awesome. :-)
>
> I would argue that PHP was already doing that almost since inception.  I
> think we have ample evidence that we've been seeing a lot of different
> types of usage - both beginners' and ultra advanced going on in PHP for
> decades.
> I would also argue that in recent years, the trending direction has been
> focusing on the "PhDs", while neglecting the simplicity seekers (which I
> wouldn't necessarily call beginners).  Making PHP more and more about being
> like yet-another-language, as opposed to one that tries to come up with
> creative, simplified ways of solving problems.
> Last, I'd argue that a language that tries to be everything for everybody
> ends up being the "everything's and the kitchen sink", rather than
> somethings that is truly suitable for everyone.
>
> We also seemed to have dumped some of our fundamental working assumptions
> - that have made PHP extremely successful to begin with:
>
> - Emphasis on simplicity
> - Adding optional features makes the language more complex regardless of
> whether everyone uses them or not
>
>
Really? The recent number of RFCs focusing on making some of PHPs
annoyances go away have passed you by? They seem to fall squarely within
"emphasis on simplicity" as far as I can tell.

Also, PHP is known as the language with a million ways to do things, where
some functions even have aliases because reasons. It's been that way since
a very long time. That suggests to me that complexity/optional features are
not frowned upon - only some types of complexity are seen as bad, and only
some types of simplicity are apparent worthwhile. Spelling out personal
preferences here would probably help solve these discussions faster.



> It does seem as if we're trying to replicate other languages, relentlessly
> trying to "fix" PHP, which has been and still is one of the most successful
> languages out there - typically a lot more so than the languages we're
> trying to replicate.
>
>
Regards
Peter


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

---

## #92282 — Tony Marston — 2016-04-14T09:00:41+00:00

URL: https://externals.io/message/92252#92282 · In reply to: #92272

"Zeev Suraski"  wrote in message 
news:5B147E88-CC0A-4CBC-A49D-C7FE3BF557C0@zend.com...
>
>
> > […]
>
>I would argue that PHP was already doing that almost since inception.  I 
>think we have ample evidence that we've been seeing a lot of different 
>types of usage - both beginners' and ultra advanced going on in PHP for 
>decades.
>I would also argue that in recent years, the trending direction has been 
>focusing on the "PhDs", while neglecting the simplicity seekers (which I 
>wouldn't necessarily call beginners).  Making PHP more and more about being 
>like yet-another-language, as opposed to one that tries to come up with 
>creative, simplified ways of solving problems.
>Last, I'd argue that a language that tries to be everything for everybody 
>ends up being the "everything's and the kitchen sink", rather than 
>somethings that is truly suitable for everyone.
>
>We also seemed to have dumped some of our fundamental working assumptions - 
>that have made PHP extremely successful to begin with:
>
>- Emphasis on simplicity
>- Adding optional features makes the language more complex regardless of 
>whether everyone uses them or not
>
>It does seem as if we're trying to replicate other languages, relentlessly 
>trying to "fix" PHP, which has been and still is one of the most successful 
>languages out there - typically a lot more so than the languages we're 
>trying to replicate.
>
>Zeev

I agree with Zeev 100%. There are too many people out there who are trying 
to make the language more complicated than it need be just to prove how 
clever they are. The aim of any language should be to enable programmers to 
do complicated things in a simple way, and not to do simple things in a 
complicated way.

I have been programming for over 30 years, so in no way can I be classed as 
a newbie. PHP is my favourite language because of its simplicity. I started 
with PHP 4, and although I have upgraded to PHP 5 I refuse to use any of the 
"clever" additions which have been made to PHP 5 simply because I can 
achieve what I need to achieve WITHOUT using any of those additions.

I will not be making use of any changes that are made to the language in 
order to handle typed variables for the simple reason that PHP was 
specifically designed to be an untyped language, and in the 13+ years that I 
have been programming with PHP I have found that to be more of an advantage 
than a hindrance.

-- 
Tony Marston

---

## #92287 — Alain Williams — 2016-04-14T09:44:40+00:00

URL: https://externals.io/message/92252#92287 · In reply to: #92282

> I agree with Zeev 100%. There are too many people out there who are
> trying to make the language more complicated than it need be just to
> prove how clever they are. The aim of any language should be to
> enable programmers to do complicated things in a simple way, and not
> to do simple things in a complicated way.

I disagree. My way of looking at it is that adding some features(eg the current
type specification/checking) adds to the simplicity because I can say what types
I want and don't need to write code to check the types of argument received by a
function (etc).

Why would I want to check: because I value robustness, ie not having my code
fall over because, somehow, a wrong type slips by unnoticed.

Does that make quick/simple programming not possible in PHP ?

No: I will put the most of the robustness work into libraries/classes that I
write and want to reuse - the simple programs that use them don't necessarily be
written to the same standard.

> I have been programming for over 30 years, so in no way can I be
> classed as a newbie. PHP is my favourite language because of its
> simplicity. I started with PHP 4, and although I have upgraded to
> PHP 5 I refuse to use any of the "clever" additions which have been
> made to PHP 5 simply because I can achieve what I need to achieve
> WITHOUT using any of those additions.
> 
> I will not be making use of any changes that are made to the
> language in order to handle typed variables for the simple reason
> that PHP was specifically designed to be an untyped language, and in
> the 13+ years that I have been programming with PHP I have found
> that to be more of an advantage than a hindrance.

Type juggling is useful, but somewhere you do need to check your input.

I doubt that we will agree, but we don't need to: we prob have different aims
and goals. There is no reason that PHP cannot satisfy both of us.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h

---

## #92289 — Lester Caine — 2016-04-14T09:56:17+00:00

URL: https://externals.io/message/92252#92289 · In reply to: #92265

> > […]
> There was a time where PHP was considered a good beginner's language.
> Now it seems we want to pivot and target category theory PhDs instead? :)

Well it's well above my M.Sc in Digital Systems ... but that was gained
in 1982 and it seems even my wife's primary school charges are already
trained to a higher level of programming.

-- 
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

---

## #92291 — Lester Caine — 2016-04-14T09:59:51+00:00

URL: https://externals.io/message/92252#92291 · In reply to: #92282

> I have been programming for over 30 years, so in no way can I be classed
> as a newbie. PHP is my favourite language because of its simplicity. I
> started with PHP 4, and although I have upgraded to PHP 5 I refuse to
> use any of the "clever" additions which have been made to PHP 5 simply
> because I can achieve what I need to achieve WITHOUT using any of those
> additions.

+1
I certainly wish I'd stopped at PHP5.2 and simply maintained a safe copy
of that.

-- 
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

---

## #92299 — Lin Yo-An — 2016-04-14T12:47:49+00:00

URL: https://externals.io/message/92252#92299 · In reply to: #92287

> 
>
> > […]
>
> I disagree. My way of looking at it is that adding some features(eg the
> current
> type specification/checking) adds to the simplicity because I can say what
> types
> I want and don't need to write code to check the types of argument
> received by a
> function (etc).

Why would I want to check: because I value robustness, ie not having my code
> fall over because, somehow, a wrong type slips by unnoticed.



I think the original purpose of adding type system in Hack, is to provide
just-in-time compilation, this provides more information to let compiler to
optimize the code with specific type.

Haskell, OCaml, C or C++, these statically typed languages compile code
into executable binary, the compiler raises the warnings or errors before
executing it, thus they have more time to check type information, they
usually don't check type in the run-time.

However PHP is not, PHP runs script on the fly, and check the type in the
runtime (instead of compile time), therefore the type checking implemented
in PHP is a kind of execution performance trade off (until we implemented
the JIT compiler). and a complex type system add more extra work to the
whole system than statically typed language.

Adding type hinting makes people writing PHP code with more confident, I
like the scalar type hinting implemented in the current PHP.

But weak type conversion and union type are not, it introduces more complex
rules of how variables should be converted into another values, and there
will be more implementation defined behavior. People will have to always
have a cheatsheet or something to check whether if they write the correct
code.

And I believe, if we can remove the support of weak type conversion, PHP
could be a "consistent", "simple" language and it can help people write
confident code.



Cheers, Yo-An Lin

---

## #92302 — Levi Morrison — 2016-04-14T14:29:18+00:00

URL: https://externals.io/message/92252#92302 · In reply to: #92282

> There are too many people out there who are trying to make the language more complicated than it need be just to prove how clever they are.

I can assure you I am not proposing these RFCs to show how clever I am.

---

## #92309 — Fleshgrinder — 2016-04-14T17:54:23+00:00

URL: https://externals.io/message/92252#92309 · In reply to: #92299

> But weak type conversion and union type are not, it introduces more complex
> rules of how variables should be converted into another values, and there
> will be more implementation defined behavior. People will have to always
> have a cheatsheet or something to check whether if they write the correct
> code.
> 
> And I believe, if we can remove the support of weak type conversion, PHP
> could be a "consistent", "simple" language and it can help people write
> confident code.
> 

I don't know what is complicated about "string|Stringable" or "Foo|Bar"
since it is super self-explanatory. However, I find myself checking the
docs (IDE or online) in which order I need to pass arguments to one of
the various mixed up functions in the core all the time.

PHP is not easy, it has so many quirks that one needs to know of that
you could make a PhD only for that.

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

This contains A LOT of that stuff.

-- 
Richard "Fleshgrinder" Fussenegger

---

## #92310 — Stanislav Malyshev — 2016-04-14T18:59:53+00:00

URL: https://externals.io/message/92252#92310 · In reply to: #92309

Hi!

> I don't know what is complicated about "string|Stringable" or "Foo|Bar"
> since it is super self-explanatory. However, I find myself checking the

It may be self-explanatory for you. It's much less self-explanatory for
somebody just starting to learn. It is also very dangerous - if it's
either Foo or Bar, can you call Foo::stuff on it or not? If it's string
or not string, can you call strlen on it? Etc., etc. It adds a lot of
cognitive load and complicates the whole picture. You may have a
specific use case where it is useful (which we have yet to see btw) but
please remember it's a language with literally millions of use cases and
users.

> docs (IDE or online) in which order I need to pass arguments to one of
> the various mixed up functions in the core all the time.

Which takes about 0.5 seconds. Can we please not waste time on
discussing argument order some 9000th time?

> PHP is not easy, it has so many quirks that one needs to know of that
> you could make a PhD only for that.

PHP has some quirks, but it doesn't take PhD to look up argument order
in a manual. Anyway, having super-complicated type algebra does not help
any with argument order, so I'm not sure why it's brought here at all.

> https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
> 
> This contains A LOT of that stuff.

Oh, could we please stop referring to this list of nitpicks each time we
discuss the language? About 90% of it is not worth the bytes spent on it
for discussing it again and again. Using it as some kind of magic "some
guy wrote article bashing PHP, therefore my proposals need to be
accepted" card makes no sense at all.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #92311 — Fleshgrinder — 2016-04-14T19:25:12+00:00

URL: https://externals.io/message/92252#92311 · In reply to: #92310

> Hi!
> 
> > […]
> 
> It may be self-explanatory for you. It's much less self-explanatory for
> somebody just starting to learn. It is also very dangerous - if it's
> either Foo or Bar, can you call Foo::stuff on it or not? If it's string
> or not string, can you call strlen on it? Etc., etc. It adds a lot of
> cognitive load and complicates the whole picture. You may have a
> specific use case where it is useful (which we have yet to see btw) but
> please remember it's a language with literally millions of use cases and
> users.
> 

Reduce assertions*, enhance self-documentation, making code more robust,
perform checks in the VM and not in userland, ...

function fn($arg) {
    assert('is_string($arg) || method_exists($arg, "__toString")');
}

interface Stringable {
    function __toString(): string;
}

function fn(string|Stringable $arg) {
    // :)
}

You can find more information on the topic here:

https://en.wikipedia.org/wiki/Tagged_union

* Assertions in PHP are very error prone if combined with refactoring
due to the fact that one should enclose the actual assertion in a string.

-- 
Richard "Fleshgrinder" Fussenegger

---

## #92312 — Fleshgrinder — 2016-04-14T19:27:46+00:00

URL: https://externals.io/message/92252#92312 · In reply to: #92311

> 
> > […]
> 
> Reduce assertions*, enhance self-documentation, making code more robust,
> perform checks in the VM and not in userland, ...
> 
> function fn($arg) {
>     assert('is_string($arg) || method_exists($arg, "__toString")');
> }
> 
> interface Stringable {
>     function __toString(): string;
> }
> 
> function fn(string|Stringable $arg) {
>     // :)
> }
> 
> You can find more information on the topic here:
> 
> https://en.wikipedia.org/wiki/Tagged_union
> 
> * Assertions in PHP are very error prone if combined with refactoring
> due to the fact that one should enclose the actual assertion in a string.
> 

Oh oh oh, I forgot the very important unions *int|string* and
*float|string* for overflows as one can encounter them from time to
time; even in native code.

-- 
Richard "Fleshgrinder" Fussenegger

---

## #92313 — Jordi Boggiano — 2016-04-14T19:32:21+00:00

URL: https://externals.io/message/92252#92313 · In reply to: #92310

Heya,


> > […]
>
> It may be self-explanatory for you. It's much less self-explanatory for
> somebody just starting to learn. It is also very dangerous - if it's
> either Foo or Bar, can you call Foo::stuff on it or not? If it's string
> or not string, can you call strlen on it? Etc., etc. It adds a lot of
> cognitive load and complicates the whole picture.

I don't really think it's much more complex to grasp `Foo|Bar $foo` than 
only `Foo $foo`. I mean once you grasp the concept of type hints you 
probably have by then a good understanding of || and hopefully can 
derive understanding from there.

That said I agree it's rarely useful, and as such I am not expecting 
we'll see this all over the place, it's just nice to have when you need 
it, but I can't think of very many valid cases (nullable types are much 
more common).

Please take that into consideration as well when arguing that it adds 
complexity. If it's rarely seen in the wild it's not very valuable but 
it's *also* not hindering newcomers often.

> You may have a
> specific use case where it is useful (which we have yet to see btw) but
> please remember it's a language with literally millions of use cases and
> users.

Just to highlight one use case I can think of, here is one:

https://github.com/Seldaek/monolog/blob/master/src/Monolog/Handler/MongoDBHandler.php#L51-L53

We need some sort of Mongo thing, and there are two available with 
different interfaces, so here both are accepted but as you see in the 
code below they are handled kinda separately. It would just save us 
those 3 lines of check if we could type-hint appropriately.

And it would save us one line of phpdoc as well because IDEs could infer 
the information from the code.

Cheers

-- 
Jordi Boggiano
@seldaek - http://seld.be

---

## #92315 — Stanislav Malyshev — 2016-04-14T19:59:27+00:00

URL: https://externals.io/message/92252#92315 · In reply to: #92312

Hi!

> > […]

You don't reduce assertions, you just make them more cryptic and change
error message slightly.

> Oh oh oh, I forgot the very important unions *int|string* and
> *float|string* for overflows as one can encounter them from time to
> time; even in native code.

Not sure what are you referring here to, but I suspect you are trying to
reimplement weak typing in some partial inconsistent and strange way,
while pretending it's strong typing.

-- 
Stas Malyshev
smalyshev@gmail.com

---

Next page: https://externals.io/message/92252.md?page=2