Improving PHP's type system

10 years ago by Levi Morrison — view source — reply

unread

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.

Return types cannot specify the function will return only type T or Null.
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.
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:

10 years ago by Levi Morrison — view source — reply

unread

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.

Return types cannot specify the function will return only type T or Null.

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.

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.

10 years ago by Fleshgrinder — view source — reply

unread

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

10 years ago by Levi Morrison — view source — reply

unread

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.

10 years ago by Fleshgrinder — view source — reply

unread

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.

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

10 years ago by Stanislav Malyshev — view source — reply

unread

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

10 years ago by Fleshgrinder — view source — reply

unread

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? :)

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

10 years ago by Bob Weinand — view source — reply

unread

Am 13.04.2016 um 22:24 schrieb Stanislav Malyshev smalyshev@gmail.com:

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

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

10 years ago by Stanislav Malyshev — view source — reply

unread

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

10 years ago by Tom Worster — view source — reply

unread

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.

I agree. This is an important point. I should include it in my RFC[1]
that argues pro nullable return but contra nullable params or unions.
May I copy-paste?

Tom

[1] https://wiki.php.net/rfc/nullable_returns

10 years ago by Larry Garfield — view source — reply

unread

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? :)

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

10 years ago by Lester Caine — view source — reply

unread

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? :)

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

10 years ago by Stephen Coakley — view source — reply

unread

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.

Return types cannot specify the function will return only type T
or Null.

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.

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.

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

10 years ago by Zeev Suraski — view source — reply

unread

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? :)

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

10 years ago by Peter Lind — view source — reply

unread

On 14 באפר׳ 2016, at 7:14, Larry Garfield larry@garfieldtech.com
wrote:

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?
:)

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

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

10 years ago by Tony Marston — view source — reply

unread

"Zeev Suraski" wrote in message
news:5B147E88-CC0A-4CBC-A49D-C7FE3BF557C0@zend.com...

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?
:)

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

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

10 years ago by Alain Williams — view source — reply

unread

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

10 years ago by Lin Yo-An — view source — reply

unread

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.

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

10 years ago by Fleshgrinder — view source — reply

unread

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

10 years ago by Stanislav Malyshev — view source — reply

unread

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

10 years ago by Fleshgrinder — view source — reply

unread

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.

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

10 years ago by Fleshgrinder — view source — reply

unread

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.

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

10 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

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

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

10 years ago by Fleshgrinder — view source — reply

unread

Hi!

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

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

e.g.
https://secure.php.net/mysqli.affected-rows#refsect1-mysqli.affected-rows-returnvalues

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.

Nope, I want to strengthen from weak to almost-strict for real use-cases
as outlined before. Of course there are other and better possibilities
but Larry Garfield already outlined it much better than I ever could why
they might not be as useful as union and intersection types. Also, I
never said that one does not require additional checks, however ...

function fn(Foo|Bar $arg) {
    if ($arg instanceof Foo) {
        $arg->foo();
    }
    else {
        $arg->bar();
    }
}

... is still much better than ...

function fn($arg) {
    if ($arg instanceof Foo) {
        $arg->foo();
    }
    elseif ($arg instanceof Bar) {
        $arg->bar();
    }
    else {
        // ????
    }
}

... and currently one can handle it only as ...

/**
 * @param Foo|Bar $arg
 */
function fn($arg) {
    assert('$arg instanceof Foo || $arg instanceof Bar');
    if ($arg instanceof Foo) {
        $arg->foo();
    }
    else {
        $arg->bar();
    }
}

This is an explanatory example real world usage for me is mainly
handling and decorating of built-in PHP stuff.

function fn(string|Stringable $s) {
    // Avoid having type casts everywhere and handle it where
    // needed.
    $s = (string) $s;
}

function fn(int|string $i) {
    // Handle scalar and big integer
}

function fn(float|string $f) {
    // Handle scalar and real number
}

function fn(array|Traversable $t) {
    // foreach
}

public function getLastInsertId(): int|string {
    return $this->mysqli->insert_id;
}

// No easy check for big int possible anymore. :(
public function getLastInsertId(): string {
    return (string) $this->mysqli->insert_id;
}
// Note that this currently would be my preferred way of handling
// this case because one should not perform arithmetic operations
// on an ID. However, I sadly see it happening all the time...

// Would be awesome but operator overloading is not supported. :(
public function getLastInsertId(): NaturalNumber {
    return new NaturalNumber($this->mysqli->insert_id);
}

// This works with integers but there is no equivalent for real
// numbers available. :(
//
// Extending of GMP in userland is not possible and hence adding
// restrictions to it (e.g. above NaturalNumber or a
// PositiveNaturalNumber) is not possible and again needs to be
// spread among the whole code base.
public function getLastInsertId(): GMP {
    return gmp_init($this->mysqli->insert_id, 10);
}

public function findEntityById(int $id): ?Entity {
    // Not acceptable because we have a BIGINT.
}

https://github.com/Fleshgrinder/php-assertion/blob/master/src/Variable.php#L492-L512

public function findEntityById(string $id): ?Entity {
    assert('\Variable::isPositiveNaturalNumber($id)');
}

/** @throws EntityNotFound */
public function getEntityById(string $id): Entity {
    assert('\Variable::isPositiveNaturalNumber($id)');
}

public function findEntityById(GMP $id): ?Entity {
    assert('$id > 0');
}

/** @throws EntityNotFound */
public function getEntityById(GMP $id): Entity {
    assert('$id > 0');
}

public function findEntityById(PositiveNaturalNumber $id): ?Entity {
    // DRY + secure :)
}

/** @throws EntityNotFound */
public function getEntityById(PositiveNaturalNumber $id): Entity {
    // DRY + secure :)
}

Ergo, I am not saying that union and intersection types are the solution
for all problems in this world. I am only saying that they have their
seldom special use cases. Please note, I am all in if we decide here to
not allow union and intersection and instead fix the type mixture in PHP
and add other features that allow us to create stricter types in
userland code. :)

Richard "Fleshgrinder" Fussenegger

10 years ago by Tom Worster — view source — reply

unread

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.

Reduce assertions*, enhance self-documentation, making code more robust,

I disagree here. I think our programs are more robust when programmers
avoid passing mixed types and write more simple code instead.

Hence I agree with Stas about the danger part. Union type hints are a
hazard. Adding them to PHP as a new feature is like saying "here's a
great new tool, pick it up and use it" but the tool is really a footgun.

Tom

10 years ago by Jordi Boggiano — view source — reply

unread

Heya,

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.

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

10 years ago by Christoph Becker — view source — reply

unread

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

There may not be very many cases for union types, but that might not
hinder some programmers to make extensive use of the feature, which
others may encounter in their APIs.

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.

It occurs to me that this is an instance of parameter overloading:
accept one of two (or more) unrelated types and handle them separately
in a single function. An alternative would be to have two (or more)
(factory) functions, each accepting one of the alternative types
(perhaps delegating to a common function for the common code, if necessary).

--
Christoph M. Becker

10 years ago by Andrea Faulds — view source — reply

unread

Hi Stas,

Stanislav Malyshev wrote:

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.

This is something that particularly concerns me about union types, in
that they reduce type safety. If you have a union type of Foo|Bar for
some variable, then the set of methods you can call on that variable is
actually the intersection, not the union, of the set of methods you can
call on Foo and Bar. Which, unless those two classes share some
interface, is probably an empty set. So there's nothing you can actually
do safely with it without doing checks within the body of the function,
and if you're doing that, then why do we have a type declaration? It's
only barely more useful than omitting a type declaration at all; type
declarations are supposed to prevent you needing to check. On the other
hand, if the two classes share some methods, then either there's an
interface you can already use here, or you can create one. Either way,
you don't need a union type.

There are some cases where you can't create an interface, but if that's
the case, I think it is more worthwhile to look at how we can fix those
cases, rather than add what amounts to a hacky workaround.

Thanks!

Andrea Faulds
https://ajf.me/

10 years ago by Levi Morrison — view source — reply

unread

This is something that particularly concerns me about union types, in that
they reduce type safety.

This is incorrect. Anyone using a union type now simply uses PHP's
dynamic type system. Going from no enforced type to restricting it to
N types does not in any circumstance reduce type safety.

10 years ago by Larry Garfield — view source — reply

unread

Hi Stas,

Stanislav Malyshev wrote:

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.

This is something that particularly concerns me about union types, in
that they reduce type safety. If you have a union type of Foo|Bar for
some variable, then the set of methods you can call on that variable
is actually the intersection, not the union, of the set of methods you
can call on Foo and Bar. Which, unless those two classes share some
interface, is probably an empty set. So there's nothing you can
actually do safely with it without doing checks within the body of the
function, and if you're doing that, then why do we have a type
declaration? It's only barely more useful than omitting a type
declaration at all; type declarations are supposed to prevent you
needing to check. On the other hand, if the two classes share some
methods, then either there's an interface you can already use here, or
you can create one. Either way, you don't need a union type.

There are some cases where you can't create an interface, but if
that's the case, I think it is more worthwhile to look at how we can
fix those cases, rather than add what amounts to a hacky workaround.

Thanks!

I think there's 2 general use cases for union types that would be "good
things", which are different for & and |, and have very little...
intersection. (yaaaaaaa!)

The OR case is for cases where the language doesn't support a unified
case at all. The most obvious example here is array|Traversable. If I
want "a thing I can foreach()", then PHP right now has no way of saying
that syntactically. You have to type on array, or Traversable, or not
type at all. array|Traversable is what you really want, because those
DO have an overlap (foreach-ablility), PHP is just incapable of
representing that otherwise.

A similar example would be callable|SomeInterface. An interface can
specify a signature for __invoke(), which gives you documentation on the
format that is expected for a callable. However, you can't strictly
enforce that because then you don't allow for a function or closure that
fits the same method signature. That means you have to leave it
untyped. This, I argue, would be better and reasonably type safe:

interface MiddlewareInterface {
function __invoke(RequestInterface $req, ResponseInterface $res);
}

function middleware_builder(callable|MiddlewareInterface $m) {
// ...
}

As that self-documents that MiddlewareInterface is the callable
signature we need, but still allows an arbitrary callable to be passed.
It's not perfect (I could pass a string of a function name that doesn't
have that interface and it would still explode), but it is an
improvement over middleware_builder() having no type specification at
all, as is the case today.

(Hat tip to Matthew O'Phinney for cueing me into this neat feature of
interfaces and __invoke().)

On the flipside, the & is mostly useful for where you need multiple
interfaces for something. For instance, there's the PSR-7
ResponseInterface. Drupal also has a number of interfaces for value
objects to indicate their cacheability metadata, such as
CacheableMetadataInterface. But that applies to more than just
Responses, of course, so having it extend ResponseInterface is not
good. So how can I specify that I need an object that is BOTH
ResponseInterface AND CacheableMetdataInterface? That's an entirely
reasonable thing to do, but currently PHP doesn't allow for it at all.
Even having a custom interface that extends both of those doesn't help,
because then my class needs to implement the child interface, not both
parents.

Being able to type on function foo(ResponseInterface &
CacheableMetadatInterface $r) seems entirely reasonable to me, and
definitely more type safe than leaving it untyped and relying on
documentation.

The danger zone is, as many people have noted, OR-ing interfaces
together. That does undermine type safety in most cases, I'd argue.
However, it's also rather obvious when it does so, because you end up
with a giant if-statement inside your function. So while it's a risk, I
don't think it's a subtle one, especially if well documented.

Actually, there is a use case for ORing interfaces, and that's for BC
reasons. Take, for instance, Symfony 2's routing system. It started
off with a RouteMatcherInterface::match(RequestContext $r) method, where
RequestContext is a "junior version" of a Request. After a while it
became evident that having the full for-reals Request object was useful,
so after prompting from Drupal they build an alternate version that used
a full Request, but overlaped in ugly ways with the original. Making
RequestContext extend Request (or vice versa) was completely impractical
for various reasons. However, as a BC transitional approach it would
have been reasonable to simply update the interface to
RouteMatcherInterface::(RequestContext|Request $r), as a signaling
mechanism that the old object still worked for a while, and despite
there not being a common type most of the methods are common between
those two objects. That would have allowed that service to fully
internalize the BC layer.

So while I agree there are risks to misuse of Class|Class type hints, I
think the overall benefits (detailed above) outweigh the risks. Even
then, hinting on A|B is better than hinting on nothing and still
accepting A or B. At least it's explicit that you're doing something risky.

--
--Larry Garfield

10 years ago by Christoph Becker — view source — reply

unread

I think there's 2 general use cases for union types that would be "good
things", which are different for & and |, and have very little...
intersection. (yaaaaaaa!)

