Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Improving PHP's type system »

Improving PHP's type system

php.internals

Levi Morrison

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

Levi Morrison

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

Fleshgrinder

10 years ago
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

Levi Morrison

10 years ago
On Wed, Apr 13, 2016 at 1:10 PM, Fleshgrinder <php@fleshgrinder.com> wrote:
> 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.

Fleshgrinder

10 years ago
On 4/13/2016 9:57 PM, Levi Morrison wrote:
> On Wed, Apr 13, 2016 at 1:10 PM, Fleshgrinder <php@fleshgrinder.com> wrote: >> 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

Stas Malyshev

10 years ago
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

Fleshgrinder

10 years ago
On 4/13/2016 10:24 PM, Stanislav Malyshev 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? :) >
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

Bob Weinand

10 years ago
> 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

Stas Malyshev

10 years ago
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

Tom Worster

10 years ago
On 4/13/16 5:06 PM, Stanislav Malyshev wrote:
>> 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

Larry Garfield

10 years ago
On 4/13/16 3:24 PM, Stanislav Malyshev 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. :-)
-- --Larry Garfield

Zeev Suraski

10 years ago
> On 14 באפר? 2016, at 7:14, Larry Garfield <larry@garfieldtech.com> wrote: > >> On 4/13/16 3:24 PM, Stanislav Malyshev 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 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

Peter Lind

10 years ago
On 14 April 2016 at 01:43, Zeev Suraski <zeev@zend.com> wrote:
> > > On 14 באפר׳ 2016, at 7:14, Larry Garfield <larry@garfieldtech.com> > wrote: > > > >> On 4/13/16 3:24 PM, Stanislav Malyshev 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

Tony Marston

10 years ago
"Zeev Suraski" wrote in message news:5B147E88-CC0A-4CBC-A49D-C7FE3BF557C0@zend.com...
> > >> On 14 ????? 2016, at 7:14, Larry Garfield <larry@garfieldtech.com> wrote: >> >>> On 4/13/16 3:24 PM, Stanislav Malyshev 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 > >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

Alain Williams

10 years ago
On Thu, Apr 14, 2016 at 10:00:41AM +0100, Tony Marston wrote:
> 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>

Lester Caine

10 years ago
On 14/04/16 10:00, Tony Marston wrote:
> 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

Levi Morrison

10 years ago
> 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.

Zeev Suraski

10 years ago
> -----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... > > > > > >> On 14 ????? 2016, at 7:14, Larry Garfield <larry@garfieldtech.com> wrote: > >> > >>> On 4/13/16 3:24 PM, Stanislav Malyshev 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 > > > >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

Lester Caine

10 years ago
On 13/04/16 21:24, Stanislav Malyshev wrote:
>> 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

Stephen Coakley

10 years ago
On Wed, 13 Apr 2016 10:53:13 -0600, Levi Morrison wrote:
> Continued (hit send by hotkey accident): > > On Wed, Apr 13, 2016 at 10:50 AM, Levi Morrison <levim@php.net> wrote: >> First, some background: several versions of PHP ago authors of >> functions and methods could only restrict types to the array type or a >> class/interface type. We slowly added some other types such as callable >> and primitive types. These tools have been invaluable to those who care >> about restricting the types of their inputs and outputs. This type >> information reduces the code each author has to write if they want to >> restrict to working with certain types and it also provides a form of >> documentation. Overall these features have been well received and are >> considered a good thing to do. >> >> However, as we have added these new restrictions we still cannot >> express exactly what types are permitted in some common cases. >> >> 1. Return types cannot specify the function will return only type T >> or Null. >> 2. Parameter types cannot express that an iterable type is required. >> It's common for functions to work a stream of data and it is irrelevant >> if it is an array or a Traversable object. >> 3. Parameter types cannot express that that the parameter must >> implement two different interfaces. For example, requiring a parameter >> to implement both Countable and Traversable cannot be done. >> >> There are some common work-arounds to these issues: >> >> - Omit the type information and rely on documentation. >> - Check the parameter type inside the function (eg >> `assert(is_array($x) || $x instanceof Traversable)`) >> - Introduce a new type that embodies the restrictions. If this in an >> interface it must be implemented by every object you hope to use the >> restriction with. >> >> In some cases these work-arounds are tolerable. However, some of them >> are really painful. >> >> - Requiring a new supertype is intrusive. Code cannot always be >> changed to use the new supertype. For example: >> - Upstream projects that would not benefit from your changes. >> - Primitives cannot be extended except by altering the engine. >> In these cases a new type has to be introduced that proxies >> behavior to the underlying object/primitive. >> - Relying on documentation can lead to subtle and hard to diagnose >> issues when it is used incorrectly. Erroring immediately is sometimes >> preferable. >> >> All of these issues I've outlined can be nicely resolved by adding two >> new kinds of types to our system: union and intersection types. A union >> type requires the variable to match at least one of the types. An >> intersection type requires the variable to match all of the types. The >> vertical par symbol (OR) is used for unions and ampersand (AND) is used >> for intersections. For example: >> >> function (A | B $var); would require $var to be either type A or >> type B. >> function (A & B $var); would require $var to be type A and type B. >> >> To accommodate the common use-case of returning some type or Null we >> would need to formally allow `Null` as an explicit type: >> >> function (): T | Null; >> >> Since this is a common use case some languages have a short-hand >> notation to represent a union with Null: > > function (): ?T; > > Examples of such languages include Swift, C#, OCaml and Hack (though the > symbol is sometimes in the front and sometimes in the back. > > Later today I will be submitting RFCs for each of these proposals. > Although they can work independently it is helpful to understand the > overall goal and how they fit together, which has been the purpose of > this email. Feedback for each RFC will belong in the thread for that > piece, but discussion about the ideas overall is better suited here.
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