In a new post today C. Sadeesh Kumar has a quick tip to help your script detect file types without having to rely on the extension to be correct.

In most web applications today, there is a need to allow users to upload images, audio and video files. Sometimes, we also need to restrict certain types of files from being uploaded - an executable file being an obvious example. Security aside, one might also want to prevent users from misusing the upload facility, e.g. uploading copyrighted music files illegally and using the service to promote piracy! In this article, we'll look into a few ways in which we can achieve this.

The trick to his example is in using the Fileinfo PECL extension. With the help of this extension you can look inside the file and pick out the "magic bytes" (the first few bytes of a file) and see what MIME type the file really is. He includes a simple example of using the extension on a file and a file upload script that checks the type and handles the file accordingly.

In the second part of their series looking at data typing in PHP, the WebTutor blog takes a different approach to supporting strong typing in PHP, using autoboxing and indestructible objects.

In an earlier article on the strong typing I've described the typehint mechanism that provides data type enforcement for the values sent to the methods and functions. Unfortunately said implementation does not protect against another problem associated with the dynamic typing of variables: a lack of type enforcement when overwritting value of an existing variable. In order to control the type of data, I decided to introduce to PHP the concept of autoboxing known from other languages such as C# and Java.

He talks briefly about what autoboxing is (wrapping primitive types into objects automatically) and links to a library that can be used to accomplish it. A bit of sample code is included showing how to create an AutoBoxedObject and how to use it in practice on some string values.

Christian Weiske has a recent post to his site looking at something most PHP developers don't even think about when serving up their scripts - the MIME types for PHP files.

While setting some svn properties at work, we wondered about the correct MIME type for .php files.

He found several in the official IANA list including "text/php", "application/php" and "application/x-http-php" - all valid but none of them considered a standard. He talks about the ones supported by linux distributions (like Debian/Ubuntu) and some reasoning that might make "application/php" the best choice of the list. He points out some downsides to the choice, though, including the fact that something starting with "application/" should considered "machine readable" only despite PHP just being text.

Gonzalo Ayuso has a new post to his blog today talking about a regular expression-laden script he's some up with to reflect over a PHP file and pull out the document's comments (PHPDoc-style).

I want to parse PHPDoc code. Let me explain a little bit what I want to do. Imagine a dummy function documented with PHPDoc. [...] PHP has a great reflection API, but as at least in the current PHP version (as far as I know) we only can get the PHPDoc as a string, without parse it. I need to get the parameters and the type of them with reflection. [...] But the type is different.

His script (based loosely on a bit of a component from the Zend Framework) parses the file and its comments and grabs the variable types from the PHPDoc blocks on each method and associates them.

If you're looking for a more mature solution than just this script, take a look at Docblox, a PHP 5.3 documentation generator.

Kevin Schroeder has a new post to his blog today about dynamic typing (a big part of PHP's variable handling) and how it has nothing to do with scalability in reply to some comments about how using them can hinder the performance of an application.

Every once in a while I inject my opinions into places where they are not welcome. I have heard from people in the staticly-typed realm of how amateur dynamic typing is. Some people are interested in understanding how to use dynamic typing, others, not so much. So what I would like to do is talk about some of the arguements made against dynamic typing. Clearly PHP will be my reference point, but many of my points will be salient across many dynamically typed languages.

He dispels some of the myths surrounding PHP's dynamic typing. He points out that PHP isn't always dynamically typed, that bad things can happen with compiled code too and that bad or missing validation of data isn't a reason to jump all over variables that could shift types.

In the theme of other recent posts mentioning the scalar type hinting that has been included in the main line of code that is headed towards the next PHP release, Sebastian Bergmann has a new post about their inclusion in PHP 5.3.99 (yes, that's PHP 5.4) and the new syntax it introduces.

In a nutshell, this means that PHP 5.3.99 introduces new syntax -- scalar type hints -- but no new semantics. The latter can either be implemented as an extension written in C/C++, in userland PHP code, or in a tool that statically analyzes the code.

He includes an example fro userland with a "php_check_parameters" function that looks at the arguments of the current method and uses Reflection to check against the type hints for the correct value type.

Johannes Schluter has posted a bit more information about the scalar type hinting that's been included in the main development line of the PHP language (trunk).

Some time ago I wrote an article about the implementation of type hints for non-object types for PHP. Meanwhile many things happened and that implementation was replaced by a different one. Readers of my previous post might know that I have doubts about type hints in PHP.

He shows some of the example syntax for the hinting and points out how, in one case, there's no error thrown when the type hint is a native one but an error is thrown on a custom type hint.

So why is there a syntax added which is ignored? [...] Well, I let it to you to decide whether it make sense to have two syntaxes which look the same but do very different things (being ignored vs. throwing a terminating error) and whether it makes sense to push a system where the core language behaves differently depending on the system. [...] I seriously hoped PHP was out of the era of introducing new inconsistencies.

As Johannes Schluter mentions in his latest blog post, another new feature has been added to the trunk of the PHP project - scalar type hints.

So in my blog series I try to cover all additions to PHP trunk so I have to mention scalar type hints.

He gives examples of both simple hinting (ensuring a value is a float) and a more complex example setting an attribute on a PDO connection (checking for an integer). Sample error messages are included as well. He also gives some advice on mixing strong and weak typing in your apps - it's like "opening a can of worms".

Ilia Alshanetsky has a quick new post with some great news for some PHP developers out there - scalar type hinting has been introduced into the latest trunk of the PHP project.

About an hour ago, something I've been fighting for almost 2 years happened. The Scalar Type Hinting patch for PHP (the one I wrote almost a year ago) has been adjusted for PHP's trunk tree and committed by Derick.

You can see some of the type hinting features already included in PHP in the manual. This patch adds hinting ability for the other (non-object and non-array) variable types.

Etienne Kneuss has posted about a dataflow type analysis tools he's created that models code as control flow graphs.

It will assign types and let them flow through control structures. When reaching stability, it will check that the operations done of the values are sound type-wise. It will also do some structural checks.

There's some more technical details here and a presentation here but if you want to get at the code, you can grab it off of the project's github page.