Results tagged “PHP” from Blog of Max Horvath

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 alias bool)
• float (including aliases double and real)
• integer (including aliases int and long)
• object (generic object matcher)
• resource
• string

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.

As PHP 5.3 is marching towards the final release, Eclipse PDT's next version needs to support its new features. Two major additions to PHP 5.3 are namespaces and bundling the Phar extension. Especially used in combination, libraries could/should be distributed like Jars in the Java world.

The Phar extension provides a way to put entire PHP libraries or applications into a single file called a "Phar" (PHP Archive) for easy distribution and installation. Phar archives are best characterized as a convenient way to group several files into a single file. As such, a Phar archive provides a way to distribute a complete PHP library or application in a single file and run it from that file without the need to extract it to disk. Additionally, Phar archives can be executed by PHP as easily as any other file, both on the command line and from a web server. Phar is kind of like a thumb drive for PHP applications.

PHP 5.3 and Eclipse PDT 2.0 will soon hit the street

With Eclipse PDT 2.0 to be released in September (or October) support for namespaces is already on the roadmap. Support for Phar archives has not been listed, yet. But in my opinion Eclipse PDT 2.0 must support handling Phar archives when PHP 5.3 will hit the street.

Playing around with PHP 5.3 HEAD and Eclipse PDT 2.0 HEAD I've discovered several drawbacks of the yet missing support for Phar archives - here are the most important ones:

• You cannot browse Phar archives.
• Because of the disability of Eclipse PDT 2.0 of browsing Phar archives you cannot see in the outline which classes are inside of the Phar archive.
• You cannot debug Phar archives. (Eclipse won't open a Phar archive.) (Using Xdebug or Zend Debugger does not change the situation.)

Debugging Phar archives using Xdebug is still an issue with the current stable release (Xdebug won't return enough information to browse the Phar archive), but Derick is already working on solving that issue. I didn't try the Zend Debugger - I don't even know if it runs with PHP 5.3.

Requirements for the Phar support are still to be defined

So opened an feature request at the Bugzilla issue tracker of Eclipse PDT. Roy Ganor, the team leader of the Zend Development Tools Group, responded quite fast and said, that the development team of Eclipse PDT already talked about the support of Phar archives but couldn't decide on requirements.

He asked me to help out and define proposals for requirements in a PDF file or the Eclipse PDT wiki.

Before providing proposals for requirements of the support of Phar archives for the next version of Eclipse PDT on my own, I wanted to ask the PHP community (especially those using Eclipse PDT / Zend Studio for Eclipse), what kind of Phar support they would like to see in Eclipse PDT 2.0.

Please do not hesitate on responding /commenting on this article, as there's not much time left before Eclipse PDT 2.0 shall hit the streets - and I wouldn't like to miss Phar support in this great IDE.

While it's absolutly correct that direct access to private properties is strictly forbidden in PHP, it's quite disturbing that even reflection cannot do it when you're writing Unit Tests. Sometimes you just want to test whether a private property contains the correct data. With the normal visibility rules you cannot access those from your Unit Tests.

Luckily, as I just read at Tobias Schlitt's Blog, Derick Rethans committed a patch to the PHP 5.3 repository, which allows you to get things done quite easily. You still need to explicitly state that you want to access the value of a protected/private property through reflection by the new method setAccessible(). It's a good thing to avoid people doing stupid things accidentally, but you finally get the access to it.

PHP 5.3 you'll be able to access private properties like this:

But until we'll see a stable PHP 5.3, there we're many working "hacks", which worked for some versions of PHP 5.x - the most current one would be this:

This should get you up and running for PHP 5.2.5 ("older hacks" won't work).

So how could you use it?

I hope those lines of code will help you until PHP 5.3 arrives, as it helps our developers.

Update

As Sebastian points out in his comment to this post, PHPUnit has had support for testing private and protected attributes for quite a while. It can be used via:

I should be reading the documentation much more thoroughly next time (even though I must admit, that none of our developers has known this method, too).