Monday, February 19. 2007
 |
 |
 |
 |
Posted by Stephan Schmidt
in
No Stubbles, Planet PHP Comments (21) Trackbacks (2) |
 |
 |
 |
 |
My wishlist for PHP 6, pt1: The 'object' type hint
I was very pleased, that PHP 5 introduced type hints, although they are not available for primitives like string, int, boolean, etc. Still, I'd like to see the object type hint introduced in any future version of PHP that allows me to specify, that a method or function only accepts an object, regardless of the type of the object:
Currently you always have to specify a class or interface name, but I can't see, why this is needed. In Java, this is no problem, as they have a common base class for all of their classes, which is not the case with PHP. So when trying to call this method with an object like this:
you get the following error:
Catchable fatal error: Argument 1 passed to Processor::processObject() must be an instance of object, instance of Foo given, called in test.php on line 14 and defined in test.php on line 6
The reflection extension lets us do a lot of funky stuff without knowing anything about the passed object, so I can't see a reason why this feature should not be implemented. If this already is possible in PHP, please let me know. If not, I hope that Marcus Börger is reading this entry and will implement this for PHP 6
. And yes, I'm well aware, that this might create some problems if anybody has a class named Object, but please don't start another namespace flamewar (although namespace are one of my other wishes for PHP 6).
And while we are talking about it: What about a ressource type hint, that will only accept ressources, that can be processed by functions like fread() and fclose()?
public static function processObject(object $obj)
should be:
public static function processObject(stdClass $obj)
class Processor {
public static function processObject(object $obj) {
echo get_class($obj) . "\n";
}
}Currently you always have to specify a class or interface name, but I can't see, why this is needed. In Java, this is no problem, as they have a common base class for all of their classes, which is not the case with PHP. So when trying to call this method with an object like this:
class Foo{}
Processor::processObject($foo);you get the following error:
Catchable fatal error: Argument 1 passed to Processor::processObject() must be an instance of object, instance of Foo given, called in test.php on line 14 and defined in test.php on line 6
The reflection extension lets us do a lot of funky stuff without knowing anything about the passed object, so I can't see a reason why this feature should not be implemented. If this already is possible in PHP, please let me know. If not, I hope that Marcus Börger is reading this entry and will implement this for PHP 6
. And yes, I'm well aware, that this might create some problems if anybody has a class named Object, but please don't start another namespace flamewar (although namespace are one of my other wishes for PHP 6).And while we are talking about it: What about a ressource type hint, that will only accept ressources, that can be processed by functions like fread() and fclose()?
Comments
Display comments as
(Linear | Threaded)
I also searched for a "global super class" in php, would be nice to have it in php6
I do not necessarily need a global super class (although this might be nice to have), I just want to be able to say "only accept objects of any type in this parameter".
Why not rename PHP to Java Lite while we're at it 
More seriously I can't see the point of type hints in a dynamic language like PHP. Yes, you get the ability to do some nice stuff like auto wiring of objects (http://sourceforge.net/projects/phemto) but you won't gain the benefits of static type checking since there is no real compile stage.
More seriously I can't see the point of type hints in a dynamic language like PHP. Yes, you get the ability to do some nice stuff like auto wiring of objects (http://sourceforge.net/projects/phemto) but you won't gain the benefits of static type checking since there is no real compile stage.
Well, currently PHP allows more static type checking, than the one I propose. So adding this feature surely wouldn't hurt...
Sure, it would add consistency to type hinting. Yet I am asking myself: What's the point of it?
As stated earlier you won't gain much from static type checking in PHP and even if you did it wouldn't catch all the bugs for you. You will still need another way of verifying wheter your code is working or not (for example Unit Tests).
As stated earlier you won't gain much from static type checking in PHP and even if you did it wouldn't catch all the bugs for you. You will still need another way of verifying wheter your code is working or not (for example Unit Tests).
Of course, this is no replacement for unit-tests, but it saves me typing is_object() in every method, that expects an object of any type. Of course, I'd want to convert the E_RECOVERABLE to an exception by using an error_handler. It would even be cooler, if the engine itself would throw the exception.
"I hope that Marcus Börger is reading this entry and will implement this for PHP 6"
It might be better to contact the persons directly or using the bug tracker or developer list. Blogging is quite inefficient for reaching the devs...
It might be better to contact the persons directly or using the bug tracker or developer list. Blogging is quite inefficient for reaching the devs...
Can you give an example of when you would use this 'object' hint? Surely, your function would be making assumptions about the object, to manipulate it in some way. If it does this, it expects the object to implement certain methods or properties. In this case, you could use a base class or an interface.
In our XMLSerializer class, I have a method, that serializes objects. It uses reflection, to extract information like the properties or methods and writes them to XML (this can be influenced using annotations). In this method, I don't care about the type of the object, but I surely need an object. I could think of a lot more examples, where this could be useful.
As a workaround you can use interfaces for typehinting. This way you don't have to bind your method signature to a specific class and it's also more specific than a generic 'object' type hint:
Well, I know, that I can use interfaces. In 90% of all cases, I'm using interfaces instead of class names for type hints. But still, there's the need for a completely generic object type hint.
If you were to leave hints out altogether, what would happen exactly?
While not the most elegant solution, you could always do:
interface Stubbles_Object { }
And just tack that on wherever you need it as the generic way to check for an object. Of course, that only works if you can modify each of the objects you want to pass into your processObject() code.
interface Stubbles_Object { }
And just tack that on wherever you need it as the generic way to check for an object. Of course, that only works if you can modify each of the objects you want to pass into your processObject() code.
Hi Travis.
We have such an interface:
http://www.stubbles.net/browser/trunk/src/main/php/net/stubbles/stubObject.php
But we I do not want to force all users to implement this interface. Even if we added a separate interface that's just used for tagging, it would enforce you to tag all of your classes.
We have such an interface:
http://www.stubbles.net/browser/trunk/src/main/php/net/stubbles/stubObject.php
But we I do not want to force all users to implement this interface. Even if we added a separate interface that's just used for tagging, it would enforce you to tag all of your classes.
The link didn't work. I believe this is it.
That's not exactly what I had in mind. I was thinking of a blank interface that serves as nothing but placeholder. Still not the most elegant solution and it does require everyone to add 'implements SomeInterface' to every one of the objects they want to use, but it is an option.
Having the ability to type hint against primatives (array, int, float, string, object, resource, all of 'em) would definitely be useful.
That's not exactly what I had in mind. I was thinking of a blank interface that serves as nothing but placeholder. Still not the most elegant solution and it does require everyone to add 'implements SomeInterface' to every one of the objects they want to use, but it is an option.
Having the ability to type hint against primatives (array, int, float, string, object, resource, all of 'em) would definitely be useful.
"this is not about what people want always. If we wer doing this than all
languages would more or less look the same and none had a prticular use
case. Instead all languages would simply always suck. PHP was designed for a
typless environment, the web. Read the mail archieves for more on this."
This is insane. Testing for strings and arrays or any other type are not separate features. They are the same feature.
languages would more or less look the same and none had a prticular use
case. Instead all languages would simply always suck. PHP was designed for a
typless environment, the web. Read the mail archieves for more on this."
This is insane. Testing for strings and arrays or any other type are not separate features. They are the same feature.
public static function processObject(object $obj)
should be:
public static function processObject(stdClass $obj)
I think this would be a very useful feature. I love PHP, I am a full time PHP devloper and a freelance designer. All i use is PHP. I think this would be very beneficial because one of the major flaws of PHP in my opinion it its toleration for sloppiness and flawed code. This would be incredibly useful for my applications, because as it is now I have to validate every important variable manually, which is a huge pain. It probably would be even easier to implement than object type hinting, which has already been done.
I would have to second you on the type hints. It seems it must have been easy to add type hints for classes and arrays... but must have been harder to do primitives as well so they left that out. They seem to be sort of "in the middle" and so i think they should finish off what they started with type hints. Return type hints would also be nice so you know what something like: get_collection() will return (array? object? delimited string? etc)
Not keen on your second point in the post though, but i defiantly agree with the first point.
Not keen on your second point in the post though, but i defiantly agree with the first point.
Calendar
|
July '09 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||
Categories
Quicksearch
Blogs we read...
Syndicate This Blog
Blog Administration
Yesterday evening Stephan wrote about the object type hint. Coincidentally, while being in my favourite bar, I was talking with Timm Friebe, a colleague of mine, about the scalar type hint: function bar(scalar $baz) { ... } This type hint would al
Tracked: Feb 20, 14:18
Tracked: Feb 20, 14:36