On the TutsPlus.com site they've continued their series of posts introducing you to some of the basic functionality included with the PHP language. In this latest tutorial they focus on integers, floats, and number strings and how to determine which you're using.

Working with numbers in PHP seems to be a trivial concept, but it can be quite confusing. It looks easy at first because PHP provides automatic type conversion. For example, you can assign an integer value to a variable, and the type of that variable will be an integer. On the next line, you can assign a string to the same variable, and the type will change to a string. Unfortunately, this automatic conversion can sometimes break your code.

There are a lot of types for numeric values as well. In this tutorial, you'll learn about integers and floats in PHP, as well as the functions which can be used to determine the type of numbers that we are dealing with and convert between them. You'll also learn how to convert integers and floats to and from numerical strings.

The post starts by giving a summary of each of the types - integers and floats - along with the concepts of infinity and NaN. It then covers the use of "numerical strings" in PHP and the automatic type switching that can happen when using them with actual number values. The post wraps up with examples of how to cast values from strings to integers (and back) along with some final thoughts.

Johannes Schlüter has a post to his site detailing the handling of types in PHP and MySQL and how they might act differently than expected in some situations.

Since PHP 7.0 has been released there's more attention on scalar types. Keeping types for data from within your application is relatively simple. But when talking to external systems, like a database things aren't always as one eventually might initially expect.

He talks about MySQL types and how they relate to the "network protocol" being used, converting everything to strings. He includes a few examples of hinting on the results, one where an integer is expected/string provided and another where a string was type hinted but an integer was returned. He points out that sometimes this is a limitation of what PHP can handle, not always what MySQL returns. He also includes other examples of returning decimals - sometimes as a number value and others as a string.

This leaves the question whether you should disable the emulation in order to get the correct types. Doing this has some impact on performance characteristics: With native prepared statements there will be a client-server round-trip during the prepare and another round-trip for the execute.

On the SitePoint PHP blog they've posted another tutorial from Christopher Pitt, this time about macros in PHP, and how you can use the Yay library to add in custom pre-processed macros to your code.

I get really excited when developers feel empowered to create new tools, and even new languages with which to solve their problems. You see, many developers come to PHP from other languages. And many PHP developers can code in more than one language. Often there are things in those languages — small syntax sugars — that we appreciate and even miss when we’re building PHP things.

Adding these to a language, at a compiler level, is hard (or is it?). That is unless you built the compiler and/or know how they work. We’re not going to do anything that technical, but we’re still going to be empowered.

He starts off by describing the goal: a simple "range" macro that creates an array and fills it with integers. He helps you get the library installed and shows how to use it to pre-process a file and output the PHP version. He shows how to create the syntax for the macro in the format Yay is expecting for the array_slice shortcut. He also includes handling letting you slice out a portion of an array using the same notation. Finally he shows the resulting code after the pre-processing has happened and the macros have been resolved.

Joshua Thjissen has a post to his site looking at a relatively common operation in PHP code - incrementing values - but gets a lot more in-depth than just a simple overview.

Take a variable, increment it with 1. That sounds like a simple enough job right? Well.. from a PHP developer point of view that might seem the case, but is it really? There are bound to be some catches to it (otherwise we wouldn’t write a blogpost about it). So, there are a few different ways to increment a value, and they MIGHT seem similar, they work and behave differently under the hood of PHP, which can lead to – let’s say – interesting results.

He starts with the most basic situations, updating known integer values, but shows the curious things that can happen when the same operations are done on strings. He digs down into the bytecode that's generated from these bits of code, showing the order of operations when the code is actually executed. He then gets into more detail on each kind of operator, starting with the unary increment operator then moving on to the add assignment expression and add operator. For each he describes the behind the scenes bytcode actions happening and where in the PHP source code its being handled (and how).

The Paragon Initiative blog has posted a guide to what they see as a way to safely generate random strings and integers in PHP applications.

