Today I released the first public version of my new library PHPTypeSafe. It provides the ability to use PHPs Type Hinting feature for scalar values.
The PHP way of Type Hinting
PHP 5 introduced Type Hinting. Functions were now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). But Type Hints can only be of the object and array type. Traditional Type Hinting with int and string isn't supported.
There were several request on the PHP internals maillinglist to introduce Type Hinting for scalar values, too. All of them got rejected, but at the moment there's a request for comment going on at the PHP Wiki. Besides Type Hints for scalar values the proposals also includes Type Hinting for return values. While the first proposal can be done in the userland, the later can only be archived by changing PHP itself.
So what does PHPTypeHint offer?
By including PHPTypeSafe in your project you will be able to use Parameter Type Hinting for scalar values, the compound type object and the special type resource. A simple example on how to use this functionality would be:
The output would be:
PHPTypeSafe offers the support for the following types:
boolean(including aliasbool)float(including aliasesdoubleandreal)integer(including aliasesintandlong)object(generic object matcher)resourcestring
Every type hint matcher is strict (so '1' won't match with the integer type hint), as you shouldn't use type hints if you aren't sure about the given /required type of value. (Those cases could still be checked using is_str(), is_int() and the like.)
Requirements and where to get it
PHPTypeSafe has been written using namespaces and is being packaged as a Phar PHP Archive. That's why it requires you to use PHP 5.3 (or later).
You can download PHPTypeSafe at dev.maxhorvath.com.
Feedback
I would be very happy to receive your feedback on how you like the library and if there are any issues on how to use it.
Very cool. Glad to see I'm not the only one who has started using the Java-like namespace names. The next plugin I plan to write for my preprocessor is for type-hinting. Maybe I will just have the plugin do return type-hinting, and use your plugin for input value type-hints.
Very good work! We need this in the PHP 5.3 core!
@Ronald:
Glad you like it. If you want to have it in the PHP Core (plus type hinting for return values), have a look at http://wiki.php.net/rfc/typehint and give your vote for it in the PHP internals maillinglist ...
A long waited and useful functionality!
And i think also, that this should be in PHP's core.
Interesting approach. However, I doubt that catching and parsing E_RECOVERABLE_ERROR ist very fast. Did you run any benchmarks comparing your approach to typical is_*() tests inside the method or compared to internal type hints?
This looks more like a very interesting experiment than a tool for productive use to me.
Hey Tobi,
sure it's not as fast as it should be. I wanted to publish benchmarks during the next days. So stay tuned.
Besides that - I personally use the library in a project that doesn't run in a high concurrency environment - so the performance penalty is not that much of an issue.
What I can say right now is, that checks for scalars and resource are much faster than the check for object.
In the end there is one advantage: the speed penalty will hit only when you use the type hints. And I tried to cache as much as possible so parsing repeatedly errors shouldn't take as long as the first hit.
No, just no. I'm sorry but this is just horrible. Can someone please tell me the point of type hinting i a dynamic language? I beg of you.
Dear anonymous commenter,
I just want to give two reasons / points.
1. Type Hinting is an *optional* feature - nobody forces you to use it. But if you need it, you *can* use it.
2. If it is, because PHP is a dynamic language which should not have a mechanism of checking the type of a variable - why did they include all the is_*() functions in the language?
Excellent, but I won't use it until it makes the core. But I'm soooo hoping it will be part of PHP one day.
The idea behind it is to avoid having to cast, if a error is thrown, it meant you did something wrong. So of course in that scenario it's slower.
But you shouldn't be getting the errors.
It's not something needed for every method out there, it's just to force in cases you would really want it.
Put simply, this is for people who don't understand how to use polymorphism to an advantage. That being said, I'm sure that these people will appreciate type hinting, and it's not as though there's one perfect way to use PHP.
Well, no - there are situations where you need to check for the type of an variable - and type hints can just make you write much less code (compare type hints for parameters to a few if-clauses containing is_*() calls and exception handling).
In the end you are not forced to use type hints for parameters. They are just a nice add-on.
The thing is, I can't see any reason for this. One of the main advantage of typ hinting in compiled languages is that the compiler can catch errors for you, *before* they happen in the runtime, in php you can't.
As another commenter pointed it, parsing E_RECOVERABLE_ERROR got to be rather slow - but then again it probably won't matter since the application will throw a fatal exception if an error is found anyway.
Also, because you have type hinting/forcing without the added benefit of static languages of compiletime-checking the calling context has to be aware of to handled errors that could be thrown because of the argument list (in a dynamic language), errors that should be handled within the called function/method.
Have you given a look at SPL_Types for that matter? That could be a way to save you some annoyances. Why re-inventing the wheel after all when all you'd have to do is to enable the extension :)
@Fredrik:
Well, as I already wrote:
1.) Parsing E_RECOVERABLE_ERROR got to be rather slow ... but it only happens when there are errors anyway.
2.) More important: using type hints in a dynamic language is NOT the same like in a static language - but it's shorter to use type hints compared to using is_*() functions (and its error handling) all the time.
@David:
I don't know, if I understood SPL_Types wrong, but you'd have to compile in a custom PHP (Pecl) extension and be forced to declare/change (i.e.) strings like objects ... that's not as easy like just using string and checking the type.
I guess a lot of people hate new things :) This looks like a very cool, frontline feature and i'll definitely be looking into it.
I work in a small web-company and this could be very handy for us. Using other peoples methods you can easily be confused what types are required, and have to look in the code or the PHPDOC's. A lot of effort on our parts also goes into enssuring that our methods are passed the right kind of data. I shall look into this.
Thank you so much for bringing this to my attention!
Rune
Awesome! Haven't tried your Phar yet but it sounds very promosing as this is something PHP really misses so far...