Do You Think That PHP Would Benefit from Static Typing?

[Jake Arkinstall]

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
  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
  function uselessFunction($string) returns string{
      return $string;
  }
  ?>

  That's more user friendly but more lengthy - but the 'returns' could be abreviated to _ or something, i.e:
  

  <?php
  function uselessFunction($string) _ string{
  
  }?>

• More type hinting! Yeah, you can specify a type of object or implementation. I mean full:
  

  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:
  

  $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?

[BerislavLopac]

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.

[Jake Arkinstall]

Interfaces are most definitely not a waste of time.

If you give yourself restraint, your code is more stable.

[Amenthes]

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:

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.

[Jake Arkinstall]

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.

[chestertondevelopment]

More type hinting! Yeah, you can specify a type of object or implementation. I mean full:

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.

Return types specified. Any syntax, as long as you can. Personally, I'd prefer:

<?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.

The ability to use an ordinary variable as it's object. For example:

$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.

[Jake Arkinstall]

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
function getFirst() for string $str{
    return $str[0];
}
$var = 'hello';
echo $var->getFirst(); //output: h

[BerislavLopac]

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.

[Bob Carologees]

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.

[kyberfabrikken]

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.

[Jake Arkinstall]

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.

[Czaries]

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.

[dagfinn]

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.

[Bob Carologees]

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.

[Jake Arkinstall]

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.

[BerislavLopac]

An integer can be cast to a string: 29 == "29".

Hm -- and why not '1D'? or 11101'?

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.

[Jake Arkinstall]

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.

[robt]

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..

if (mysql_connect_errno())
{
     // handle error
}

[Jake Arkinstall]

That should technically be:

if (mysql_errno() > 0){
     // handle error
} 

Because you're checking if the errno is above 0, therefore an error exists.

[BerislavLopac]

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.

[Jake Arkinstall]

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.

[BerislavLopac]

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.

[Jake Arkinstall]

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.

[Czaries]

I actually wouldn't mind dynamic typecasting of function parameters, either. I can think of a ton of potential great uses for that:

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.

[BerislavLopac]

Actually, Czaries, putting the type into the parentheses, as you did in your examples, kinda solves the issue.