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 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 85
  1. #26
    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 see where I went too Java in this.

    So here's a refinement of what I think PHP should have (optionally):
    • Return types specified. Any syntax, as long as you can. Personally, I'd prefer:
      PHP Code:
      <?php
      string uselessFunction
      ($string){
          return 
      $string//must be a string.
      }
      ?>
      So replace function with whatever the return type is - but still allow function.
      Another way could be:
      PHP Code:
      <?php
      function uselessFunction($stringreturns string{
          return 
      $string;
      }
      ?>
      That's more user friendly but more lengthy - but the 'returns' could be abreviated to _ or something, i.e:
      PHP Code:
      <?php
      function uselessFunction($string_ string{

      }
      ?>
    • More type hinting! Yeah, you can specify a type of object or implementation. I mean full:
      PHP Code:
      function uselessFunction(string $string){ 
      That surely can't cause issues, especially because (a)the manual has the types listed anyway and (b)it would be optional.
    • The ability to use an ordinary variable as it's object. For example:
      PHP Code:
      $str "hello";
      echo 
      $str->replace('h''H'); 
      Again, optional, but I think it would revolutionise PHP's functions - especially because they're so jumbled up as they are.

    All of the above wouldn't mess up current code, but it would surely help make code cleaner and more structured.

    Agree?
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  2. #27
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just a few thoughts of my own:

    Static typing adds nothing to object-oriented programming.

    In PHP5, typehints and interfaces are a waste of time. They only make sense if worked together, and they are not necessary at all precisely because PHP is dynamically typed. Duck typing beats static typing any time.

    Static typing makes sense only for low-level languages which operate only on basic types, such as C. This allows programmers to have maximum control over their use of system resource, which is in high-level languages such as PHP taken care of by the garbage collectors.

  3. #28
    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)
    Interfaces are most definitely not a waste of time.

    If you give yourself restraint, your code is more stable.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  4. #29
    SitePoint Zealot Amenthes's Avatar
    Join Date
    Oct 2006
    Location
    Bucharest, Romania
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A patch for hinting scalar types like int, string, boolean has already been done and proposed but didn't make it. Among the emails from the php-internals list that I read, some people suggested that would be more useful to hint the general type, scalar or non-scalar. Like:

    PHP Code:
    function foo(scalar $param) {} 

    Honestly, I don't think type hinting is what PHP needs, but lambdas and namespaces (which we'll have with PHP 5.3). More means of organizing our programs.

    I don't want PHP bloated in a Java style. It already has a lot of quirks with function names and param order and parser problems. Python doesn't have the type-hinting facilities PHP has right now, yet, there are people that do very nice programs with it.
    I'm under construction | http://igstan.ro/

  5. #30
    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'm not talking about the result of the PHP application - the result is the same.

    However if you create a set of classes for PHP and they NEED to be certain types etc, you should be able to define them and let PHP handle errors when they don't suit - rather than going through that horrible type-validation stage.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  6. #31
    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 arkinstall
    More type hinting! Yeah, you can specify a type of object or implementation. I mean full:
    PHP Code:
    function uselessFunction(string $string){ 
    This is something I'd like to see, it's very strange that we have type hinting for arrays but not for strings, integers or booleans. It wouldn't break BC and seems like an easy addition to the language, it would be interesting to know why it was declined by internals.
    Quote Originally Posted by arkinstall
    Return types specified. Any syntax, as long as you can. Personally, I'd prefer:
    PHP Code:
    <?php 
    string uselessFunction
    ($string){ 
        return 
    $string//must be a string. 

    ?>
    I don't see any benefits to return types at all to be honest, more verbosity and less flexibility. Like I mentioned earlier in the thread the only place I see a benefit for them is in interfaces where a class is expected to conform to a set of rules.
    Quote Originally Posted by arkinstall
    The ability to use an ordinary variable as it's object. For example:
    PHP Code:
    $str "hello"
    echo 
    $str->replace('h''H'); 
    Again, optional, but I think it would revolutionise PHP's functions - especially because they're so jumbled up as they are.
    No real reason for it but I really don't like that idea. It's very ruby-like where everything is an object and would be a massive change to the language, an unwelcome one for me.

  7. #32
    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)
    Technically everything wouldn't be an object.

    The parser simply notices the object notation isn't connected to an object but a variable. It then verifies the type of variable and passes it to predefined functions for that particular variable type.

    Kind of like general functions but with the parameter being it's 'host'.

    There are alot of possibilities for something like that. You could create your own defined functions for variables:
    PHP Code:
    <?php
    function getFirst() for string $str{
        return 
    $str[0];
    }
    $var 'hello';
    echo 
    $var->getFirst(); //output: h
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  8. #33
    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
    However if you create a set of classes for PHP and they NEED to be certain types etc, you should be able to define them and let PHP handle errors when they don't suit - rather than going through that horrible type-validation stage.
    I have argued this extensively in other threads on this forum, so I won't repeat all the arguments here. But most briefly, what define's an object's type is not its class, but its behavior -- which is actually the collection of its public properties.

    Try reading a bit about duck typing.

  9. #34
    Non-Member
    Join Date
    Jul 2005
    Posts
    606
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think the type-hinting that's already available is sufficient, one of the things that has helped the language grow over the years is it's expressiveness and dynamic nature, to drastically change that, or to crowbar such functionality into it would be a huge mistake.

    Good applications will have measures in place to mitigate the risks of data integrity problems already, or they should do.

    These sort of suggestions are quite typical of people that are new to the language, if you've been working with it for several years it's quite incomprehensible to imagine it being as strict as Java or C. If anything we should want to increase the expressiveness of PHP, not decrease it. Things like lexical scope, more convenient short-hands and better support for iterators would be a move in the right direction.

  10. #35
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    PHP Code:
    function uselessFunction(string $string){ 
    That surely can't cause issues, especially because (a)the manual has the types listed anyway and (b)it would be optional.
    Allowing this would break PHP's dynamic typing system. Today you can pass an integer to a function that expects a string, and PHP will typecast the argument for you. If you introduced typehints to scalars, this would have to change. That's a major paradigm shift.

  11. #36
    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)
    Not necessarily. An integer can pass as a string. But if you're expecting a boolean and 29 or "leaf" is passed, there are problems.

    Basically variables passed are attempted to be cast as the variable the function accepts. If it's a string, 2 will pass. If it's a number, "52" would pass. If it's a boolean, 0 and 1 would pass, "true" and "false" would pass, too.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  12. #37
    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
    Not necessarily. An integer can pass as a string. But if you're expecting a boolean and 29 or "leaf" is passed, there are problems.

    Basically variables passed are attempted to be cast as the variable the function accepts. If it's a string, 2 will pass. If it's a number, "52" would pass. If it's a boolean, 0 and 1 would pass, "true" and "false" would pass, too.
    That idea wouldn't really go over well, and defeats the whole purpose of requiring a strict type anyway - I can just see the list of exceptions now - what about NULL? What about objects that have a __toString() method defined? I imagine some sort of table would have to be created that would then map out what type actually accepts which other types and would look something like these ... it would be a mess, and in my opinion, a mistake for PHP.

    I agree with the sentiment that strict type hinting would go against the very core dynamic nature of PHP, and shouldn't be done. There are a few times when it may be nice, but the type casting added in PHP5 remedies most of those cases for me.

  13. #38
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by CoderMaya View Post
    I think ultimately what I was talking about is a fabulous modification of PHP into another language.
    I came across a "blitz interview" in which Bruce Tate is asked

    Imagine, that you have the right to add five Ruby language elements to the next version of Java. What would they be? Can you include quick code samples as well?
    http://java.sys-con.com/node/251986

    This might apply equally to PHP.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  14. #39
    Non-Member
    Join Date
    Jul 2005
    Posts
    606
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not necessarily. An integer can pass as a string. But if you're expecting a boolean and 29 or "leaf" is passed, there are problems.

    Basically variables passed are attempted to be cast as the variable the function accepts. If it's a string, 2 will pass. If it's a number, "52" would pass. If it's a boolean, 0 and 1 would pass, "true" and "false" would pass, too.
    Sense. You're making none.

  15. #40
    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)
    It makes perfect sense.

    Basically if a parameter is expected to be one type, the passed variable is attempted to be cast to that type. If it can't be (i.e. a boolean to a string) then it errors.

    So to rephrase that extract:

    An integer can be cast to a string: 29 == "29".
    An integer 29 can't be cast to boolean realistically
    A string 'leaf' can't be cast to a boolean
    The string "52" can be cast to an integer.
    integers 0 and 1, and strings "true" and "false" can both be cast to a boolean.

    That's how it already works - I'm just suggesting that it be carried out with function parameters too.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  16. #41
    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
    An integer can be cast to a string: 29 == "29".
    Hm -- and why not '1D'? or 11101'?

    Quote Originally Posted by arkinstall View Post
    An integer 29 can't be cast to boolean realistically
    A string 'leaf' can't be cast to a boolean
    The string "52" can be cast to an integer.
    integers 0 and 1, and strings "true" and "false" can both be cast to a boolean.

    That's how it already works - I'm just suggesting that it be carried out with function parameters too.
    It's not working quite as you're saying (string 'leaf' is cast to boolean as TRUE), but I get what you mean -- a typehint for basic type would implicitly call a typecast, i.e. function foo (string $bar) would have the same effect as calling the function as foo((string) $bar). I could actually live with that; however, this would mean that you have one syntax for two different effects (type check and typecast), which is a major no-no.

  17. #42
    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)
    why not '1D'? or 11101'?
    They would both be accepted. 11101 would be, by default, 11101 - unless it was originally cast to binary.

    this would mean that you have one syntax for two different effects
    Not entirely true.

    For one the typecast is in brackets whilst the type check isn't. Secondly the typecheck exists only in the function definition, where the typecasting would error.

    I do beleive, however, that 'leaf' shouldn't cast to boolean. That is a big flaw and is, to be honest, pointless.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  18. #43
    SitePoint Enthusiast
    Join Date
    Nov 2006
    Posts
    50
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    I do beleive, however, that 'leaf' shouldn't cast to boolean. That is a big flaw and is, to be honest, pointless.
    I think that sort of thing is quite useful..

    Code PHP:
    if (mysql_connect_errno())
    {
         // handle error
    }
    Last edited by robt; Sep 1, 2008 at 04:38. Reason: typo

  19. #44
    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)
    That should technically be:
    PHP Code:
    if (mysql_errno() > 0){
         
    // handle error

    Because you're checking if the errno is above 0, therefore an error exists.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  20. #45
    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
    Not entirely true.

    For one the typecast is in brackets whilst the type check isn't. Secondly the typecheck exists only in the function definition, where the typecasting would error.
    You didn't understand. We have function foo (basetype $bar) and function foo (Class $bar), which is essentially the same syntax, but has two different effects: the first silently converts an incorrect type, but the latter throws an error on a wrong type.

  21. #46
    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)
    Not necessarily.

    If the expected value is a scalar value, cast the passed variable to it. Otherwise just check it's the same type (or an implementation/extention thereof) and throw an exception otherwise.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  22. #47
    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
    If the expected value is a scalar value, cast the passed variable to it. Otherwise just check it's the same type (or an implementation/extention thereof) and throw an exception otherwise.
    My point exactly -- two different behaviors from a single syntax.

  23. #48
    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)
    Not really - it's the same thing. In both situations a cast is attempted.

    The difference is that objects and scalars can't be cast to other objects.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  24. #49
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I actually wouldn't mind dynamic typecasting of function parameters, either. I can think of a ton of potential great uses for that:

    PHP Code:
    function getUser((int) $userId) {
        
    // Now $userId is safe to use directly in a query because it has been cast to INT...
    }

    function 
    doSomeIteration((array) $someArray) {
        
    // We can now loop over this fine because it will always be an array...

    I do have to agree with BerislavLopac about the syntax though. What you're wanting is for the variable to be automatically cast to the type you want, not a strict enforcement of a specific type through type-hinting. And since PHP already has specific syntax for typecasting, that needs to be used instead of a strict type declaration like is currently used for classes/interfaces and arrays.

  25. #50
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Actually, Czaries, putting the type into the parentheses, as you did in your examples, kinda solves the issue.


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
  •