Generating useful random data is a fairly common task for a developer to implement, but also one that developers rarely get right. [...] It's generally not okay to use a weak random number generator unless both of the following two conditions are met: the security of your application does not depend in any way on the value you generate being unpredictable or there is no requirement for each value to be unique (up to a reasonable probability).

He gives some examples of places where it's a must to use a "cryptographically secure pseudo-random number generator" including generating random passwords, encryption keys or IVs for data in CBC mode. The article goes on to talk about some of the problems that could come from using weak generators. It then gets into the process for generating random values and the use of the random_* functions in PHP (or using this polyfill) to more safely generate the numbers. Included is code showing the process and some advice around converting random bytes to both strings and integers.

In the latest post to the SitePoint PHP blog Vova Feldman shows you how to create an integer from a hash string that's both 64 bit and unique each time it's generated.

PHP provides the popular md5() hash function out of the box, which returns 32 a hex character string. It’s a great way to generate a fingerprint for any arbitrary length string. But what if you need to generate an integer fingerprint out of a URL?

He describes the real-world situation he was facing - a rating widget that needed a randomized integer based on the page using it - and the two "sub-challenges" that make it up: url canonization and the string to unique 64 bit problem. He tackles each problem and shares code snippets showing the process and how it can be put to use. He also includes some interesting metrics at the end of the post showing the level of hash collisions (hint, it's a very low number).

Lorna Mitchell has a quick reminder about an issue in the new joind.in API version - everything was being returned as strings, even integers.

A few weeks later (my inbox is a black hole and it takes a while to process these things) I fell over a throwaway comment to an undocumented constant JSON_NUMERIC_CHECK, and I added the constant name to my todo list. In the time it took for me to actually get around to googling for this, some wonderful person updated the PHP manual page (this is why I love PHP) to include it as a documented option, and someone else had added a user contributed note about using it.

This option, JSON_NUMERIC_CHECK, tells the json_encode function to property consider numbers in its encoding process. It applies globally, so if there's an instance where you don't want something assigned as a number, you might need to go with another, more flexible JSON encoding option. You can find information about this and other possible options json_encode can take on its manual page.

On the XpertDeveloper.com site there's a post reminding you of an date could cause all sorts of problems with your PHP application - the effects of the Y2K38 bug.

Y2K38, or the Unix Millennium Bug, affects PHP and many other languages and systems which use a signed 32-bit integer to signify dates as the number of seconds since 00:00:00 UTC on 1 January 1970. The furthest date which can be stored is 03:14:07 UTC on 19 January 2038. Beyond that, the left-most bit is set and the integer becomes a negative decimal number or a time prior to the epoch.

If you're worried about your application's support for date and time handling, there's a pretty simple fix - replace your current handling with the DateTime functionality. This handles them correctly.

On the SitePoint PHP blog today they pose a question to all PHP developers out there - is your application affected by the Y2K38 bug?

I don't want to be too alarmist, but try running the [given] PHP code on your system. [...] With luck, you'll see "Wednesday 1 February 2040 00:00" displayed in your browser. If you're seeing a date in the late 60's or early 70's, your PHP application may be at risk from the Y2K38 bug!

The bug, caused by a 32-bit operating system, can be helped by running the application on a 64-bit platform (it's due to the limitation of integer size), but there is another option - the DateTime class that handles dates and times differently than the just using the local time settings.

There's been some talk floating around about a proposed additional syntax for creating arrays in PHP. Brian Moon sums it up nicely in a new post to his blog.

So, I was asked in IRC today about the proposed short array syntax for PHP. For those that don't know, I mean the same syntax that other languages (javascript, perl, python, ruby) all have. [...] It just feels like a good addition to the language. It is common among web languages and therefore users coming into PHP from other languages may find it more comfortable.

He compares it with other data type creation in PHP (you don't call int() to make an integer, so why call array() to make an array). However, according to a post from the internals mailing list, we might not be seeing this any time soon.