Type safety in PHP - Page 2
Page 2 of 2 FirstFirst 12
Results 16 to 29 of 29

Thread: Type safety in PHP

  1. #16
    Pna lbh ernq guvf¿
    Join Date
    Jul 2004
    Location
    Kansas City area
    Posts
    19,353
    I, too, tried to keep backwards compatibility in mind for every answer I gave on the survey.

    One of my ideas was to by default make type violations an E_NOTICE/E_WARNING level error but to also add an option to error_reporting that would elevate these to catchable fatal errors.

    EDIT: I should add... I came up with this idea without thinking of the approach Derokorian described (and/or what was described on the page traq linked to in post #12). I'm still on the fence as to which way I like better.
    Last edited by bradgrafelman; 01-05-2013 at 11:36 AM.

  2. #17
    Senior Member traq's Avatar
    Join Date
    Jun 2011
    Location
    so.Cal
    Posts
    949
    Quote Originally Posted by Derokorian View Post
    What I would expect is that since $a != (int) $a that this usage would not produce 0 but instead produce a Fatal error
    Right:
    PHP Code:
    function intOnlyint $int ){}
    intOnly"a" );
    /*
    (int)"a" = 0
    "a" != 0
    throw error
    */
    intOnly"1" );
    /*
    (int)"1" = 1
    1 == 1
    okay
    */
    # intOnly( "1thing" ); # strike that. better example:
    intOnlytrue );
    /*
    (int)true = 1
    ...?
    yeah... that's where it gets muddy.
    */ 
    Quote Originally Posted by bradgrafelman View Post
    One of my ideas was to by default make type violations an E_NOTICE/E_WARNING level error but to also add an option to error_reporting that would elevate these to catchable fatal errors.
    Hadn't thought of that. Good possibility.
    Last edited by traq; 01-05-2013 at 03:34 PM.

  3. #18
    High Energy Magic Dept. NogDog's Avatar
    Join Date
    Aug 2006
    Location
    Ankh-Morpork
    Posts
    13,820
    As far as I'm concerned, if you specify...
    PHP Code:
    function foo(boolean $bar) { ... } 
    ...and call it as...
    PHP Code:
    foo(1); 
    ...it should throw an exception, just as it would if you type-hinted with "Array" or any class name. Automatically converting it to the desired type would not be "type safety", to my mind.

    However, note any such implementation would now mean you could not call any of your classes "boolean" or any other implemented type names (which may already be reserved words?), or if you did, you could not use that class's name as a type-hint any more -- not that I'd generally want to call any of my classes that, but I suppose you could define classes to represent different data types as a way to implement type safety, by allowing you to type-hint with those class names?

    Oh well, guess I'm just glad I've never really had an issue with PHP's loose typing (or whatever it's technically called?).
    Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be." ~ from Nation, by Terry Pratchett

    "But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now!" ~ http://www.oreillynet.com/ruby/blog/...ck_to_p_1.html


    eBookworm.us

  4. #19
    Senior Member traq's Avatar
    Join Date
    Jun 2011
    Location
    so.Cal
    Posts
    949
    Quote Originally Posted by NogDog View Post
    As far as I'm concerned, if you specify...
    PHP Code:
    function foo(boolean $bar) { ... } 
    ...and call it as...
    PHP Code:
    foo(1); 
    ...it should throw an exception, just as it would if you type-hinted with "Array" or any class name. Automatically converting it to the desired type would not be "type safety", to my mind.
    Agreed - just a little muddy, since (for example) 1 and 0 are so synonymous with TRUE and FALSE.
    But where would you draw the line? Should "5" (a string) fail where an integer is required?

  5. #20
    High Energy Magic Dept. NogDog's Avatar
    Join Date
    Aug 2006
    Location
    Ankh-Morpork
    Posts
    13,820
    Quote Originally Posted by traq View Post
    Agreed - just a little muddy, since (for example) 1 and 0 are so synonymous with TRUE and FALSE.
    But where would you draw the line? Should "5" (a string) fail where an integer is required?
    In my mind, yes, since type-hinting means you only want to accept parameters of the specified type. If, instead, you want the normal loose typing, then simply do not type-hint for it (or embed your own type-checking/-swapping mechanism at the beginning of the function definition if you want something in between strict type-checking and no type-checking). But like I said, I'm not going to loose any sleep over it for now.

    Hmm...now I'm imagining a class full of methods for various sorts of type-checking...darn you all, I have other things that need doing!
    PHP Code:
    function enforceInteger(&$value)
    {
        if(
    is_int($value)) {
            return 
    true;
        }
        elseif((int)
    $value == $value) {
            
    $value = (int) $value;
            return 
    true;
        }
        throw new 
    TypeException("Not an integer");

    Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be." ~ from Nation, by Terry Pratchett

    "But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now!" ~ http://www.oreillynet.com/ruby/blog/...ck_to_p_1.html


    eBookworm.us

  6. #21
    Pna lbh ernq guvf¿
    Join Date
    Jul 2004
    Location
    Kansas City area
    Posts
    19,353
    Quote Originally Posted by traq View Post
    But where would you draw the line? Should "5" (a string) fail where an integer is required?
    IMHO, yes, because:
    PHP Code:
    gettype("5") != gettype(5
    .

    Otherwise, why not consider the character 'a' to be an integer? Any C program would be happy to evaluate:
    Code:
    ('a' == 97)
    as TRUE.

  7. #22
    Junior Member
    Join Date
    Dec 2012
    Posts
    0
    Quote Originally Posted by Derokorian View Post
    What I would expect is that since $a != (int) $a that this usage would not produce 0 but instead produce a Fatal error.
    Well, if
    PHP Code:
    $a "a"
    then
    PHP Code:
    $a == (int) $a 
    evaluates to true because the == does make a weak comparision and thus $a would be castet to a int before it is compared against (int) $a and consequentely $a and (int) $a are the same.

    but $a !== (int) $a. But if you compare it with === then it would be the same as having a strict type-safety as described by NogDog (what in my opinion makes absolutely sense).

    Maybe it would be nice if a developer can decide on his own if he wants an auto casting or not. Maybe with a construct like this:
    PHP Code:
    function foo (cast int $a){ //cast $a to int if $a isn't a int
    //...
    }
    function 
    bar(int $a){ // does not cast $a to int and therefore would throw a fatal error if a string is given
    //...

    if someone would call foo with an object then also a fatal error would be thrown, since an object cannot be castet to int

  8. #23
    Senior Member traq's Avatar
    Join Date
    Jun 2011
    Location
    so.Cal
    Posts
    949
    Quote Originally Posted by rstoll View Post
    Well, if
    PHP Code:
    $a "a"
    then
    PHP Code:
    $a == (int) $a 
    evaluates to true because the == does make a weak comparision and thus $a would be castet to a int before it is compared against (int) $a and consequentely $a and (int) $a are the same.
    yeah... it'd have to be implemented some other way.

    Quote Originally Posted by rstoll View Post
    Maybe it would be nice if a developer can decide on his own if he wants an auto casting or not.
    I'd thought about that. I was considering using
    PHP Code:
    function foo( (int)$a ){ /* cast $a if necessary */ }
    function 
    barint $a ){ /* no casting; strict equality only */ 
    seems more intuitive to me.

    *****

    To answer bradgrafelman and NogDog,

    I agree that casting "if equivalent" wouldn't actually work very well, and that, if you ask for a particular type you should expect the comparison to be strict. The only examples where I'm hesitant (that I can think of) is 1/0 vs. TRUE/FALSE and numeric strings vs. integers.

  9. #24
    High Energy Magic Dept. NogDog's Avatar
    Join Date
    Aug 2006
    Location
    Ankh-Morpork
    Posts
    13,820
    Quote Originally Posted by rstoll View Post
    ...
    PHP Code:
    function foo (cast int $a){ //cast $a to int if $a isn't a int
    //...

    I do kind of like that, in that it makes it obvious what's happening just from the function prototype, regardless of what any comments or lack of comments may say.
    Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be." ~ from Nation, by Terry Pratchett

    "But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now!" ~ http://www.oreillynet.com/ruby/blog/...ck_to_p_1.html


    eBookworm.us

  10. #25
    Senior Member Derokorian's Avatar
    Join Date
    Apr 2011
    Location
    Denver
    Posts
    1,740
    Quote Originally Posted by rstoll View Post
    Well, if
    PHP Code:
    $a "a"
    then
    PHP Code:
    $a == (int) $a 
    evaluates to true because the == does make a weak comparision and thus $a would be castet to a int before it is compared against (int) $a and consequentely $a and (int) $a are the same.

    but $a !== (int) $a. But if you compare it with === then it would be the same as having a strict type-safety as described by NogDog (what in my opinion makes absolutely sense).
    ah but not if you did:
    PHP Code:
    $a == (string) ((int) $a
    where string is the type passed, if castable. Because "a" != "1" so it would fail.

    Quote Originally Posted by rstoll View Post
    Maybe it would be nice if a developer can decide on his own if he wants an auto casting or not. Maybe with a construct like this:
    PHP Code:
    function foo (cast int $a){ //cast $a to int if $a isn't a int
    //...
    }
    function 
    bar(int $a){ // does not cast $a to int and therefore would throw a fatal error if a string is given
    //...

    I like this way a lot.
    Sadly, nobody codes for anyone on this forum. People taste your dishes and tell you what is missing, but they don't cook for you. ~anoopmail
    I'd rather be a comma, then a full stop.
    User Authentication in PHP with MySQLi - Don't forget to mark threads resolved - MySQL(i) warning

  11. #26
    Pedantic Curmudgeon Weedpacket's Avatar
    Join Date
    Aug 2002
    Location
    General Systems Vehicle "Thrilled To Be Here"
    Posts
    21,773
    Quote Originally Posted by rstoll View Post
    Maybe it would be nice if a developer can decide on his own if he wants an auto casting or not. Maybe with a construct like this:
    PHP Code:
    function foo (cast int $a){ //cast $a to int if $a isn't a int
    //...

    And if $a is passed by reference (function foo (cast int &$a){), does the source variable find its value also being cast?
    PHP Code:
    $value '42';
    foo($value);
    echo 
    gettype($value); // "integer" or "string"? 
    THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER
    FAQs! FAQs! FAQs! Most forums have them!
    Search - Debugging 101 - Collected Solutions - General Guidelines - Getting help at all

  12. #27
    Senior Member traq's Avatar
    Join Date
    Jun 2011
    Location
    so.Cal
    Posts
    949
    Quote Originally Posted by Weedpacket View Post
    And if $a is passed by reference (function foo (cast int &$a){), does the source variable find its value also being cast?
    My impulse answer would be "yes," since you presumably know that you're passing by reference (and if you didn't, you'd have problems anyway).
    I wouldn't expect the value to be modified (in any way) if it failed the test, however.

  13. #28
    Senior Member traq's Avatar
    Join Date
    Jun 2011
    Location
    so.Cal
    Posts
    949
    An illustration. Still too many problems to actually be useful.

    https://gist.github.com/4600808

  14. #29
    Junior Member
    Join Date
    Dec 2012
    Posts
    0
    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

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

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