SitePoint Sponsor

User Tag List

View Poll Results: Static Typing:

Voters
45. You may not vote on this poll
  • Yes

    11 24.44%
  • Maybe

    2 4.44%
  • No

    30 66.67%
  • Don't Care

    2 4.44%
Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 85
  1. #51
    SitePoint Member
    Join Date
    Oct 2007
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @arkinstall: Do you know Generics ? PHP is not Java

  2. #52
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The proper place to constrict behaviour is in unit tests. What failing tests can only be made to pass using static typing?

  3. #53
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac View Post
    Actually, Czaries, putting the type into the parentheses, as you did in your examples, kinda solves the issue.
    Yeah... that was the point . I was trying to illustrate the way that I personally would want what @arkinstall wanted actually implemented. The key to that syntax choice was here:
    ...since PHP already has specific syntax for typecasting, that needs to be used instead of a strict type declaration...
    So basically I was pointing out that what he really wanted was dynamic typecasting of function parameters instead of requiring a specific type, and the chosen syntax should reflect that (which is why I used the types in parenthesis instead).

  4. #54
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Actually, I'm suggesting both.

    The function does require a certain type. The variable passed to it, if not the certain type, has a cast attempted on it.

    So, for example:
    PHP Code:
    function doSomething(String $str){ }
    doSomething("hello world"); //already a string
    doSomething(1); //1 is converted to "1"
    doSomething($myObject); //__toString() is accessed - if not specified, error out.
    doSomething(true); //boolean cannot be converted to string realistically - throw an error 
    and
    PHP Code:
    <?php
    interface someInterface{}
    class 
    someClass implements someInterface{}
    class 
    anotherClass implements someInterface{}
    class 
    yetAnotherClass extends anotherClass{}
    class 
    justSomeClass{}
    function 
    doSomething(someInterface $obj){}
    doSomething(new someClass); //implements someInterface - pass
    doSomething(new anotherClass); //implements someInterface - pass
    doSomething(new yetAnotherClass); //parent implements someInterface - pass
    doSomething(new justSomeClass); //doesn't implement someInterface - fail
    doSomething('hello'); //Scalar, not object - error
    So, I'm not suggesting that the variable is only cast. The chosen type is required - if it isn't that type a cast is attempted.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  5. #55
    SitePoint Addict SirAdrian's Avatar
    Join Date
    Jul 2005
    Location
    Kelowna, BC
    Posts
    289
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'd hate to see autocasting like that, I much prefer throwing exceptions when the type is wrong. IMO the code calling the function should do the casting, if necessary.

    In the object to string example, either accept an object and call __toString() in the method, or accept a string. Not both.
    Adrian Schneider - Web Developer

  6. #56
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    Actually, I'm suggesting both.

    The function does require a certain type. The variable passed to it, if not the certain type, has a cast attempted on it.
    ... (snip) ...
    So, I'm not suggesting that the variable is only cast. The chosen type is required - if it isn't that type a cast is attempted.
    But that's really the same thing... You'll end up with a variable of the type you want (string, int, etc.) or an error either way. If you cast a variable to a certain type that it already is, a cast won't be attempted already. If it can't be cast, an error will be produced.

    There would be no difference between what you want and what typecasting already does. It would be much better if the syntax matched what it was actually doing, and looked like the already existing typecasting syntax.

    You say you want this syntax to enforce a "String" type, but to attempt a cast if you pass in any other type:

    PHP Code:
    function needString(String $myStr) {
        return 
    $myStr;

    I don't see how that would be any different than this, which would also attempt a typecast if the passed variable was not a string:

    PHP Code:
    function needString((string) $myStr) {
        return 
    $myStr;

    Either way you end up with a string variable or an error, and one syntax already exists and is more explicit about what it's actually doing.

  7. #57
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    @SirAdrian: I'm not talking about what you do now, I'm talking about what should be allowed (after all, PHP is always under dev).

    Whilst they could be handled in-function - it should be an automatic process. After all, if it's build into PHP it's going to be a faster process anyway.

    Take, for example, the behaviour of echo. It should be mimicked in the action of string casting:
    PHP Code:
    function output(String $str){} 
    Anything that echo would output would be in $str. If echo can't handle them (e.g. booleans) it should fail.

    Similar to what you sometimes get in Java.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  8. #58
    SitePoint Addict SirAdrian's Avatar
    Join Date
    Jul 2005
    Location
    Kelowna, BC
    Posts
    289
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I know, and I'm saying I disagree with it.

    It's even faster if you pass it the right data type to begin with.
    Adrian Schneider - Web Developer

  9. #59
    SitePoint Addict chestertondevelopment's Avatar
    Join Date
    Dec 2005
    Location
    Essex, UK
    Posts
    241
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This sort of typecasting seems like too much magic going on in the background and it's not obvious what the code should do. Every other language that has static typing on methods ensures that the variable is that type, it doesn't try and cast it into something else. I wouldn't mind perhaps the ability to ensure a boolean or integer on methods but if you want to cast something then why not just do the following.
    PHP Code:
    function foo($bar) {
        
    $bar = (int) $bar;
        if (
    $bar == 0) throw new Exception(....);

    It's more coding but it's also more explicit.


    Quote Originally Posted by arkinstall
    PHP Code:
    function doSomething(String $str){ } 
    doSomething("hello world"); //already a string 
    doSomething(1); //1 is converted to "1" 
    doSomething($myObject); //__toString() is accessed - if not specified, error out. 
    doSomething(true); //boolean cannot be converted to string realistically - throw an error 
    Quote Originally Posted by arkinstall
    Anything that echo would output would be in $str. If echo can't handle them (e.g. booleans) it should fail.
    But in the rest of PHP a boolean can be casted to a string, either '1' or '0', you can't introduce something that acts in a completely different way to the rest of PHP, whether that be the right or the wrong way.
    Last edited by chestertondevelopment; Sep 3, 2008 at 17:12.

  10. #60
    SitePoint Addict SirAdrian's Avatar
    Join Date
    Jul 2005
    Location
    Kelowna, BC
    Posts
    289
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    IIRC true gets casted as '1' and false gets casted as ''.

    This sort of typecasting seems like too much magic going on in the background and it's not obvious what the code should do. Every other language that has static typing on methods ensures that the variable is that type, it doesn't try and cast it into something else.
    Exactly.
    Adrian Schneider - Web Developer

  11. #61
    SitePoint Addict chestertondevelopment's Avatar
    Join Date
    Dec 2005
    Location
    Essex, UK
    Posts
    241
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by SirAdrian
    IIRC true gets casted as '1' and false gets casted as ''.
    Ah, probably is then that's what happens when you post late purely on memory.

  12. #62
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by chestertondevelopment View Post
    Ah, probably is then that's what happens when you post late purely on memory.
    And so it is:
    [berry@berry ~]$ php -r 'var_dump( (string) true );'
    string(1) "1"
    [berry@berry ~]$ php -r 'var_dump( (string) false );'
    string(0) ""

  13. #63
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Ok - I must have only come in contact with echo false then, because I find that it doesn't echo.

    My point is that there should be a way to make sure that the passed variable is of a certain type. As people seem to be in disagreement about the casting feature, there could easily be a .ini set to auto_cast or something, which a user could change both on the server and on-the-fly.

    Still, do you guys agree that such var-rules should at least be allowed? It would really stabalize applications easier than having to check through the passed variables, and it would, of course, be optional.

    If not, the in-function-definition casting would still be handy to have (i.e. function something((string) $str){}).
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  14. #64
    SitePoint Addict SirAdrian's Avatar
    Join Date
    Jul 2005
    Location
    Kelowna, BC
    Posts
    289
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    An ini_set rule would be chaos, similar to magic quotes or register globals. It would be such a pain to track down when it's not set correctly.

    I still think this is the best way:
    PHP Code:
    function identifier(string $text) {


    In most cases, doing this at the function level would, at least to me, indicate the data should have been dealt with earlier. Whether it's user input, database data, it should be cleaned up before using in your application. When it's not a string, that's an error on your part, and an exception should be thrown to notify you.

    I don't see how
    PHP Code:
    function identifier( (string) $text) { 


    is any more convenient than
    PHP Code:
    function identifier($text) {
       
    do_something((string)$text);

    It actually makes the code less clear, because 1) you can't tell what the function expects and 2) you get unexpected behavior in your new function.
    Adrian Schneider - Web Developer

  15. #65
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @arkinstall:

    I don't think the disagreement is with the feature itself, but instead with the syntax you are choosing. The "function something(String $str) {}" syntax is for strict types in every other language I can think of. @chestertondevelopment hit the nail on the head, and it's what I've been trying to tell you by suggesting a different syntax all along.

    Quote Originally Posted by arkinstall View Post
    ... As people seem to be in disagreement about the casting feature, there could easily be a .ini set to auto_cast or something, which a user could change both on the server and on-the-fly.
    That is a terrible idea. The goal of future versions of PHP (especially PHP6) has been to reduce the settings dependencies and differences between servers. Think 'register_globals' and 'magic_quotes' - some scripts that required them would completely break if the setting was off. That is exactly what would happen if such a critical core PHP behavior is allowed to be turned on or off on the fly.

    I do agree, however, that auto-casting would be very useful for functions, and I would love to see it in a new version of PHP - with the already defined and understood casting syntax - "function something((string) $str) {}".

  16. #66
    Coding and Breathing CoderMaya's Avatar
    Join Date
    Feb 2008
    Location
    Atlit, Israel
    Posts
    470
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @SirAdrian:

    Eh. I don't know about that. Implementing it in the function definition makes the function a lot more stable...

    Not to mention, if the function is supposed to get a string then why would we want to send it like in your 3rd code block over and over again? Why not just force it in the definition?

    I think you got a bit lost there, to be honest.
    Learn about the new Retro Framework
    Code PHP the way it was meant to be coded!

  17. #67
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by SirAdrian View Post
    An ini_set rule would be chaos, similar to magic quotes or register globals. It would be such a pain to track down when it's not set correctly.
    lol... we must have been writing our posts at the same time...

    Quote Originally Posted by SirAdrian View Post
    I don't see how
    PHP Code:
    function identifier( (string) $text) { 


    is any more convenient than
    PHP Code:
    function identifier($text) {
       
    do_something((string)$text);

    It actually makes the code less clear, because 1) you can't tell what the function expects and 2) you get unexpected behavior in your new function.
    I must say I really disagree with you here...

    1) I see that the first function expects a string, because it's right in the function signature - I don't see how that's less clear?

    2) You still get unexpected behavior if you place the casting further down in the function, only the error will look like it's coming from inside the function itself and not the input that was passed into the function. Again, that seems much less clear to me, not to mention potentially confusing to someone trying to use your function and thinking it's broken because the error message says the error is inside the function. At least with dynamic casting, they'll know about any errors upfront and immediately see that it was bad input as a function argument.

  18. #68
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I still think this is the best way: function identifier(string $text) { }
    In most cases, doing this at the function level would, at least to me, indicate the data should have been dealt with earlier. Whether it's user input, database data, it should be cleaned up before using in your application. When it's not a string, that's an error on your part, and an exception should be thrown to notify you.
    To be honest, I couldn't agree with you more.

    I don't think the disagreement is with the feature itself, but instead with the syntax you are choosing. The "function something(String $str) {}" syntax is for strict types in every other language I can think of
    Well, are you in agreement with a strict-type then?
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  19. #69
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    Well, are you in agreement with a strict-type then?
    Not for PHP, no. To me, it would defeat the dynamic nature of variables in PHP. If any type of type-hiting is allowed, it should be dynamic casting because that's what PHP does with variables anyways.

  20. #70
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    But we can do it with objects and arrays - why not scalars too?
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  21. #71
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    But we can do it with objects and arrays - why not scalars too?
    Because Objects and Arrays have special syntax and/or functions - the rest of the types are interchangeable.
    Last edited by Czaries; Sep 4, 2008 at 11:46. Reason: typo

  22. #72
    SitePoint Addict SirAdrian's Avatar
    Join Date
    Jul 2005
    Location
    Kelowna, BC
    Posts
    289
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I said convenient, not necessarily easy to spot. I suppose if editors were able to parse it (which I'm sure they would) then it's slightly less evil.

    My point was doing it in the function is pretty standard. If you expect something to be an integer, you might intval or (int) before using it in your code - as final sanity check. Ultimately, either assertion or throwing an exception is best here, IMO.

    I also agree with what was said earlier - restricting type restrictions with unit testing. Handling scalar types this way (function x ( string $var ) ) is not quite as crucial, because they do not have any special syntax or expected interface.
    Adrian Schneider - Web Developer

  23. #73
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    But we can do it with objects and arrays - why not scalars too?
    Just because something exists doesn't mean that it's good and should be used. Type hinting in PHP don't make much sense unless you're using interfaces -- and interfaces themselves are completely unnecessary (except as a kind of documentation) unless you're using type hinting.

    Interfaces were introduced into statically typed languages to make them more dynamic; introducing them into dynamic languages kinda beats the purpose. And in any case, dynamic languages already have a perfectly fine way of ensuring that an object belongs has the right interface -- it's called duck typing.

  24. #74
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Duck typing really isn't my style.

    I like my code to be as small and concise - but very readable - as possible. I'd prefer two words in the function (doSomething(interfacename $object)) than have to check if it has the right properties and functions.

    PHP may be dynamically typed, but that's not all it is. The reason I use it is because it's good for it's job, but I know I'd definitely prefer a static typed variant.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  25. #75
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    PHP may be dynamically typed, but that's not all it is. The reason I use it is because it's good for it's job, but I know I'd definitely prefer a static typed variant.
    Well, you're trying to bend the tool to act like another tool you "prefer". It's like trying to hammer a nail with a screwdriver.

    If you prefer nails, use a hammer. If you decide to use a screwdriver, use screws, not nails. Tools are specialized -- you can't blame a tool for being something else than what you're familiar with. The problem is not in PHP, it's in you.

    But you're still young, there's time for you to learn.


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
  •