The OR case is for cases where the language doesn't support a unified
case at all. The most obvious example here is array|Traversable. If I
want "a thing I can foreach()", then PHP right now has no way of saying
that syntactically. You have to type on array, or Traversable, or not
type at all. array|Traversable is what you really want,

It is not what I would want, though.

because those
DO have an overlap (foreach-ablility), PHP is just incapable of
representing that otherwise.

Maybe we should consider to accept an array as Traversable? Actually, I
wonder why that's not already the case.

A similar example would be callable|SomeInterface. An interface can
specify a signature for __invoke(), which gives you documentation on the
format that is expected for a callable. However, you can't strictly
enforce that because then you don't allow for a function or closure that
fits the same method signature. That means you have to leave it
untyped. This, I argue, would be better and reasonably type safe:

interface MiddlewareInterface {
function __invoke(RequestInterface $req, ResponseInterface $res);
}

function middleware_builder(callable|MiddlewareInterface $m) {
// ...
}

As that self-documents that MiddlewareInterface is the callable
signature we need, but still allows an arbitrary callable to be passed.
It's not perfect (I could pass a string of a function name that doesn't
have that interface and it would still explode), but it is an
improvement over middleware_builder() having no type specification at
all, as is the case today.

In my opinion, `callable' is to weak a type hint to be really useful,
and it would be better if we would improve that (generics come to mind).
Then you wouldn't need MiddlewareInterface at all and be not afraid
that somebody passes in an incompatible function.

--
Christoph M. Becker

10 years ago by Larry Garfield — view source — reply

unread

I think there's 2 general use cases for union types that would be "good
things", which are different for & and |, and have very little...
intersection. (yaaaaaaa!)

The OR case is for cases where the language doesn't support a unified
case at all. The most obvious example here is array|Traversable. If I
want "a thing I can foreach()", then PHP right now has no way of saying
that syntactically. You have to type on array, or Traversable, or not
type at all. array|Traversable is what you really want,
It is not what I would want, though.

because those
DO have an overlap (foreach-ablility), PHP is just incapable of
representing that otherwise.
Maybe we should consider to accept an array as Traversable? Actually, I
wonder why that's not already the case.

It's been asked a few dozen times, but never went anywhere. Mainly, I
think, Traversable implies object, which implies certain passing
semantics. Array is a primitive, so has different passing semantics.
There's probably other subtle issues like that which have kept the
engine-gurus from trying to make it work.

My assumption here is "if it were that easy someone would have done it
already". (Which may not be an entirely accurate assumption, but seems
logical given how often it's been asked for.)

A similar example would be callable|SomeInterface. An interface can
specify a signature for __invoke(), which gives you documentation on the
format that is expected for a callable. However, you can't strictly
enforce that because then you don't allow for a function or closure that
fits the same method signature. That means you have to leave it
untyped. This, I argue, would be better and reasonably type safe:

interface MiddlewareInterface {
function __invoke(RequestInterface $req, ResponseInterface $res);
}

function middleware_builder(callable|MiddlewareInterface $m) {
// ...
}

As that self-documents that MiddlewareInterface is the callable
signature we need, but still allows an arbitrary callable to be passed.
It's not perfect (I could pass a string of a function name that doesn't
have that interface and it would still explode), but it is an
improvement over middleware_builder() having no type specification at
all, as is the case today.
In my opinion, `callable' is to weak a type hint to be really useful,
and it would be better if we would improve that (generics come to mind).
Then you wouldn't need MiddlewareInterface at all and be not afraid
that somebody passes in an incompatible function.

