SitePoint Sponsor

User Tag List

Results 1 to 9 of 9
  1. #1
    SitePoint Member
    Join Date
    Dec 2012
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Type safety in PHP

    Hi,
    I am currently working on my final project of my undergraduate study and the project is about type safety in PHP. One aspect of the project examines the opinion of the PHP community on this topic.

    I now need your help. I would be very glad, if you could take 5 20 minutes to fill in my online survey: http://www.q-set.co.uk/q-set.php?sCode=PGSKQCJUWZVK

    I will publish the deliverables of my project under an open source license. Thus you contribute automatically to an open source project if you fill in the form

    Thanks for your help
    Robert Stoll

  2. #2
    SitePoint Member
    Join Date
    Feb 2009
    Posts
    17
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You may want to read this https://wiki.php.net/rfc/returntypehint2 as the keyword function becomes an alias for return type mixed for backwards compatibility and maybe change your form to represent this as I believe this is the latest rfc even if it is a bit old.

  3. #3
    Keeper of the SFL StarLion's Avatar
    Join Date
    Feb 2006
    Location
    Atlanta, GA, USA
    Posts
    3,747
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)
    I find the survey to be... misleading/incomplete.

    You start to say "This will not affect PHP in any way"... and then in the next question propose changing the syntax of the function command.
    So... i cant complete the survey correctly.
    Never grow up. The instant you do, you lose all ability to imagine great things, for fear of reality crashing in.

  4. #4
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    I took your survey, out of curiosity. But I think some discussion could be held here on certain points as well. I realise most of this has been hashed and re-hashed many times over, here, on the PHP discussion groups, and elsewhere on the internet. Though, many of patrons do not visit such places.

    I think the differentiation should be made between type hinting and type safety. The are fundamentally different and likewise, serve different purposes. Type hinting is an as-of-right-now check, while type safety is an at-any-time check. Variables, or return values, marked with a type hint are checked only at the time of entry or return. However, such variables types would still be mutable once the values have been obtained. With type safety, they cannot. Implementing full type hinting would only serve to better error reporting in PHP. Of course, I am not denouncing the impact of this. Rather, I am merely putting it into perspective. As I am primarily a C/C++/C# developer, I would prefer that both aspects be fully utilized, with an ini option to disable it globally, and a method to turn it off for the current script. That said, do I think it is required? No. Part of the charm of PHP is the overall mutability it has. But if done, it needs to be done correctly and completely.

  5. #5
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    4,810
    Mentioned
    141 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Serenarules View Post
    I think the differentiation should be made between type hinting and type safety. The are fundamentally different and likewise, serve different purposes. Type hinting is an as-of-right-now check, while type safety is an at-any-time check. Variables, or return values, marked with a type hint are checked only at the time of entry or return. However, such variables types would still be mutable once the values have been obtained. With type safety, they cannot. Implementing full type hinting would only serve to better error reporting in PHP. Of course, I am not denouncing the impact of this. Rather, I am merely putting it into perspective. As I am primarily a C/C++/C# developer, I would prefer that both aspects be fully utilized, with an ini option to disable it globally, and a method to turn it off for the current script. That said, do I think it is required? No. Part of the charm of PHP is the overall mutability it has. But if done, it needs to be done correctly and completely.
    I agree with that. However, I also think that full type safety would be hard to implement in PHP since it isn't really a compiled language. Granted I guess once you start to serve up the page the JIT could find the errors and report them, but if you ask me, that is too late (from a developer perspective). That is one reason I really enjoy C/C#, I love the instant notification I can get by simply compiling my code.

    Also, granted, several IDEs are very capable of detecting these errors on your behalf before your code is asked to be rendered/compiled too, so you could argue it could still be implemented on that level too. But I digress, if your IDE did that, do you really need full type safety? Wouldn't type hinting with IDE support for detecting errors be enough? The only thing I dislike about that idea, is you are separating responsibility, PHP is responsible for continuing type hinting, and IDEs are responsible for ensuring your code sends appropriate values to your type hinted methods, classes, etc. -- Seems very dirty.
    Be sure to congratulate xMog on earning April's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  6. #6
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    I agree with that. However, I also think that full type safety would be hard to implement in PHP since it isn't really a compiled language. Granted I guess once you start to serve up the page the JIT could find the errors and report them, but if you ask me, that is too late (from a developer perspective). That is one reason I really enjoy C/C#, I love the instant notification I can get by simply compiling my code.

    Also, granted, several IDEs are very capable of detecting these errors on your behalf before your code is asked to be rendered/compiled too, so you could argue it could still be implemented on that level too. But I digress, if your IDE did that, do you really need full type safety? Wouldn't type hinting with IDE support for detecting errors be enough? The only thing I dislike about that idea, is you are separating responsibility, PHP is responsible for continuing type hinting, and IDEs are responsible for ensuring your code sends appropriate values to your type hinted methods, classes, etc. -- Seems very dirty.
    Exactly. Which is why I, overall, opt for the 'not required' option. And you're right. The way PHP handles certain scalars is not ameniable at the time for implenting type hints: string, int, etc).

    Anyway, you bring home a point most people seem to miss. Compiled vs Interpreted. In addition, the original intent of the given language. PHP was designed to be fast, light-weight and mutable. While it has seen more use lately in larger projects (business driven distributed applications), that isn't what it was designed for originally. The language is progressing, as more and more web sites make use of advanced concepts, but it's going to be a long road.

  7. #7
    SitePoint Member
    Join Date
    Dec 2012
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Heya,

    Quite a long time ago (almost a year), I asked you guys to fill in a survey about type safety in PHP which I conducted in context of my bachelor thesis.
    Unfortunately, I did not really have time to publish all results on a website so far but I am happy to announce that you can find the results here now:
    http://tsphp.tutteli.ch/wiki/display...+Safety+in+PHP

    My bachelor thesis serves as a basis of the open source project TSPHP. You can find further information about it on the wiki as well:
    http://tsphp.tutteli.ch/wiki/display/TSPHP/Overview

    Please don't hesitate if you have further questions about the survey or the project.

    Cheers,
    Robert

  8. #8
    SitePoint Addict bronze trophy
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    338
    Mentioned
    6 Post(s)
    Tagged
    1 Thread(s)
    Sounds interesting. PHP does not have return type hinting, which makes it less type safe compared to strongly typed languages. On the other hand, PHP's type juggling capability is powerful and flexible, but it comes with a cost to type safety as well. Also I believe implementing the language feature of Generics will further enhance type safety, as it can be used in collection classes/array objects. Currently a PHP array is definitely not type-safe, some restrictions can be enforced by extending PHP's ArrayObject/SplFixedArray class and the overriding its offsetGet and offsetSet so that they check object types. Nonetheless, this means that you have to create one subclass of ArrayObject/SplFixedArray for every type you want to enforce type-safety in a collection. It will require quite a bit of changes to make PHP a truly type-safe programming language.

    One comment Id like to make regarding return type hinting in your survey. I was wondering whether the keyword 'function' can be omitted if return type hinting is used. The following syntax below makes better sense to me, as specifying a return type after the keyword 'function' makes the code looks ugly:

    PHP Code:
    public string getName(){
        
    //...
    }
    public 
    void setName(string $name){
        
    //...

    If return type hinting is optional, the keyword 'function' cannot be omitted as the compiler wont be able to tell that it's a method compared to a property. Well in languages like javascript this is not a problem, but for PHP I'm sure theres a reason why distinguishing properties from methods is necessary. To summarize, the keyword function in method signature is used as identifier for methods that do not follow return type hinting, when return type hinting is used the keyword function is replaced by the return type. Of course this assumes that only method return type hinting is implemented, but not with property type declaration(so nothing like public string $name).

  9. #9
    SitePoint Member
    Join Date
    Dec 2012
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As a general answer, PHP isn't type-safe at all, it just gives the user the possibility to define some constraints with type hints but they are not binding. For instance, I can still write (the valid code)
    PHP Code:
    function foo(Foo $foo){
        
    $foo 1;

    Personally I think it is not bad that PHP is weak typed and not type-safe. I think PHP has become so popular exactly due to this "sloppiness". It's a language which is very easy to learn and still powerful and besides, everyone can write in a type-safe manner if one likes. The project TSPHP does not try to change that and therefore is introduced on a higher level than PHP (thus without changing PHP itself). It could be seen as the type-safe counterpart of PHP (or you could think of a very big DSL based on PHP where the domain is type safety ^^).

    Quote Originally Posted by Hall of Famer View Post
    Also I believe implementing the language feature of Generics will further enhance type safety, as it can be used in collection classes/array objects
    I totally agree, but I don't think it makes really sense for PHP itself. Consider the following:
    PHP Code:
    function foo(array<int$arr){
        
    $arr[] = "muahaha"//will still be possible

    As you can see, as long as PHP is not completely type-safe this feature is more or less useless and it would also cause an undesired performance penalty because array<int> would actually mean that PHP has to verify the content of $arr before it can be used and thus would be something similar like the following userland code:
    PHP Code:
    function foo(array<int$arr){
        for(
    $arr as $value){
            if(!
    is_int($arr[$i]))  trigger_error("xy",\E_USER_ERROR);
        }
        
    //and now do something

    That's why I don't think it would be clever to introduce generics in PHP. However, generics make perfect sense in TSPHP (aim is to introduce it in v. 0.8.0 of TSPHP). Just to avoid misunderstandings, TSPHP demands complete type safety (there won't be something like optional type safety). Generics would simplify the usage of arrays in TSPHP because right now, arrays can just hold objects of type object and hence one has to cast to the appropriate type when reading from an array. With generics this would become needless.

    Quote Originally Posted by Hall of Famer View Post
    It will require quite a bit of changes to make PHP a truly type-safe programming language.
    Indeed, a big effort is needed and the changes are just one reason why I doubt PHP will become once a type-safe language because the changes would imply a huge BC break at some point.
    In my personal opinion, I think a compile time approach (as TSPHP follows) is the right one because it enables complete type safety for those who want it, does not result in performance penalties (there are actually performance improvement opportunities) and does not hamper PHP to evolve further as language.
    One big drawback: TSPHP has to be maintained in parallel to PHP and the implementation of TSPHP itself is already a huge effort (contributors are welcome )

    An additional benefit of the compile time approach is, that one has the possibility to go back to PHP (without type safety) because all TSPHP code is translated to PHP at some point. There is somewhat a forward compatibility between PHP and TSPHP (not a backward compatibility though - PHP code does not compile as TSPHP code, but I am already thinking about a solution for this issue).

    I think there is also another factor which shouldn't be underestimated. Type safety means also an additional learning curve. I tried to simplify the change to TSPHP and the need for additional type definitions by introducing new constructs. As an example the cast assign operator and the cast modifier which should ease the usage with types.
    Still, there are other improvements which could be implemented to simplify the usage with types such as type inference.

    Quote Originally Posted by Hall of Famer View Post
    I was wondering whether the keyword 'function' can be omitted if return type hinting is used.
    That's actually a good point. I was thinking about it at the beginning of the project and decided at the stage that one has to write function as well. My decision was based on the reason that the transition from PHP code
    PHP Code:
    function foo(){} 
    to TSPHP code
    PHP Code:
    function void foo(){} 
    would be easier. Nevertheless, I just created a change request (TSPHP-645) and I will at least reconsider to make function optional (then code conventions have to define whether the developer should write function or not).


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •