The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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

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.

Originally Posted by arkinstall

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

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.

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.

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:

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.

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.

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.

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

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.

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.

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

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.

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.

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.