One of the key language design points I think we should be keeping in
mind is that, on the whole, single-purpose features are inferior to more
general capabilities that implicitly grant the same capability. Thus,
I'd argue that the Property Accessor RFC is superior to adding a half
dozen keywords to object properties (because they implicitly grant all
of those same capabilities with less mental overhead and fewer keywords)
and Union Types are superior to special casing array|Traversable or
array|ArrayAccess, etc. (Making array a for-reals honest to goodness
object would be good too, but that's a considerably larger issue.)
Union Types side-step the need for more special cases, as they can be
handled in user-space code. It's not a perfect fix, but the perfect fix
involves very BC-unfriendly changes to PHP (making everything an object,
Go-style type aliases, etc.) that are not likely to happen any time soon.

Related: What would union types mean for the typed property RFC? Would
this be a good solution or an evil solution:

class Foo {
public array|Traversable $arr;
public Foo&Bar $c;
}

--
--Larry Garfield

10 years ago by Lin Yo-An — view source — reply

unread

I pretty much like the Haskell type system, it let you define types via the
syntax below:

data Tree a = Branch (Tree a) (Tree a) | Leaf a

But the type inference in Haskell can be resolved in the compile-time. We
can only verify the variable type for each function call in PHP.

10 years ago by Lin Yo-An — view source — reply

unread

If we can pre-define the types via something like this:

data Tree a = Branch (Tree a) (Tree a) | Leaf a

And only allow one type for each function parameter in the prototype, then,
I think the performance impact of type checking in the runtime can be
reduced.

In other words, you predefine the union type before you used them, and the
union types can be reused in different functions, you don't write a lot
union type in function prototype.

For example,

typedef T = array | Traversable

function foo(T $a) { }
function bar(T $b) { }

10 years ago by Bastian Schneider — view source — reply

unread

Just a quick thought. I would prefer something like

 union Iterable {
     use array;
     use ArrayAccess;
     use Traversable;
 }

 function bla(Iterable $iterable) {
     foreach($iterable as $element) {}
 }

Primitives like string, float, bool or int are not allowed in union.
Only classes, interfaces and array. I doesn't see any benefit in
combining string with int or int with float in one union.

Do I overlook or missed anything?

10 years ago by Ryan Pallas — view source — reply

unread

On Sat, Apr 16, 2016 at 4:10 AM, Bastian Schneider <
bastian.schneider@commerce-plus.com> wrote:

Just a quick thought. I would prefer something like
union Iterable {
    use array;
    use ArrayAccess;
    use Traversable;
}

function bla(Iterable $iterable) {
    foreach($iterable as $element) {}
}
Primitives like string, float, bool or int are not allowed in union. Only
classes, interfaces and array. I doesn't see any benefit in combining
string with int or int with float in one union.

Here's an example that shows combining scalar maybe useful:

union Numeric {
use int;
use float;
}

Something I would very much like to use where types are allowed.

Do I overlook or missed anything?

10 years ago by Davey Shafik — view source — reply

unread

On Sat, Apr 16, 2016 at 4:10 AM, Bastian Schneider <
bastian.schneider@commerce-plus.com> wrote:
Just a quick thought. I would prefer something like
union Iterable {
    use array;
    use ArrayAccess;
    use Traversable;
}

function bla(Iterable $iterable) {
    foreach($iterable as $element) {}
}
Primitives like string, float, bool or int are not allowed in union. Only
classes, interfaces and array. I doesn't see any benefit in combining
string with int or int with float in one union.
Here's an example that shows combining scalar maybe useful:

union Numeric {
use int;
use float;
}

Something I would very much like to use where types are allowed.

Could also be used for solving the issue of coercing:

union Numeric {
use int;
use float;
use string as float;
}

Thoughts?

Davey

10 years ago by Bastian Schneider — view source — reply

unread

Just a quick thought.

 union Iterable {
     use array;
     use ArrayAccess;
     use Traversable;
 }

 function bla(Iterable $iterable) {
     foreach($iterable as $element) {}
 }

Primitives like string, float, bool or int are not allowed in union.
Only classes, interfaces and array. I doesn't see any benefit in
combining string with int or int with float in one union.

Do I overlook or missed anything?

10 years ago by Zeev Suraski — view source — reply

unread

-----Original Message-----
From: Larry Garfield [mailto:larry@garfieldtech.com]
Sent: Friday, April 15, 2016 9:13 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Improving PHP's type system

I think there's 2 general use cases for union types that would be
"good things", which are different for & and |, and have very little...
intersection. (yaaaaaaa!)

The OR case is for cases where the language doesn't support a unified
case at all. The most obvious example here is array|Traversable. If
I want "a thing I can foreach()", then PHP right now has no way of
saying that syntactically. You have to type on array, or
Traversable, or not type at all. array|Traversable is what you
really want,
It is not what I would want, though.

because those
DO have an overlap (foreach-ablility), PHP is just incapable of
representing that otherwise.
Maybe we should consider to accept an array as Traversable? Actually,
I wonder why that's not already the case.

It's been asked a few dozen times, but never went anywhere. Mainly, I think,
Traversable implies object, which implies certain passing semantics. Array is
a primitive, so has different passing semantics.
There's probably other subtle issues like that which have kept the engine-
gurus from trying to make it work.

My assumption here is "if it were that easy someone would have done it
already". (Which may not be an entirely accurate assumption, but seems
logical given how often it's been asked for.)

A similar example would be callable|SomeInterface. An interface can
specify a signature for __invoke(), which gives you documentation on
the format that is expected for a callable. However, you can't
strictly enforce that because then you don't allow for a function or
closure that fits the same method signature. That means you have to
leave it untyped. This, I argue, would be better and reasonably type safe:

interface MiddlewareInterface {
function __invoke(RequestInterface $req, ResponseInterface $res);
}

function middleware_builder(callable|MiddlewareInterface $m) {
// ...
}

As that self-documents that MiddlewareInterface is the callable
signature we need, but still allows an arbitrary callable to be passed.
It's not perfect (I could pass a string of a function name that
doesn't have that interface and it would still explode), but it is an
improvement over middleware_builder() having no type specification at
all, as is the case today.
In my opinion, `callable' is to weak a type hint to be really useful,
and it would be better if we would improve that (generics come to mind).
Then you wouldn't need MiddlewareInterface at all and be not afraid
that somebody passes in an incompatible function.

One of the key language design points I think we should be keeping in mind is
that, on the whole, single-purpose features are inferior to more general
capabilities that implicitly grant the same capability.

It's a good rule-of-thumb, but I don't think it makes a lot of sense here.

Compared to the handful (or less) of situations where two different types of objects in fact have similar signatures, and like Christoph suggested - arguably, one should be considered a part of the other - in the vast majority of cases, lumping together two or more class types makes no sense. Unfortunately, I'm much less optimistic than you are about it not-being-used-because-it-makes-no-sense.

For uncommon but existent cases like the Symfony Request scenario you described, it's entirely reasonable to conduct the type check in userland code.

Creating a generic feature that makes sense in a handful of situations, while at the same time being one that's waiting-to-be-abused in the vast majority of the rest (or as Tom put it, a 'footgun') is a pretty poor bargain IMHO.

On the flipside, the & is mostly useful for where you need multiple interfaces
for something. For instance, there's the PSR-7 ResponseInterface. Drupal
also has a number of interfaces for value objects to indicate their cacheability
metadata, such as CacheableMetadataInterface. But that applies to more
than just Responses, of course, so having it extend ResponseInterface is not
good. So how can I specify that I need an object that is BOTH
ResponseInterface AND CacheableMetdataInterface? That's an entirely
reasonable thing to do, but currently PHP doesn't allow for it at all.
Even having a custom interface that extends both of those doesn't help,
because then my class needs to implement the child interface, not both
parents.

It could actually implement all of them - the two parents, and the child. That sounds like a pretty good, explicit way that requires no introduction of any new syntax, concepts or engine complexity in order to do what you're describing. This works fine:

interface foo { function foo(); }
interface bar { function bar(); }
interface baz extends foo,bar {}

class impl implements foo, bar, baz {
function foo(){}
function bar(){}
}

function sth(baz $b){}

One thing we could consider is adding some intelligence for these cases, and for interfaces that only extend other interfaces (without adding new signatures) - a class would be considered to implement that interface if it implements all of the 'parent' interfaces that the child interface extends:

class impl implements foo, bar {
function foo(){}
function bar(){}
}

function sth(baz $b){} <-- would work, as impl implements both foo and bar, and baz does nothing but extending those.

I'm not sure that's necessary, and believe the current mechanisms and syntax satisfy these use cases already, but it's probably a possibility.

Zeev

10 years ago by Fleshgrinder — view source — reply

unread

It could actually implement all of them - the two parents, and the child. That sounds like a pretty good, explicit way that requires no introduction of any new syntax, concepts or engine complexity in order to do what you're describing. This works fine:

interface foo { function foo(); }
interface bar { function bar(); }
interface baz extends foo,bar {}

class impl implements foo, bar, baz {
function foo(){}
function bar(){}
}

function sth(baz $b){}

class impl implements baz {} is actually already enough here because
baz extends foo and bar. This is the only way to solve such
situations right now but it does not help with primitive types. :(

One thing we could consider is adding some intelligence for these cases, and for interfaces that only extend other interfaces (without adding new signatures) - a class would be considered to implement that interface if it implements all of the 'parent' interfaces that the child interface extends:

class impl implements foo, bar {
function foo(){}
function bar(){}
}

function sth(baz $b){} <-- would work, as impl implements both foo and bar, and baz does nothing but extending those.

I'm not sure that's necessary, and believe the current mechanisms and syntax satisfy these use cases already, but it's probably a possibility.

That sounds like runtime checked duck typing. This actually makes the
type system less strict and might have horrific side effects and that is
exactly the opposite of what union/intersection types are meant for:
preventing this. Above code is the same as:

function sth($b) {
$b->foo();
$b->bar();
}

It will definitely fail if something else is passed in but if it is
foo, bar, or baz everything is fine. The problem is that any
object that satisfies the implementation of the methods foo and bar
would ultimately fulfill the contract here.

function sth(foo&bar $b) {}

This is a different situation because now we know that it is something
that actually implements exactly those two interfaces. Including
possible additional constraints like argument and return type hints.
There might even be a documentation shipped together with them that the
implementer should take care of honoring. The intersection type hint is
much stricter in such cases.

--
Richard "Fleshgrinder" Fussenegger

10 years ago by Zeev Suraski — view source — reply

unread

-----Original Message-----
From: Fleshgrinder [mailto:php@fleshgrinder.com]
Sent: Tuesday, April 19, 2016 8:33 PM
To: Zeev Suraski zeev@zend.com; Larry Garfield
larry@garfieldtech.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Improving PHP's type system

It could actually implement all of them - the two parents, and the child.
That sounds like a pretty good, explicit way that requires no
introduction of any new syntax, concepts or engine complexity in order
to do what you're describing. This works fine:

interface foo { function foo(); }
interface bar { function bar(); }
interface baz extends foo,bar {}

class impl implements foo, bar, baz {
function foo(){}
function bar(){}
}

function sth(baz $b){}

class impl implements baz {} is actually already enough here because
baz extends foo and bar.

Yes I know[1] - it was in the context of Larry's point.

This is the only way to solve such situations right now

And it's a good one!

but it does not help with primitive types. :(

Which is fine. Primitive types can and should get dedicated solutions. There's really no need for allowing over creativity with userland-customized scalar types.

One thing we could consider is adding some intelligence for these
cases, and
for interfaces that only extend other interfaces (without adding new
signatures) - a class would be considered to implement that interface
if it implements all of the 'parent' interfaces that the child interface extends:

class impl implements foo, bar {
function foo(){}
function bar(){}
}

function sth(baz $b){} <-- would work, as impl implements both foo and
bar, and baz does nothing but extending those.

I'm not sure that's necessary, and believe the current mechanisms
and
syntax satisfy these use cases already, but it's probably a possibility.

That sounds like runtime checked duck typing.
This actually makes the type
system less strict and might have horrific side effects and that is
exactly the opposite of what union/intersection types are meant for:

Not at all. I'm pretty sure you misunderstood what I meant.

preventing this. Above code is the same as:

function sth($b) {
$b->foo();
$b->bar();
}
[snip]

I believe you think I meant that instead of checking that $b's class actually implements foo and bar, we'd check whether $b has all of the methods needed by foo and bar - which means that theoretically means that it may have methods foo() and bar() but not actually 'officially' implement their respective interfaces. But there's no reason to do it this way and that's not what I meant.
Instead, with my proposal, a $b object whose class implements both foo and bar - will automatically be accepted as one that also implements baz. The checks will be conducted at the interface level, not the function list level. In other words, if $b doesn't explicitly implement baz, we'd take a look at 'baz', see it's comprised of foo & bar, and check whether $b's class implements them.

At this point, I can't imagine any negative side effect to automatically deducing that an object that implements foo and bar also implements baz (other than a small performance hit, probably roughly the same as the AND union type). Like I mentioned in my original post, I don't necessarily think it's needed - I personally see no reason not to add 'baz' to the list of interfaces impl implements, or as you said, replace foo and bar with baz altogether. In other words, the way I see I, PHP already supports AND union types through interfaces as it is.

Thanks,

Zeev

[1] bit.ly/1NkDmOA

10 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

Creating a generic feature that makes sense in a handful of
situations, while at the same time being one that's
waiting-to-be-abused in the vast majority of the rest (or as Tom put
it, a 'footgun') is a pretty poor bargain IMHO.

Completely agree with Zeev here.

It also seems to me that some measure of support for these features
comes from the "coolness factor" - look, ma, we have complex types, just
like those cool academic languages everybody is excited about! And I
don't deny the importance of language having some coolness factor and
getting people excited, but in this case I think it's a bit misplaced -
in PHP, I believe, most of the use for this feature would be to hide
lazy design and take shortcuts that should not be taken, instead of
developing robust and powerful type system.

Now, PHP's origins are not exactly in "powerful type system" world, so
it's fine if some people feel not comfortable with this rigidity and
having to declare tons of interfaces, and so on. This is fine. But
inserting shortcuts in the system to make it "strict, but not strict"
seems wrong to me.

--
Stas Malyshev
smalyshev@gmail.com

10 years ago by Larry Garfield — view source — reply

unread

Hi!

Creating a generic feature that makes sense in a handful of
situations, while at the same time being one that's
waiting-to-be-abused in the vast majority of the rest (or as Tom put
it, a 'footgun') is a pretty poor bargain IMHO.
Completely agree with Zeev here.

It also seems to me that some measure of support for these features
comes from the "coolness factor" - look, ma, we have complex types, just
like those cool academic languages everybody is excited about! And I
don't deny the importance of language having some coolness factor and
getting people excited, but in this case I think it's a bit misplaced -
in PHP, I believe, most of the use for this feature would be to hide
lazy design and take shortcuts that should not be taken, instead of
developing robust and powerful type system.

Now, PHP's origins are not exactly in "powerful type system" world, so
it's fine if some people feel not comfortable with this rigidity and
having to declare tons of interfaces, and so on. This is fine. But
inserting shortcuts in the system to make it "strict, but not strict"
seems wrong to me.

Can we please, please drop the "you only want it because it's cool"
strawman? A number of people are using it, and it's a flippant and
insulting ad hominem attack; from everyone using it. It's the same
thing as "PHP is not $other_language, therefore nothing from that
language is useful for PHP." Which is an utterly wrong and useless
argument to make. PHP's history has very clearly been one of borrowing
and stealing ideas from every language we can find if they fit and make
sense in PHP (and not if they don't).

Referencing other languages to support the inclusion of a feature is not
a coolness argument. It's a "solved problem, prior art exists"
argument. If a need is identified within PHP for a given feature, it is
both logical and expected to look for prior solutions to the same or
similar problems. That's the whole point of OSS. That doesn't make the
solution used by another language necessarily the right one, but it
should be considered a viable candidate.

Similarly, actual computer science (as opposed to the software
engineering most of us do) is developing real and meaningful new
solutions to problem spaces, which take years, often decades, to
percolate down into production languages. That doesn't mean proposing a
language feature informed by academia is just being hipster or elitist,
it means learning from and benefiting from the work of others. That's
the whole point of OSS.

True, the onus is on the proposer of any new language feature to justify
its inclusion. I completely agree with that. But rejecting a feature
suggestion with "you're just trying to look cool" is unhelpful,
unconstructive, and frankly harmful to the community and the language.

Remember:

'Programming languages teach you not to want what they don't provide.'
--https://twitter.com/compscifact/status/375283793923670016

That means PHP-centric developers are inherently inclined to not think a
a feature PHP has right now is useful. It's an entirely natural and
normal response to have. That doesn't make it right, or helpful.

--
--Larry Garfield

10 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

same thing as "PHP is not $other_language, therefore nothing from that
language is useful for PHP." Which is an utterly wrong and useless

No, it's not. Nobody claims nothing from other languages is useful in
PHP. What is claimed instead that not everything from other languages
is useful in PHP, and, for example, importing random high-order type
constructs from these languages without having extensive supporting
infrastructure that those languages have makes no sense. Or, for
example, importing arguments like "nulls are evil, let's replace nulls
with monadic types" into PHP make much less sense in PHP context then
they make in the context where they are made.

Referencing other languages to support the inclusion of a feature is not
a coolness argument. It's a "solved problem, prior art exists"

The problem is that this prior art exists in different context,
targeting different audience and having different styles, traditions,
capabilities and support system, and it is taken wholesale without
accounting for that.

argument. If a need is identified within PHP for a given feature, it is

Maybe my feeling is wrong, but I do have a feeling that recently "need
is identified" turned into "I can, if I think really hard, think of a
complex artificial example where this feature would provide a marginal
improvement". I would like a much higher barrier for "need is
identified" that that. For me, some of the proposals look like solution
is search of a problem. Maybe it's just because I do not understand the
actual need enough. In that case I'd like to see it shown more prominently.

I mean, for adding a function or a parameter to function - fine, almost
any use case will do, the more the merrier. But for overhauling whole
language's type system - I don't think so.

Similarly, actual computer science (as opposed to the software
engineering most of us do) is developing real and meaningful new
solutions to problem spaces, which take years, often decades, to
percolate down into production languages. That doesn't mean proposing a
language feature informed by academia is just being hipster or elitist,
it means learning from and benefiting from the work of others. That's
the whole point of OSS.

I do not object to being informed by academia, far from it. I object to
arguments "some folks from academia say X is a good thing, therefore we
must do X". Maybe X is a good thing for PHP, maybe it isn't - but
whichever way it is, it's not because somebody likes (or dislikes) it in
a completely unrelated context.

its inclusion. I completely agree with that. But rejecting a feature
suggestion with "you're just trying to look cool" is unhelpful,
unconstructive, and frankly harmful to the community and the language.

Nobody does that - that is not the reason for rejecting anything, it's
just a marginal side note. I just try to turn our attention to the fact
that not all cool features that exist in other languages can, or should
be, in PHP, even if they do look cool. And I try to share my worry that
some of the things being proposed include seriously complicating PHP's
conceptual model while serving at best infrequent use cases. Simplicity
is a virtue, and we have already lost significant amount of that virtue.
Maybe we gained more - I don't know yet, as most of our user base isn't
even on 5.5 by now. But it does worry me that we are not only losing it

we seem to be actively trying to get rid of it.

--
Stas Malyshev
smalyshev@gmail.com

10 years ago by Rick Widmer — view source — reply

unread

I try to share my worry that
some of the things being proposed include seriously complicating PHP's
conceptual model while serving at best infrequent use cases. Simplicity
is a virtue, and we have already lost significant amount of that virtue.
Maybe we gained more - I don't know yet, as most of our user base isn't
even on 5.5 by now. But it does worry me that we are not only losing it

we seem to be actively trying to get rid of it.

I just thought that needed to be repeated!

10 years ago by Zeev Suraski — view source — reply

unread

-----Original Message-----
From: Larry Garfield [mailto:larry@garfieldtech.com]
Sent: Tuesday, April 19, 2016 11:07 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Improving PHP's type system

strawman? A number of people are using it, and it's a flippant and insulting
ad hominem attack; from everyone using it.

While I agree that it can be insulting I do think that there's a certain degree of this happening (not necessarily in this thread or in any recent thread; I'm talking completely in general). It may not be productive to bring it up (because as you say, it can be insulting) - but given that I think that internals isn't free from it, I would hope that people will be encouraged to think hard on whether what they're proposing is truly needed, as opposed to just being useful.

It's the same thing as "PHP is not
$other_language, therefore nothing from that language is useful for PHP."

Larry, I don't believe that anybody has ever said anything of the sort on internals, ever (although I've been known to readily admit I'm senile). We never block a feature from PHP because it comes from a given language. However, when considering a new feature for PHP - a procedural, OO loosely-typed language, and not a functional or strongly typed one - bringing in features that make it more functional or more strongly typed, cannot be on the grounds that they exist in other languages. Of course they exist in other languages - there are many different types of languages, PHP cannot and should not try be all of them.

PHP's history has
very clearly been one of borrowing and stealing ideas from every language we
can find if they fit and make sense in PHP (and not if they don't).

I think that it's much more correct to say that PHP's history has been clearly one of borrowing and stealing ideas from C, Java and Perl, and not every language we can find. C, Java and Perl have some very strong commonalities, which is why creating a language that merged good stuff from all of them - plus adding more of our own - made sense and created a generally successful mix. But we never ever wanted, nor do we want right now, to borrow ideas from all of the languages in existence, even if they're good ideas. Good ideas exist in other languages, that don't fit PHP language characteristics.

Which again, does not mean that a feature that comes from a functional/academic language is inherently disqualified, and I do maintain to nobody is saying it; But when we come to evaluate whether it "fits and makes sense in PHP", than naturally, the likelihood that it does is inherently lower.

Referencing other languages to support the inclusion of a feature is not a
coolness argument. It's a "solved problem, prior art exists"
argument.

But it's a weak, almost trivial argument. It's still one that is relevant - but given that it's weak, people should not expect that by saying that "XYZ language has it", this constitutes a strong argument in its favor. If that XYZ language is from a very different language family, then as I mentioned above, it may be an indicator that it's not a very good fit for PHP. Again - not inherently disqualified - just 'raising questions'.

If a need is identified within PHP for a given feature, it is both
logical and expected to look for prior solutions to the same or similar
problems. That's the whole point of OSS. That doesn't make the solution
used by another language necessarily the right one, but it should be
considered a viable candidate.

The problem is, IMHO, that we're very, VERY flexible with the definition of the word 'need'.
There used to be a rule of thumb on internals that finding some use cases for a given language-level feature hardly constituted grounds to add it. It had to be useful on a very wide range of situations, in order to be worth the trouble of implementing it, maintaining it, but most of all - of adding complexity layers to the language (both in terms of cognitive burden and likelihood of misuse). Now, the whole 'complexity' factor is almost ignored. Focus is on finding a use case or a handful of use cases where the feature can be useful - a task which is almost always doable - especially when borrowing features from other languages.

Remember:

'Programming languages teach you not to want what they don't provide.'
--https://twitter.com/compscifact/status/375283793923670016

Is that inherently bad? It could be if it truly limits you, but if a language has a certain way of doing things, and not another - is it bad that it'd funnel you to do things its way?
Is it that bad that something that wants to use functional syntax, will not embrace PHP but something else? We don't have to be everything for everyone.

Regardless, at least as far as I can tell, it seems as if on internals, the sentiment is the 180 degrees opposite from Paul's statement. It's as if we feel PHP's syntax is never ever enough, and is in desperate need of extension - even though some amazingly advanced apps have been and are written on top of it. I'm not saying we should halt adding new syntax, but I am saying that (a) the pace at which we're discussing new syntax is mind boggling and way too fast, and (b) the bars we seem to be happy with in what constitutes 'need' are extremely low.

I would counter that statement with this one:
'Perfection is achieved not when there's nothing more to add, but when there is nothing left to take away'

IMHO, it would be AWESOME if we could funnel some of these cycles from new syntax and onto other things like parallel processing, async IO, JIT and more - which can truly take PHP to the next level. New syntax cannot.

Zeev

10 years ago by Levi Morrison — view source — reply

unread

IMHO, it would be AWESOME if we could funnel some of these cycles from new syntax and onto other things like parallel processing, async IO, JIT and more - which can truly take PHP to the next level. New syntax cannot.

The time investment for those projects is enormous. Not many
developers have the time or capability to add these things.

Furthermore, type system enhancements can have enormous impact.
Consider if generics landed in PHP 7.1. You had better believe that
would bring us to the "next level".

I agree that some of those things you mention would be great things.
Please do not reduce type system enhancements to mere syntax.

10 years ago by Zeev Suraski — view source — reply

unread

-----Original Message-----
From: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] On Behalf
Of Levi Morrison
Sent: Wednesday, April 20, 2016 12:23 AM
To: Zeev Suraski zeev@zend.com
Cc: Larry Garfield larry@garfieldtech.com; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Improving PHP's type system

IMHO, it would be AWESOME if we could funnel some of these cycles from
new syntax and onto other things like parallel processing, async IO, JIT and
more - which can truly take PHP to the next level. New syntax cannot.

The time investment for those projects is enormous. Not many developers
have the time or capability to add these things.

But that's what's needed, while new syntax is hardly needed. Few, if anybody, are saying that PHP's syntax is preventing them from doing what they need to do. The argument is always that the new syntax can be useful here or helpful there - which even if we accept as true, would make the rating of these features as 'nice to have', and not 'important' let alone 'must'. Not having them is not a barrier to adoption, nor is it pushing anybody away from PHP. Plus, there's this whole theory that less is more, and in its more relevant form - more is less. So arguably, the added complexity may even hamper adoption.

It's of course a lot easier to implement a patch to the engine to add some new syntax, but that's not what the language needs. There's no need to add new stuff to PHP every year especially not at the language level, and we seem to be obsessed with that. If people focused their efforts on things that can truly move the needle, even if it took a lot longer, it would eventually pay off. Instead, we're not even investing in them - because we're in a 'vicious' yearly cycle of adding new syntax.

Furthermore, type system enhancements can have enormous impact.
Consider if generics landed in PHP 7.1. You had better believe that would
bring us to the "next level".

I fail to see how adding C++ templates to PHP takes it to the next level in anything but the complexity scale. Not having them is not preventing anybody from doing anything today. Sure, a bunch of frameworks would adopt them once they become available - but it will not enable them to do things that are radically different from what they're doing today.

Please do not reduce type system enhancements to mere syntax.

For the most part, it is - as most sensible use cases have alternative solutions - either by different methods or by writing tiny bits of userland code.

Zeev

10 years ago by Marco Pivetta — view source — reply

unread

I fail to see how adding C++ templates to PHP takes it to the next level
in anything but the complexity scale. Not having them is not preventing
anybody from doing anything today. Sure, a bunch of frameworks would adopt
them once they become available - but it will not enable them to do things
that are radically different from what they're doing today.

And the fact that you fail to see it is why you don't see any advantages,
but that's because you are likely unfamiliar with most recent tooling
around static introspection.

Any reflector-based system, such as a serializer, an ORM or just a
dependency injection or configuration loader would be able to do operations
in a much more precise and less complex way.

In Doctrine ORM, having a way to know that a field or parameter is a
string | null or a int | float may be the difference between knowing
what kind of column definition is needed for a field at DB level, without
even need for defining manual mappings.

Having a configuration system that expects to call setters with specific
parameter types can allow the configuration system to validate the given
data upfront, providing meaningful exceptions to the user, without having
to write an entire separate config specification.

Having a serializer that expects certain types of data allows rejecting any
kind of value that is possibly insecure, and would cause a RCE
vulnerability by unserializing a value into something with a malicious
__wakeup in it.

Etc etc.

In general, improving the type system provides a much more interesting and
practical playground for any kind of tool that would rely on static
introspection: IDEs, reflectors, code generators, code inliners,
documentation generators.

The runtime part of this is just a tiny fraction of what is interesting
about improving the type system at all.

Hope that gives some useful context, in order to see where this would
actually be useful.

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

10 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

Any reflector-based system, such as a serializer, an ORM or just a
dependency injection or configuration loader would be able to do operations
in a much more precise and less complex way.

This should be solved by annotations. Yes, I know all the story, but it
does not change the fact that ORM serialization is not the same as
internal PHP typing, and arguing we need to change PHP typing system
because it makes it easier for (a particular) ORM serializer is putting
the cart in front of the horse.

Having a configuration system that expects to call setters with specific
parameter types can allow the configuration system to validate the given
data upfront, providing meaningful exceptions to the user, without having
to write an entire separate config specification.

We already have system that provides meaningful exceptions to the user.
It's called PHP engine. The system you describe changes nothing but
wording of error messages. This is not really worth changing the typing
system in PHP.

Having a serializer that expects certain types of data allows rejecting any
kind of value that is possibly insecure, and would cause a RCE
vulnerability by unserializing a value into something with a malicious
__wakeup in it.

All examples of unserialize problems so far were in the engine and those
examples have all the types already known, the problem was/is
unserializer has no way to use this information. This problem is not
solved by adding more syntax.

In general, improving the type system provides a much more interesting and
practical playground for any kind of tool that would rely on static

That's my point - "more interesting playground" does not sound like a
reason enough to mess with the type system of the language used by
millions. This sounds like a good description of a thesis project or a
academic proof-of-concept language, not something mature widely-used
language prizing simplicity should be aiming for. I completely agree
that if we added a ton of shiny things into PHP then there would be a
lot of interesting stuff to play with. I am saying that is not the
reason enough to actually add them.

Stas Malyshev
smalyshev@gmail.com

10 years ago by Rick Widmer — view source — reply

unread

In general, improving the type system provides a much more interesting and
practical playground for any kind of tool that would rely on static

That's my point - "more interesting playground" does not sound like a
reason enough to mess with the type system of the language used by
millions. This sounds like a good description of a thesis project or a
academic proof-of-concept language, not something mature widely-used
language prizing simplicity should be aiming for. I completely agree
that if we added a ton of shiny things into PHP then there would be a
lot of interesting stuff to play with. I am saying that is not the
reason enough to actually add them.

Are too many of these incompatible shiny things, too fast, the main
reason so many PHP users are on older versions?

IMHO, yes.

Rick

10 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

Are too many of these incompatible shiny things, too fast, the main
reason so many PHP users are on older versions?

Probably not directly. The reason is PHP 5, as is, is pretty darn good
tool for what it is being used for. Of course, it could be 10x faster,
it could have more extensions and it could have multithreading and
native Unicode support ;) But even as is, it's not bad and allows to do
a lot. So people do not feel a burning need to jump to a new version
yet, let alone learn new concepts and develop new frameworks based on
these concepts. It doesn't mean what we have added in PHP 7 is bad - but
it'll probably take some time until people start really using it.

Stas Malyshev
smalyshev@gmail.com

10 years ago by johannes@schlueters.de — view source — reply

unread

Are too many of these incompatible shiny things, too fast, the main
reason so many PHP users are on older versions?

There are many reasons. Often the reason is simply that many cheap
hosting companies or admins don't want to spend time to update. For them
this is only a cost. And there are no game changers which create
pressure. All major applications work on "old" versions and for the
individual developer it is hard to argue "oh, I want to use the <=>
operator" as the work-around is trivial.

Hosters had to offer 5 quite quickly since that was a big game changer
with the new object model.

johannes

10 years ago by Tom Worster — view source — reply

unread

Are too many of these incompatible shiny things, too fast, the main
reason so many PHP users are on older versions?

IMHO, yes.

This would mean, by an large, that people had tried a more recent
version of PHP and found that their code was incompatible. I think on
the contrary that they haven't tried because they have little motive. A
lot of running apps are in maintenance mode with no significant
investments in new code, without which it's easier to take the attitude
that it's not broken so don't mess around with it.

Tom

10 years ago by Zeev Suraski — view source — reply

unread

-----Original Message-----
From: Tom Worster [mailto:fsb@thefsb.org]
Sent: Wednesday, April 20, 2016 4:24 PM
To: Rick Widmer vchkpw@developersdesk.com; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Improving PHP's type system

Are too many of these incompatible shiny things, too fast, the main
reason so many PHP users are on older versions?

IMHO, yes.

This would mean, by an large, that people had tried a more recent version of
PHP and found that their code was incompatible. I think on the contrary that
they haven't tried because they have little motive. A lot of running apps are in
maintenance mode with no significant investments in new code, without
which it's easier to take the attitude that it's not broken so don't mess around
with it.

It's more complicated than that - people don't actually have to try and upgrade in order to know (or think they know) that they'll have to invest time and efforts in getting their code to run on a new version. They guess as much.

That said, I don't think the issue with shiny new things is that they introduce incompatibilities. They rarely do - I think the biggest source of incompatibilities we have is removal of deprecated features and not introduction of new ones. Shiny new features have other issues - increased cognitive burden, increased code complexity, etc. - but typically introduction of incompatibilities is not one of them.

However, we can learn that the attractiveness of new features in PHP is not very high - or we'd see much faster adoption of new versions (which also leads me to believe that we're spending too much effort on the wrong things). I think we're going to see much faster adoption of 7.0 - but in my experience at least, it's predominantly the increased performance and reduced memory consumption that gets people excited - the new features are secondary if they play any role at the decision.

Zeev

10 years ago by Ronald Chmara — view source — reply

unread

In general, improving the type system provides a much more interesting and
practical playground for any kind of tool that would rely on static
introspection: IDEs, reflectors, code generators, code inliners,

So, tooling that relies upon (more) strict typing is less useful for
for PHP, therefore, rather than change the tooling to be more capable
with looser typing, change PHP?

-Ronabop

10 years ago by Marco Pivetta — view source — reply

unread

In general, improving the type system provides a much more interesting
and
practical playground for any kind of tool that would rely on static
introspection: IDEs, reflectors, code generators, code inliners,

So, tooling that relies upon (more) strict typing is less useful for
for PHP, therefore, rather than change the tooling to be more capable
with looser typing, change PHP?

The tooling already works with annotations, but there is no actual "safety"
introduced by these hacks.

This sounds like a good description of a thesis project or a

academic proof-of-concept language, not something mature widely-used
language prizing simplicity should be aiming for.

So the Symfony2 routing and Doctrine ORM are academic proof of concepts?
We got to the point of inventing language features by building hacks around
the engine (Levi and I had a heated discussion about it) due to practical
necessity, not due to technical/academic onanism.
Removing the hacks and replacing them with actual language features would
be the way to go here, but let's just keep assuming that wordpress is the
baseline for good software in 2016.

I think I'm just going to mute the thread.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

10 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

So the Symfony2 routing and Doctrine ORM are academic proof of concepts?

I'm sorry I'm a bit lost about how you got from "prioritizing
'interesting playground' is more suited for academic PoC than for a
mature language" to "Doctrine ORM is an academic PoC". I have little
knowledge on what Doctrine ORM implementation is, but I'm pretty sure
deep technical details of Doctrine ORM should not be primary driver in
designing PHP's type system. There's a lot of ways to write ORM, and I'm
sure Doctrine developers are smart enough to do what is necessary. If
there's some generic lesson they can give us that would serve everybody

let's hear it then.

We got to the point of inventing language features by building hacks around
the engine (Levi and I had a heated discussion about it) due to practical
necessity, not due to technical/academic onanism.

I appreciate that your specific use case requires certain things. I even
think there is a good concept for these things, if I understand them
right - namely, annotations - and those are used in many other
environments (see? I'm not afraid to quote other languages where it is
appropriate! ;) What I am questioning is that wiring those things into
PHP type system is the right move.

Removing the hacks and replacing them with actual language features would
be the way to go here, but let's just keep assuming that wordpress is the
baseline for good software in 2016.

I have little idea what you referring to here, but I assume you think
wordpress is actually bad software, though I am still a bit lost as to
how it connects to the rest of the discussion.

There are a lot of additions that may improve PHP in many practical
ways. I just think right now there's a bit too much focus on adding new
syntax that adds much more complexity than it's worth. I'm not against
adding new syntax per se, I guess I just want more necessary
capabilities enabled per complexity added ratio.

Stas Malyshev
smalyshev@gmail.com

10 years ago by johannes@schlueters.de — view source — reply

unread

In Doctrine ORM, having a way to know that a field or parameter is a
string | null or a int | float may be the difference between
knowing
what kind of column definition is needed for a field at DB level,
without
even need for defining manual mappings.

So what's the column definition if you see string | null? A PHP string
can have (almost) arbitrary length and binary data, so this is a BLOB?
Most likely not what the user wants.

The PHP type hardly describes the constraints by the application. This
might add a small sanity check but by no means a game changer.

johannes

10 years ago by Lester Caine — view source — reply

unread

In Doctrine ORM, having a way to know that a field or parameter is a
string | null or a int | float may be the difference between
knowing
what kind of column definition is needed for a field at DB level,
without
even need for defining manual mappings.
So what's the column definition if you see string | null? A PHP string
can have (almost) arbitrary length and binary data, so this is a BLOB?
Most likely not what the user wants.

The PHP type hardly describes the constraints by the application. This
might add a small sanity check but by no means a game changer.

String length, size of integer and accuracy of numeric all affect the
definition of the schema at the DB level which adding a little twiddly
bit does nothing to provide an expandable type definition. I'm not
objecting to a type system per-say but even the bits that have been
bodged into PHP7 already do not provide a route forward for REAL data
validation?

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

10 years ago by Lin Yo-An — view source — reply

unread

Andrea Faulds ajf@ajf.me 於 2016年4月15日星期五寫道：

This is something that particularly concerns me about union types, in that
they reduce type safety. If you have a union type of Foo|Bar for some
variable, then the set of methods you can call on that variable is actually
the intersection, not the union, of the set of methods you can call on Foo
and Bar. Which, unless those two classes share some interface, is probably
an empty set. So there's nothing you can actually do safely with it without
doing checks within the body of the function, and if you're doing that,
then why do we have a type declaration? It's only barely more useful than
omitting a type declaration at all; type declarations are supposed to
prevent you needing to check. On the other hand, if the two classes share
some methods, then either there's an interface you can already use here, or
you can create one. Either way, you don't need a union type.

+1 I agree. Language like Golang use interface to intersect the method
calls, I think that's better.

--

--
Sent from Gmail Mobile

10 years ago by Larry Garfield — view source — reply

unread

Andrea Faulds ajf@ajf.me 於 2016年4月15日星期五寫道：

This is something that particularly concerns me about union types, in that
they reduce type safety. If you have a union type of Foo|Bar for some
variable, then the set of methods you can call on that variable is actually
the intersection, not the union, of the set of methods you can call on Foo
and Bar. Which, unless those two classes share some interface, is probably
an empty set. So there's nothing you can actually do safely with it without
doing checks within the body of the function, and if you're doing that,
then why do we have a type declaration? It's only barely more useful than
omitting a type declaration at all; type declarations are supposed to
prevent you needing to check. On the other hand, if the two classes share
some methods, then either there's an interface you can already use here, or
you can create one. Either way, you don't need a union type.
+1 I agree. Language like Golang use interface to intersect the method
calls, I think that's better.

Go's interfaces are implicit rather than explicit. That's what makes
micro-interfaces like that (which are often single-method) feasible.
Anthony Ferrara proposed "weak interfaces" a few years ago but it was
rejected (or didn't make it to a vote; I don't recall which).

Either way, Foo|Bar is not the main use case for union types. See my
earlier email.

--
--Larry Garfield

10 years ago by Jesse Schalken — view source — reply

unread

Without type annotations:

function foo($b) {

if (!is_string($b)) {

// Ugh, why can't the language enforce this?

throw new Exception("needed a string");

}

With type annotations:

function foo(string $b) {

// I know $b is a string. I don't need to check. :)

}

Without unions:

function foo($b) {
if (is_string($b)) {
// ...
} else if ($b instanceof Bar) {
// ...

} else {

// Ugh, why can't the language enforce this?

    throw new Exception("needed a string|Bar");

}

}

With unions:

function foo(Bar|string $b) {

if (is_string($b)) {
    // ...
} else {
    // I know $b is a Bar here. I don't need to check. :)
}

}

In both cases, the type annotation has removed the 1 check and the need to
throw an exception. It's the exact same benefit.

Hi Stas,

Stanislav Malyshev wrote:

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.

This is something that particularly concerns me about union types, in that
they reduce type safety. If you have a union type of Foo|Bar for some
variable, then the set of methods you can call on that variable is actually
the intersection, not the union, of the set of methods you can call on Foo
and Bar. Which, unless those two classes share some interface, is probably
an empty set. So there's nothing you can actually do safely with it without
doing checks within the body of the function, and if you're doing that,
then why do we have a type declaration? It's only barely more useful than
omitting a type declaration at all; type declarations are supposed to
prevent you needing to check. On the other hand, if the two classes share
some methods, then either there's an interface you can already use here, or
you can create one. Either way, you don't need a union type.

There are some cases where you can't create an interface, but if that's
the case, I think it is more worthwhile to look at how we can fix those
cases, rather than add what amounts to a hacky workaround.

Thanks!

Andrea Faulds
https://ajf.me/

10 years ago by johannes@schlueters.de — view source — reply

unread

With unions:

function foo(Bar|string $b) {

if (is_string($b)) {
    // ...
} else {
    // I know $b is a Bar here. I don't need to check. :)
}

}

I' still missing a real-life use case for this. There's no operation I
can come up with which works with an object or string.

Unions between object types should be handled via interface.

The only relevant union types I found till now are

array | Traversable
array | Countable

and eventually

array | Offset[Get|Set]

The last one is a bit critical due to the fact that arrays are value
types, whereas objects are reference types so

function ($a) {
$a[] = 42;
}

behaves notably differently between objects and arrays. So that case
might need some thinking. For the others instead of a generic union type
I'd prefer a special array-solution.

johannes

10 years ago by Jesse Schalken — view source — reply

unread

I have a function that converts values to SQL which have SQL
equivalents, including decimal values represented by a special Decimal
class. It accepts int|string|bool|null|float|Decimal.
I have a class Expr which represents an expression in SQL.
Expressions can be composed of other expressions, and of literal values, so
the constructors for Exprs accept int|string|bool|null|float|Decimal|Expr.
I have a function that converts values to JSON that can be reliably
converted back into their original. It accepts int|string|bool|null|float.
I have a function that returns the first key in an array (or throws
an exception if empty). It returns int|string.
I have a function that returns a value for a key in an array, and
removes the key. The type of the key is things that are valid array keys
(int|string|bool|null IIRC).
I have a set of functions which operates on numbers. They accept
int|float.
All the PHP functions which say "returns ... or FALSE on failure"
have their correct return type as T|false (where T is the return value on
success) (or T|bool is "false" is not an allowed type).
Nullability is nothing but a special case of union type with T|null.

If you need more examples, search some PHP codebases for PHPDoc blocks with
union types with a regex, like "@(param|var)\s*($\w+\s*)?\w+|".

On Wed, Apr 20, 2016 at 7:46 PM, Johannes Schlüter johannes@schlueters.de
wrote:

With unions:

function foo(Bar|string $b) {
if (is_string($b)) {
    // ...
} else {
    // I know $b is a Bar here. I don't need to check. :)
}
}
I' still missing a real-life use case for this. There's no operation I
can come up with which works with an object or string.

Unions between object types should be handled via interface.

The only relevant union types I found till now are

array | Traversable
array | Countable

and eventually

array | Offset[Get|Set]

The last one is a bit critical due to the fact that arrays are value
types, whereas objects are reference types so

function ($a) {
$a[] = 42;
}

behaves notably differently between objects and arrays. So that case
might need some thinking. For the others instead of a generic union type
I'd prefer a special array-solution.

johannes

10 years ago by Zeev Suraski — view source — reply

unread

-----Original Message-----
From: jesseschalken@gmail.com [mailto:jesseschalken@gmail.com] On
Behalf Of Jesse Schalken
Sent: Wednesday, April 20, 2016 1:12 PM
To: Johannes Schlüter johannes@schlueters.de
Cc: Andrea Faulds ajf@ajf.me; PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Improving PHP's type system

I have a function that converts values to SQL which have SQL
equivalents, including decimal values represented by a special Decimal
class. It accepts int|string|bool|null|float|Decimal.

I have a class Expr which represents an expression in SQL.
Expressions can be composed of other expressions, and of literal values, so
the constructors for Exprs accept int|string|bool|null|float|Decimal|Expr.

I have a function that converts values to JSON that can be reliably
converted back into their original. It accepts int|string|bool|null|float.

In other words, they accepts scalars (or nullable scalars). Introducing a scalar type would do the job.

I have a function that returns the first key in an array (or throws
an exception if empty). It returns int|string.

I'd argue that here too, a scalar would be fine. Worrying about a floating point here is not a very relevant worry.

I have a function that returns a value for a key in an array, and
removes the key. The type of the key is things that are valid array keys
(int|string|bool|null IIRC).

Scalar (or nullable scalar).

I have a set of functions which operates on numbers. They accept
int|float.

Numeric (to also include strings that look like numbers when strict is not on).

All the PHP functions which say "returns ... or FALSE on failure"
have their correct return type as T|false (where T is the return value on
success) (or T|bool is "false" is not an allowed type).

How many of those do we have? As opposed to T|null? I think most functions that return objects return null on failure, not false. And those who don't can probably evolve to that approach.

Nullability is nothing but a special case of union type with T|null.

Academically that's true, but practically speaking, the general T1|T2 is almost always bogus while T|null subset makes a lot of sense.

In reality, we can solve all the relevant use cases for union types by relatively minor tweaks (or rather additions) to our scalar type hints, by adding nullability, and by using interfaces where they make sense.

Zeev

10 years ago by Jesse Schalken — view source — reply

unread

If I had "scalar", "number" and ?T as types, the types I would need would
be:

?scalar|Decimal
?scalar|Decimal|Expr
?scalar|array
int|string (I want int|string here. I know array keys are always
int|string. A wider type is lies.)
?scalar (probably)
number
T|false
?T

5 out of 8 still need a union.

-----Original Message-----
From: jesseschalken@gmail.com [mailto:jesseschalken@gmail.com] On
Behalf Of Jesse Schalken
Sent: Wednesday, April 20, 2016 1:12 PM
To: Johannes Schlüter johannes@schlueters.de
Cc: Andrea Faulds ajf@ajf.me; PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Improving PHP's type system

I have a function that converts values to SQL which have SQL
equivalents, including decimal values represented by a special Decimal
class. It accepts int|string|bool|null|float|Decimal.

I have a class Expr which represents an expression in SQL.
Expressions can be composed of other expressions, and of literal
values, so
the constructors for Exprs accept
int|string|bool|null|float|Decimal|Expr.

I have a function that converts values to JSON that can be reliably
converted back into their original. It accepts
int|string|bool|null|float.

In other words, they accepts scalars (or nullable scalars). Introducing a
scalar type would do the job.

I have a function that returns the first key in an array (or throws
an exception if empty). It returns int|string.

I'd argue that here too, a scalar would be fine. Worrying about a
floating point here is not a very relevant worry.

I have a function that returns a value for a key in an array, and
removes the key. The type of the key is things that are valid array
keys
(int|string|bool|null IIRC).

Scalar (or nullable scalar).

I have a set of functions which operates on numbers. They accept
int|float.

Numeric (to also include strings that look like numbers when strict is not
on).

All the PHP functions which say "returns ... or FALSE on failure"
have their correct return type as T|false (where T is the return
value on
success) (or T|bool is "false" is not an allowed type).

How many of those do we have? As opposed to T|null? I think most
functions that return objects return null on failure, not false. And those
who don't can probably evolve to that approach.

Nullability is nothing but a special case of union type with
T|null.

Academically that's true, but practically speaking, the general T1|T2 is
almost always bogus while T|null subset makes a lot of sense.

In reality, we can solve all the relevant use cases for union types by
relatively minor tweaks (or rather additions) to our scalar type hints, by
adding nullability, and by using interfaces where they make sense.

Zeev

10 years ago by Jesse Schalken — view source — reply

unread

On Wed, Apr 20, 2016 at 9:54 PM, Jesse Schalken me@jesseschalken.com
wrote:

If I had "scalar", "number" and ?T as types, the types I would need would
be:

?scalar|Decimal

?scalar|Decimal|Expr

?scalar|array

int|string (I want int|string here. I know array keys are always
int|string. A wider type is lies.)

?scalar (probably)

number

T|false

?T

5 out of 8 still need a union.

-----Original Message-----
From: jesseschalken@gmail.com [mailto:jesseschalken@gmail.com] On
Behalf Of Jesse Schalken
Sent: Wednesday, April 20, 2016 1:12 PM
To: Johannes Schlüter johannes@schlueters.de
Cc: Andrea Faulds ajf@ajf.me; PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Improving PHP's type system

I have a function that converts values to SQL which have SQL
equivalents, including decimal values represented by a special
Decimal
class. It accepts int|string|bool|null|float|Decimal.

I have a class Expr which represents an expression in SQL.
Expressions can be composed of other expressions, and of literal
values, so
the constructors for Exprs accept
int|string|bool|null|float|Decimal|Expr.

I have a function that converts values to JSON that can be
reliably
converted back into their original. It accepts
int|string|bool|null|float.

In other words, they accepts scalars (or nullable scalars). Introducing
a scalar type would do the job.

I have a function that returns the first key in an array (or
throws
an exception if empty). It returns int|string.

I'd argue that here too, a scalar would be fine. Worrying about a
floating point here is not a very relevant worry.

I have a function that returns a value for a key in an array, and
removes the key. The type of the key is things that are valid array
keys
(int|string|bool|null IIRC).

Scalar (or nullable scalar).

I have a set of functions which operates on numbers. They accept
int|float.

Numeric (to also include strings that look like numbers when strict is
not on).

All the PHP functions which say "returns ... or FALSE on failure"
have their correct return type as T|false (where T is the return
value on
success) (or T|bool is "false" is not an allowed type).

How many of those do we have? As opposed to T|null? I think most
functions that return objects return null on failure, not false. And those
who don't can probably evolve to that approach.

Nullability is nothing but a special case of union type with
T|null.

Academically that's true, but practically speaking, the general T1|T2 is
almost always bogus while T|null subset makes a lot of sense.

In reality, we can solve all the relevant use cases for union types by
relatively minor tweaks (or rather additions) to our scalar type hints, by
adding nullability, and by using interfaces where they make sense.

Zeev

10 years ago by Jesse Schalken — view source — reply

unread

On Thu, Apr 14, 2016 at 10:47 PM, Lin Yo-An cornelius.howl@gmail.com
wrote:

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.

Last I checked, the HHVM JIT treats PHP and Hack code roughly identically
and doesn't use the Hack type annotations for any optimisation. It's is
really just another dynamic language JIT, like V8 and Chakra.

The purpose of type annotations and type checkers for dynamic languages,
including Hack, TypeScript and Flow, is not necessarily to improve
performance but to improve developer efficiency. Wherever there exists a
type annotation which is enforced, either statically or at runtime, the
developer has gained important knowledge to inform the modification of the
program, and can do so with increased certainty and predictability.

10 years ago by johannes@schlueters.de — view source — reply

unread

On Thu, Apr 14, 2016 at 10:47 PM, Lin Yo-An cornelius.howl@gmail.com
wrote:

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.

Last I checked, the HHVM JIT treats PHP and Hack code roughly identically
and doesn't use the Hack type annotations for any optimisation. It's is
really just another dynamic language JIT, like V8 and Chakra.

The purpose of type annotations and type checkers for dynamic languages,
including Hack, TypeScript and Flow, is not necessarily to improve
performance but to improve developer efficiency. Wherever there exists a
type annotation which is enforced, either statically or at runtime, the
developer has gained important knowledge to inform the modification of the
program, and can do so with increased certainty and predictability.

For that there is some research:

    How many bugs does static type checking catch?
    [...]
    answer: 2%.
    [...]
    not only were development times significantly shorter on average
    with dynamically typed languages, so were debug times.
    
    So all those nasty type errors were actually not having any
    negative impact on debug times, in fact the reverse was true.
    
    http://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html

johannes

10 years ago by Lester Caine — view source — reply

unread

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

10 years ago by Levi Morrison — view source — reply

unread

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.

10 years ago by Tony Marston — view source — reply

unread

"Levi Morrison" wrote in message
news:CAFMT4Nr4GmnBBsOfydF5sLOtaEo1rZZiPdGdV8v6y+Z-6PVCOg@mail.gmail.com...

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.

If millions of programmers have written millions of lines of code to write
effective programs WITHOUT the use of type hinting/enforcement, then how
come there are some people out there who keep saying that PHP is a bad
language because it does not have type checking? Those who cannot write
effective software without these "clever" additions to the language are
doing nothing but announcing to the world that they are not clever enough to
write effective software using their own limited abilities.

--
Tony Marston

10 years ago by Marco Pivetta — view source — reply

unread

Tony, that sounds really like "real programmers use dd -if -of". Please
stop with that argument, as it really doesn't reflect reality. I keep
enhancing my software with new (stricter) type checking, when available.
For example, I'm eager to replace current docblocks declaring void
methods with the upcoming hint (7.1), and every time I add hints and type
strictness I find new hidden bugs on an already well-tested code (with 100%
coverage and mutation testing). These bugs are legit, they are just waiting
to happen.

Additionally, I would also love to get rid of docblocks for type-systems:
they are unreliable, hard to reflect and enforce nothing, which allows lazy
and sloppy programmers to just circumvent specifications as it best pleases
their mood, rather than the requirements.

Yes, I'm a real programmer too, and no, I don't use cosmic rays to write
code to my computer's hard drive, give it a rest.

"Levi Morrison" wrote in message
news:CAFMT4Nr4GmnBBsOfydF5sLOtaEo1rZZiPdGdV8v6y+Z-6PVCOg@mail.gmail.com...

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.

If millions of programmers have written millions of lines of code to write
effective programs WITHOUT the use of type hinting/enforcement, then how
come there are some people out there who keep saying that PHP is a bad
language because it does not have type checking? Those who cannot write
effective software without these "clever" additions to the language are
doing nothing but announcing to the world that they are not clever enough
to write effective software using their own limited abilities.

--
Tony Marston

10 years ago by Tony Marston — view source — reply

unread

"Marco Pivetta" wrote in message
news:CADyq6sJfPYgQvhQt=UvCBqkooJjoUPCz1sUfzwXc+55hL0PpzA@mail.gmail.com...

Tony, that sounds really like "real programmers use dd -if -of". Please
stop with that argument, as it really doesn't reflect reality.

That is not what I said. As a follower of the KISS principle I believe that
good programmers write simple code that anyone can understand, while
less-than-good programmers write complex code that only a select few can
understand.

The problem with adding all these new and shiny features to the language is
that it makes the language more complicated, especially when it comes to all
those edge cases which keep arising. Changes like this are making the
language more complicated by getting it to do in core what used to be done
in userland code. All that is happening is that it becomes more complicated
to update the language for genuine improvements which would be appreciated
by the masses instead of these over-complications which are only for the
benefit of the few who think programming should be restricted to those who
have Phd's.

I keep
enhancing my software with new (stricter) type checking, when available.
For example, I'm eager to replace current docblocks declaring void
methods with the upcoming hint (7.1), and every time I add hints and type
strictness I find new hidden bugs on an already well-tested code (with 100%
coverage and mutation testing). These bugs are legit, they are just waiting
to happen.

That just proves that your unit testing did not in fact have 100% coverage.
If a potential bug hasn't been encountered by a real user then it doesn't
actually cause a problem, and if it doesn't cause a problem then why does it
need a solution? Even Microsoft, the largest software company in the world,
does not attempt to fix every possible bug only those bugs which cause
problems.

Additionally, I would also love to get rid of docblocks for type-systems:
they are unreliable, hard to reflect and enforce nothing, which allows lazy
and sloppy programmers to just circumvent specifications as it best pleases
their mood, rather than the requirements.

Yes, I'm a real programmer too, and no, I don't use cosmic rays to write
code to my computer's hard drive, give it a rest.

"Levi Morrison" wrote in message
news:CAFMT4Nr4GmnBBsOfydF5sLOtaEo1rZZiPdGdV8v6y+Z-6PVCOg@mail.gmail.com...

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.

If millions of programmers have written millions of lines of code to
write
effective programs WITHOUT the use of type hinting/enforcement, then how
come there are some people out there who keep saying that PHP is a bad
language because it does not have type checking? Those who cannot write
effective software without these "clever" additions to the language are
doing nothing but announcing to the world that they are not clever enough
to write effective software using their own limited abilities.

--
Tony Marston

--

--
Tony Marston

10 years ago by Tom Worster — view source — reply

unread

"Marco Pivetta" wrote in message
news:CADyq6sJfPYgQvhQt=UvCBqkooJjoUPCz1sUfzwXc+55hL0PpzA@mail.gmail.com...

Tony, that sounds really like "real programmers use dd -if -of". Please
stop with that argument, as it really doesn't reflect reality.

That is not what I said. As a follower of the KISS principle I believe
that good programmers write simple code that anyone can understand,
while less-than-good programmers write complex code that only a select
few can understand.

...or perhaps nobody can understand. Agreed. So I guess that makes me
a follower of the KISS principle too. I prefer boring, obvious,
conventional code and the kind of strict style guides that artisan codes
hate. I'm also conservative wrt changing PHP -- a gradualist. And I
dislike arguments proposing feature X because such-and-such more
fashionable language has it.

That said...

I have found that my programs, my team's and the libs I use are more
obvious, boring and easy to understand when they are clear about type.

So in recent years I've tried to be more and more rigorous in using
PHPdoc2 type tags, the IDE's linters to run static checks, and working
towards eliminating using "mixed" and "|" in the type spec.

PHP 7.0's type is better than relying on conventional annotations that
evolved from a doc generator. I like these specific "shiny new features".

I believe that being stricter with type has helped reduce the rate at
which we introduce bugs. It's been totally worth it. As I see it, I
can't afford not to.

So I don't like Union Type because it will encourage sloppy type in libs
that I might otherwise want to use. I don't want nullable hints for the
same reason. With some reluctance and acknowledging the inconsistency I
do advocate nullable return because eliminating something or null from
PHP conventions seems a stretch and I'd rather these were declared than
not. That's just my position.

I don't think I'm behaving like an academic researcher or computer
scientist with a PhD. I prefer to see myself as a practical computer
programmer with a deep concern for long term maintenance of my programs.

The problem with adding all these new and shiny features ...
only for the benefit of the few who think programming should be
restricted to those who have Phd's.

I see two problems with arguing along these lines. 1. It's not specific
enough. 2. It's a bit insulting both to me and, I imagine, to academics.

So please try to be more specific about both what you want and why. At
the moment you appear to be arguing against any change to PHP and
justifying this with the argument that anyone who wants to change it is
an incompetent programmer.

Tom

10 years ago by Tony Marston — view source — reply

unread

"Tom Worster" wrote in message news:571267B4.9070507@thefsb.org...

"Marco Pivetta" wrote in message
news:CADyq6sJfPYgQvhQt=UvCBqkooJjoUPCz1sUfzwXc+55hL0PpzA@mail.gmail.com...

Tony, that sounds really like "real programmers use dd -if -of".
Please
stop with that argument, as it really doesn't reflect reality.

That is not what I said. As a follower of the KISS principle I believe
that good programmers write simple code that anyone can understand, while
less-than-good programmers write complex code that only a select
few can understand.

...or perhaps nobody can understand. Agreed. So I guess that makes me
a follower of the KISS principle too. I prefer boring, obvious,
conventional code and the kind of strict style guides that artisan codes
hate. I'm also conservative wrt changing PHP -- a gradualist. And I dislike
arguments proposing feature X because such-and-such more fashionable
language has it.

That said...

I have found that my programs, my team's and the libs I use are more
obvious, boring and easy to understand when they are clear about type.

So in recent years I've tried to be more and more rigorous in using PHPdoc2
type tags, the IDE's linters to run static checks, and working towards
eliminating using "mixed" and "|" in the type spec.

PHP 7.0's type is better than relying on conventional annotations that
evolved from a doc generator. I like these specific "shiny new features".

I believe that being stricter with type has helped reduce the rate at which
we introduce bugs. It's been totally worth it. As I see it, I can't afford
not to.

So I don't like Union Type because it will encourage sloppy type in libs
that I might otherwise want to use. I don't want nullable hints for the
same reason. With some reluctance and acknowledging the inconsistency I
do advocate nullable return because eliminating something or null from
PHP conventions seems a stretch and I'd rather these were declared than
not. That's just my position.

I don't think I'm behaving like an academic researcher or computer
scientist with a PhD. I prefer to see myself as a practical computer
programmer with a deep concern for long term maintenance of my programs.

The problem with adding all these new and shiny features ...
only for the benefit of the few who think programming should be
restricted to those who have Phd's.

I see two problems with arguing along these lines. 1. It's not specific
enough. 2. It's a bit insulting both to me and, I imagine, to academics.

Where is the insult in what I wrote?

So please try to be more specific about both what you want and why. At the
moment you appear to be arguing against any change to PHP and justifying
this with the argument that anyone who wants to change it is an incompetent
programmer.

Where did I ever use the word "incompetent"?

You are reading what isn't there.

--
Tony Marston

10 years ago by Fleshgrinder — view source — reply

unread

Where is the insult in what I wrote?

You are not only insulting people in this thread, you do it in every
thread you contribute to. You were exhorted multiple times for doing so.
Pretending otherwise does not change these facts so please get a grip.

--
Richard "Fleshgrinder" Fussenegger

10 years ago by Tony Marston — view source — reply

unread

wrote in message news:57135893.3070603@fleshgrinder.com...

Where is the insult in what I wrote?

You are not only insulting people in this thread, you do it in every
thread you contribute to. You were exhorted multiple times for doing so.
Pretending otherwise does not change these facts so please get a grip.

I repeat, where was the insult in the post in question? What exactly were
the insulting words? The fact that you don't like what I say does not make
it an insult.

--
Tony Marston

10 years ago by Tom Worster — view source — reply

unread

I repeat, where was the insult in the post in question? What exactly
were the insulting words?

I chose just one example:

Those who cannot write effective software without these "clever"
additions to the language are doing nothing but announcing to the
world that they are not clever enough to write effective software
using their own limited abilities.

I think it's hard to avoid construing an implication that people
proposing and/or supporting changes to how PHP handles type in the
current discussions here are incompetent programmers.

There's no doubt that this sentence posits a class of incompetent
programmers who need crutches ('these "clever" additions') and a
complementary class of competent programmer who don't. Saying so is
pointless without some assignment (imaginary, implied or real) of
individuals to the classes. It's hard to imagine that present company or
the people whose interests we attempt to represent are not involved in
the assignment. I find this a bit insulting.

Insult is something experienced as well as something performed. If
enough people experience it then probably it was performed, regardless
of intent. So to this extent I just disagree that...

The fact that you don't like what I say does
not make it an insult.

"It's Not What You Say, It's What People Hear"

But we are now completely off topic. To bring us back on topic I repeat
my request that you try to be specific about what you want and why, with
respect to the RFCs under discussion.

Tom

10 years ago by Tony Marston — view source — reply

unread

I repeat, where was the insult in the post in question? What exactly
were the insulting words?

I chose just one example:

Those who cannot write effective software without these "clever"
additions to the language are doing nothing but announcing to the
world that they are not clever enough to write effective software
using their own limited abilities.

I think it's hard to avoid construing an implication that people proposing
and/or supporting changes to how PHP handles type in the current
discussions here are incompetent programmers.

I did not use the word "incompetent" anywhere in that sentence.

There's no doubt that this sentence posits a class of incompetent
programmers who need crutches ('these "clever" additions') and a
complementary class of competent programmer who don't.

I simply pointed out that there is a class of programmer who has been able
to write successful software using PHP's original dynamic typing approach.
There is another class of programmer who want to make PHP operate more like
other languages and introduce strict typing, and these people insist that
they cannot write successful software WITHOUT these "clever" additions. Some
programmers follow the KISS principle and write simple code to to complex
things, while others write complex code to do simple things.

I'm sorry, but those who don't like the way that PHP works should stop
complaining about it, stop using it, and switch to a language which is more
suited to their programming style.

Saying so is pointless without some assignment (imaginary, implied or
real) of individuals to the classes. It's hard to imagine that present
company or the people whose interests we attempt to represent are not
involved in the assignment. I find this a bit insulting.

Insult is something experienced as well as something performed. If enough
people experience it then probably it was performed, regardless of intent.
So to this extent I just disagree that...

The fact that you don't like what I say does
not make it an insult.

"It's Not What You Say, It's What People Hear"

Cobblers. The fact that some over-sensitive souls hear things that weren't
actually written is their problem, not mine. Nowhere it that sentence did I
use the word "incompetent", so to say that I did is a downright lie. Unless
you can point to a word which is described as an insult in the dictionary
you cannot reasonably complain that your perceived it as an insult. That
just shows that your perception is faulty.

But we are now completely off topic. To bring us back on topic I repeat my
request that you try to be specific about what you want and why, with
respect to the RFCs under discussion.

I don't want the language overloaded with features that I have no intention
of using just because other languages have them. I don't want the language
overloaded with useless features which cause the language to run slower,
introduce bugs, and which make it difficult to add other features which
could actually be useful to the millions of userland developers out there.

--
Tony Marston

10 years ago by Fleshgrinder — view source — reply

unread

I repeat, where was the insult in the post in question? What exactly
were the insulting words?

I chose just one example:

Those who cannot write effective software without these "clever"
additions to the language are doing nothing but announcing to the
world that they are not clever enough to write effective software
using their own limited abilities.

I think it's hard to avoid construing an implication that people
proposing and/or supporting changes to how PHP handles type in the
current discussions here are incompetent programmers.

There's no doubt that this sentence posits a class of incompetent
programmers who need crutches ('these "clever" additions') and a
complementary class of competent programmer who don't. Saying so is
pointless without some assignment (imaginary, implied or real) of
individuals to the classes. It's hard to imagine that present company or
the people whose interests we attempt to represent are not involved in
the assignment. I find this a bit insulting.

Insult is something experienced as well as something performed. If
enough people experience it then probably it was performed, regardless
of intent. So to this extent I just disagree that...

The fact that you don't like what I say does
not make it an insult.

"It's Not What You Say, It's What People Hear"

But we are now completely off topic. To bring us back on topic I repeat
my request that you try to be specific about what you want and why, with
respect to the RFCs under discussion.

Tom

Very well said! :)

--
Richard "Fleshgrinder" Fussenegger

10 years ago by Zeev Suraski — view source — reply

unread

-----Original Message-----
From: Tony Marston [mailto:TonyMarston@hotmail.com]
Sent: Thursday, April 14, 2016 12:01 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Improving PHP's type system

"Zeev Suraski" wrote in message
news:5B147E88-CC0A-4CBC-A49D-C7FE3BF557C0@zend.com...

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?
:)

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

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,

I think this is taking the discussion a bit in the wrong direction.

I, for one, certainly don't think that our problem is people who want to prove how clever they are, and I do believe that people who are proposing additions and improvements to the language are doing it because they think it's a good thing. That does not mean it is though.

I am also saying that generally speaking, most people who are on internals@ are biased through self-selection towards change. People who are just happy the way things are, are unlikely to be on internals and are unlikely to want to contribute. Fixing bugs, meticulously optimizing performance while maintaining compatibility, these things get a LOT less interest and aren't main attraction points for joining internals. Incidentally, they're also the things that the vast majority of users want the most.

As a whole, people don't realize that PHP does not need fixing. I'm NOT saying it's perfect and that it cannot be improved - of course it can - but I am saying that it's not broken; In fact, it's remarkably successful the way it is, and in fact, we have no evidence that since the RFC process was embraced and language-level features started making their way into it on a much faster pace - anything changed for the better in terms of popularity. People arguing to introduce radical changes to it (and making PHP a lot more of a typed language, optional or not, absolutely constitutes a radical change) should realize that it's not risk-free, and given that they tend to be advanced, top 5-10% coders - that they're catering not to just coders like them, but also the rest of the 90-95% of the world.

Introducing new syntax to PHP, with new semantics, adds a lot of cognitive load no matter how we spin it. Given how easy it is now to propose an RFC, and the general bias-for-change of internals, we're now doing this at a remarkable pace, with very few checks and balances. Every feature is evaluated context-free, on whether it's useful in some cases yes/no, and without taking into account in any way that 'less is more'. Just see how much discussion we're seeing here about open questions in this typing discussion. Whatever decision we take in each and every one of these discussions - means added cognitive load, as by definition that decision wasn't an intuitive one, but one that required much discussion, debate and sometimes compromise in order to reach.

Zeev

10 years ago by Fleshgrinder — view source — reply

unread

but it does not help with primitive types. :(

Which is fine. Primitive types can and should get dedicated solutions. There's really no need for allowing over creativity with userland-customized scalar types.

Hmmm... nope. I already brought various examples where I personally see
the strength of union types and that is exactly with the primitives.[1]
int|string is so powerful if you deal with MySQLi and its BIGINT stuff
because I can fully type hint it now (like the /mysqli/ extension does
in C) and check very fast if I need to use GMP or not.

I can only repeat. I am fully supporting to block union types if we
instead commit to the introduction of additional primitive types (as
outlined in the generics RFC)[2] and operator overloading in userland.

However, use cases remain and union/intersection types can help
especially if you do not want any kind of is-a relationship in your
classes. In other words, we do not want to introduce an additional
interface for something because we do not want the instance to pass
through other checks. Or, of course, the situation where it is simply
impossible for me to introduce the interface: built-in classes. I might
want to decorate them and pass through all checks but I cannot because,
well, how?

[1] http://marc.info/?l=php-internals&m=146080503103988&w=2
[2] https://wiki.php.net/rfc/generics#related_enhancements

I believe you think I meant that instead of checking that $b's class actually implements foo and bar, we'd check whether $b has all of the methods needed by foo and bar - which means that theoretically means that it may have methods foo() and bar() but not actually 'officially' implement their respective interfaces. But there's no reason to do it this way and that's not what I meant.
Instead, with my proposal, a $b object whose class implements both foo and bar - will automatically be accepted as one that also implements baz. The checks will be conducted at the interface level, not the function list level. In other words, if $b doesn't explicitly implement baz, we'd take a look at 'baz', see it's comprised of foo & bar, and check whether $b's class implements them.

At this point, I can't imagine any negative side effect to automatically deducing that an object that implements foo and bar also implements baz (other than a small performance hit, probably roughly the same as the AND union type). Like I mentioned in my original post, I don't necessarily think it's needed - I personally see no reason not to add 'baz' to the list of interfaces impl implements, or as you said, replace foo and bar with baz altogether.

interface HouseCat {
function drink();
}

interface Dog {
function eat();
}

interface Lion {
function drink();
function eat();
}

A lion drinks and eats but is neither a HouseCat nor a Dog. This is
dangerous and introduces many potential hard to find bugs. Better don't
touch it and go for duck typing or the introduction of a dedicated
interface: always

--
Richard "Fleshgrinder" Fussenegger

10 years ago by Zeev Suraski — view source — reply

unread

-----Original Message-----
From: Fleshgrinder [mailto:php@fleshgrinder.com]
Sent: Tuesday, April 19, 2016 11:03 PM
To: Zeev Suraski zeev@zend.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Improving PHP's type system

but it does not help with primitive types. :(

Which is fine. Primitive types can and should get dedicated solutions.
There's really no need for allowing over creativity with userland-customized
scalar types.

Hmmm... nope. I already brought various examples where I personally see the
strength of union types and that is exactly with the primitives.[1]
int|string is so powerful if you deal with MySQLi and its BIGINT stuff
because I can fully type hint it now (like the /mysqli/ extension does in C) and
check very fast if I need to use GMP or not.

I can only repeat - primitive types can and should get dedicated solutions. There's really no need for allowing over creativity with userland-customized scalar types. If we think that a certain scalar definition makes a lot of sense, we can add it at the language level. There's no need to complicate the language, add syntax which makes no sense for objects and isn't really needed for scalars either.

interface HouseCat {
function drink();
}

interface Dog {
function eat();
}

-interface Lion {
+interface Lion extends HouseCat, Dog{
function drink();
function eat();
}

Pardon me saying this but it doesn't appear as if you've read what I wrote. Please take a look at the 'diff' I made in the definition of your Lion class, because without it, your sample and mine have little to do with each other.

With that change in place, please reevaluate whether what you said is relevant:

A lion drinks and eats but is neither a HouseCat nor a Dog. This is dangerous
and introduces many potential hard to find bugs. Better don't touch it and go
for duck typing or the introduction of a dedicated
interface: always

Nothing further.

Zeev

10 years ago by Fleshgrinder — view source — reply

unread

I can only repeat - primitive types can and should get dedicated solutions. There's really no need for allowing over creativity with userland-customized scalar types. If we think that a certain scalar definition makes a lot of sense, we can add it at the language level. There's no need to complicate the language, add syntax which makes no sense for objects and isn't really needed for scalars either.

We can for many:

type number := int|float
type object := <any object>
type scalar := bool|int|float|string
...

However, what about:

type ? := array|Traversable
type ? := int|string
type ? := float|string
type ? := bool|null
...

I actually argue that we do not even want to define them on a language
level (with the exception of array|Traversable) because these
combinations are too usecase specific.

interface HouseCat {
function drink();
}

interface Dog {
function eat();
}

-interface Lion {
+interface Lion extends HouseCat, Dog{
function drink();
function eat();
}

Pardon me saying this but it doesn't appear as if you've read what I wrote. Please take a look at the 'diff' I made in the definition of your Lion class, because without it, your sample and mine have little to do with each other.

With that change in place, please reevaluate whether what you said is relevant:

I guess I just jumped over that fact and misinterpreted it because what
you are proposing is a magic intersection type limited to interfaces.
While I cannot think of a situation where this creates problems from a
technical point of view (it is duck typing after all) I find it highly,
highly unusual and way too magic as well as even confusing.

I think there are two ways:

No union/intersection at all!

Union and intersection!

Going somewhere in between destroys generics, bounded quantification,
and F-bounded quantification in the future or at least makes it harder
to implement cleanly. You need to consider that this RFC might be voted
negative but it might come back in PHP 8 or PHP 9 where the landscape
has changed so vastly that it might become a yes.

Let's not introduce half backed features that nobody ever implemented
and found useful in any context or we end up with more weirdness that we
already have a some points.

--
Richard "Fleshgrinder" Fussenegger

10 years ago by Zeev Suraski — view source — reply

unread

I fail to see how adding C++ templates to PHP takes it to the next level in anything but the complexity scale. Not having them is not preventing anybody from doing anything today. Sure, a bunch of frameworks would adopt them once they become available - but it will not enable them to do things that are radically different from what they're doing today.

And the fact that you fail to see it is why you don't see any advantages, but that's because you are likely unfamiliar with most recent tooling around static introspection.

Saying that a given feature will not take PHP to the next level is not at all the same as saying I don't see any advantages. I did not say the latter, and I stand behind the former. As I said, I'm sure frameworks would use it and there are obviously some valid use cases for it, but it won't change the way the vast majority of people develop code. Forget for a minute whether we should or shouldn't add it - this is not a make or break feature for PHP.

Zeev

10 years ago by Marco Pivetta — view source — reply

unread

this is not a make or break feature for PHP.

That's why it's called a "feature"

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

10 years ago by Zeev Suraski — view source — reply

unread

If I had "scalar", "number" and ?T as types, the types I would need would be:

?scalar|Decimal

What's decimal? I'm not aware we have that type. Apologies if I missed it that it was added.

?scalar|Decimal|Expr

What's Expr? Again I'm not aware that we have that type.

In both, a nullable scalar does the job.

?scalar|array

Conduct this check in user code, you'd have to anyway.

int|string (I want int|string here. I know array keys are always int|string. A wider type is lies.)

This is needlessly purist. For handling a meaningless con, we'd overcomplicate the language and provide a footgun(tm) for everyone. Not a good bargain.

?scalar (probably)

Ok

number

Ok

T|false

You didn't answer my question on this one.

?T

Ok

5 out of 8 still need a union.

Actually, in my count only one of them does (#7) and it's probably solvable (if it's even a thing), and in another, it makes no sense to use types at all (#3) as you'd have to do these checks in userland anyway. All others can be satisfied just fine with scalar, numeric and nullable types, unless you're being needlessly purist - and we're not going to overcomplicate the language for the sake of purism.

Zeev

10 years ago by Jesse Schalken — view source — reply

unread

If I had "scalar", "number" and ?T as types, the types I would need would
be:

?scalar|Decimal

What's decimal? I'm not aware we have that type. Apologies if I missed
it that it was added.

As I said:

I have a function that converts values to SQL which have SQL equivalents,

including decimal values represented by a special Decimal class. It accepts
int|string|bool|null|float|Decimal.

All of int|string|bool|null|float can be converted to SQL
straightforwardly, however, MySQL has a distinct decimal type for exact
decimal values, written like "8542.31" in SQL (to get write a float, you
need "8542.31e0"). My class Decimal is used to represent a MySQL value of
type decimal, so it can be passed without be lossily converted to/from
float, and so it can be converted to the correct SQL. It is neither a float
nor an integer. A distinct class is needed for it.

?scalar|Decimal|Expr

What's Expr? Again I'm not aware that we have that type.

As I said:

I have a class Expr which represents an expression in SQL. Expressions can

be composed of other expressions, and of literal values, so the
constructors for Exprs accept int|string|bool|null|float|Decimal|Expr.

In both, a nullable scalar does the job.

?scalar|array

Conduct this check in user code, you'd have to anyway.

Not if I'm giving it straight to json_encode() I don't.

int|string (I want int|string here. I know array keys are always
int|string. A wider type is lies.)

This is needlessly purist. For handling a meaningless con, we'd
overcomplicate the language and provide a footgun(tm) for everyone. Not a
good bargain.

int|string is the correct type. If you're going to dismiss correctness as
"needlessly purist" then I'm going to dismiss PHP as not intended for
writing correct software.

?scalar (probably)

Ok

number

Ok

T|false

You didn't answer my question on this one.

substr() returns string|false
file_get_contents() returns string|false
fopen() returns resource|false
strpos() returns int|false
etc..

Without unions, the types of these functions cannot be denoted.

?T

Ok

5 out of 8 still need a union.

Actually, in my count only one of them does (#7) and it's probably
solvable (if it's even a thing), and in another, it makes no sense to use
types at all (#3) as you'd have to do these checks in userland anyway. All
others can be satisfied just fine with scalar, numeric and nullable types,
unless you're being needlessly purist - and we're not going to
overcomplicate the language for the sake of purism.

Zeev

10 years ago by Zeev Suraski — view source — reply

unread

From: jesseschalken@gmail.com [mailto:jesseschalken@gmail.com] On Behalf Of Jesse Schalken
Sent: Wednesday, April 20, 2016 4:42 PM
To: Zeev Suraski zeev@zend.com
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Improving PHP's type system

If I had "scalar", "number" and ?T as types, the types I would need would be:

?scalar|Decimal

What's decimal? I'm not aware we have that type. Apologies if I missed it that it was added.

As I said:

Zeev> So just use a container class (SQLValue or whatnot) that can include a scalar or a Decimal, and use this instead. It would probably result in a cleaner function body anyway.

?scalar|Decimal|Expr

What's Expr? Again I'm not aware that we have that type.

As I said:

Zeev> Same as above. Another option of course is to handle the type checks inside – that depends on whether you want to handle the details inside the SQLValue class or inside the function that accepts it.

?scalar|array
Conduct this check in user code, you'd have to anyway.

Not if I'm giving it straight to json_encode() I don't.

Zeev> Why not let json_encode() do the type checking then?

int|string (I want int|string here. I know array keys are always int|string. A wider type is lies.)
This is needlessly purist. For handling a meaningless con, we'd overcomplicate the language and provide a footgun(tm) for everyone. Not a good bargain.

int|string is the correct type. If you're going to dismiss correctness as "needlessly purist" then I'm going to dismiss PHP as not intended for writing correct software.

Zeev> Purism by definition – in all areas of life - insists it’s the one and only correct way to look at things. PHP has never been about purism, and we’re not going to start now. Instead of adjusting to how PHP models scalars, or moving to another language (both very valid options) – you insist on saying PHP must change to be your way.

T|false
You didn't answer my question on this one.

substr() returns string|false
file_get_contents() returns string|false
fopen() returns resource|false
strpos() returns int|false
etc..

Without unions, the types of these functions cannot be denoted.

Zeev> Why is it important to have a type that maps the return values of these functions? What does it buy you?

10 years ago by Fleshgrinder — view source — reply

unread

I am not quoting anything because the formatting of your emails is
completely off in Thunderbird. However, I want to add one to the list:

declare(strict_types=1);

interface Stringable {
function __toString(): string;
}

function fn(string|Stringable $arg) {
$param = (string) $arg;
}

We could add a new stringable primitive to PHP though, but do we guys
really want to start doing so? There is pretty much an endless amount of
combinations and finding names alone is endlessly hard.

declare(strict_types=1);

function fn(int|string $maybe_bigint) {
// mysqlnd automatically creates the proper type based on the value.
// Expressing this in userland is impossible ... :(
}

--
Richard "Fleshgrinder" Fussenegger

10 years ago by Dominic Grostate — view source — reply

unread

Just a thought that crossed my mind which might satisfy both worlds. Has
anyone every considered unions as a type declaration?

namespace Vector/TypeDefs

union Stringable
{
as string;
as int;
as float;

private $value;

public function __make($type)
{
    switch (type) {
        case 'string': return (string) $this->value;
        case 'int':    return (int)    $this->value;
        case 'float':  return (float)  $this->value;
    }
}

}

my_echo_func("123"); // << A scalar variable on the outside.

function my_echo_func(Stringable $stringable) // << a union on the inside
{
var_dump($stringable as string); // string(3) "123"
var_dump($stringable as int); // int(123)
var_dump($stringable as float); // float(123.0)
}

Perhaps not exactly like this, but adding unions as type of class
declaration should save a hell of a lot of keywords, and may save a number
of "instanceof" type checks as well.

I am not quoting anything because the formatting of your emails is
completely off in Thunderbird. However, I want to add one to the list:

declare(strict_types=1);

interface Stringable {
function __toString(): string;
}

function fn(string|Stringable $arg) {
$param = (string) $arg;
}

We could add a new stringable primitive to PHP though, but do we guys
really want to start doing so? There is pretty much an endless amount of
combinations and finding names alone is endlessly hard.

declare(strict_types=1);

function fn(int|string $maybe_bigint) {
// mysqlnd automatically creates the proper type based on the value.
// Expressing this in userland is impossible ... :(
}

--
Richard "Fleshgrinder" Fussenegger

10 years ago by Fleshgrinder — view source — reply

unread

Just a thought that crossed my mind which might satisfy both worlds. Has
anyone every considered unions as a type declaration?

namespace Vector/TypeDefs

union Stringable
{
as string;
as int;
as float;
private $value;

public function __make($type)
{
    switch (type) {
        case 'string': return (string) $this->value;
        case 'int':    return (int)    $this->value;
        case 'float':  return (float)  $this->value;
    }
}
}

my_echo_func("123"); // << A scalar variable on the outside.

function my_echo_func(Stringable $stringable) // << a union on the inside
{
var_dump($stringable as string); // string(3) "123"
var_dump($stringable as int); // int(123)
var_dump($stringable as float); // float(123.0)
}

Perhaps not exactly like this, but adding unions as type of class
declaration should save a hell of a lot of keywords, and may save a number
of "instanceof" type checks as well.

I do not like the idea because these types directly become part of your
public API and you end up including a dozen packages just to get the
basic union types in. More IO, more cache utilization, more
dependencies, ...

Also, one cannot change any type that was ever declared without a direct
BC. No, sorry, I thing that this is very bad. :(

However, the idea to make objects castable to more of the various scalar
types is not new and would be awesome.

interface Object {

function __toBool(): bool;
function __toFloat(): float;
function __toInt(): int;
function __toString(): string;

function __toArray(): array;
function __toObject(): object;
function __toResource(): resource;

}

Auto-conversion only if not ambiguous ($o1 + $o2 where both have
__toInt() and __toFloat() throws an ?Error but (float)$o1 + (float)$o2 works so does intdiv($o1, $o2)), next is operator
overloading. ;)

--
Richard "Fleshgrinder" Fussenegger

Improving PHP's type system View as Markdown

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? :)

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? :)

-- Lester Caine - G8HFL

Thanks!

-- Lester Caine - G8HFL

Thanks!

-- Lester Caine - G8HFL

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? :)

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? :)

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL