On the Laravel News site there's a new post about a feature in the v5.5 release of the popular framework: pivot casting.

A new addition to Laravel 5.5 will add support for pivot table casts when inserting & updating data on an intermediate table model.

Currently, the $casts you set on a traditional model will work in both directions; any model that extends the EloquentModel class will look for a $casts property and convert the specified attributes to a data type when reading and writing.

[...] Now with Laravel 5.5, the $casts property on the EloquentModel and EloquentRelationsPivot classes will behave the same. Laravel will “respect” your casts on both, whether you’re reading, inserting or updating data.

In a new post to his site Anthony Ferrara takes on the topic of typing in PHP, discussing some of the main ideas around the current typing scheme and the discussions being have about potential changes.

There has been a lot of talk about typing in PHP lately. There are a couple of popular proposals for how to clean up PHP's APIs to be simpler. Most of them involve changing PHP's type system at a very fundamental level. So I thought it would be a good idea to talk about that. What goes into a type?

He starts at the highest level, covering what "typing" is in general and some of the tradeoffs that come with being a strongly typed versus weakly typed language. He then gets into PHP's two "semi-independent type systems" - one for objects and one for everything else. He includes some code examples to illustrate and how, for the non-object handling, context means everything for how the types are switched. He also talks about polymorphism, the chaos that could come from scalars becoming objects and a current RFC suggesting the addition of "safe casting" functions to PHP to provide less "magic" when shifting values from one type to another.

Christian Weiske had an interesting situation pop up in one of his applications around a call to a variable with an interesting name.

Some days ago I saw the following fatal error for the first time in my life:

Fatal error: Cannot access property started with '\o' in file.php

After some debugging, I found out that the source of the error was not some strange BOM or UTF-8 characters in PHP source code files. No, it was a combination of protected class properties, object-to-array casting and automatic template property mappings.

As it turns out, there was a change in how object-to-array casting was done in PHP 5.3 that made this break (related to things appended to private and protected variable names). He includes a bit of sample code to illustrate the problem - a simple class converted from object to array with direct casting. He does point out that it doesn't happen with get_object_vars, though, as that doesn't do the casting, just extraction.

Anthony Ferrara has a new article posted to his site today about parameter typecasting and the discussions that have been happening about it on the PHP "internals" mailing list.

As any of you who follow the PHP internals list know, scalar type hinting has been a hot topic as of late. You'll also know that I've submitted two new RFC (Request For Comment) proposals for inclusion of two new major features in the PHP language. I figured it was worth going into both RFCs and patches a little deeper, explain my rationale and (hopefully) garner some more visibility of the proposals.

He shares the details of the two main RFCs that are proposed right now - parameter type casting hints and object scalar casting magic methods (both with code examples). Right now, they're only in the patch stage and there's talk of improving the current casting functionality of PHP before something like one of these goes into place.

David Otton has a handy little tip if you're looking for a cleaner way to deal with array data - casting it to an object.

Array notation is fine, but it can look a bit clunky when you're working with complex structures. [...] Casting the array to an object allows us to use object notation (->) and makes the code more readable.

He includes examples of the casting, showing the difference between the array and object notations including a method for creating an object based on a simple array that has basic properties built in. This sort of transformation can be useful if you want consistency through out the application - just passing objects with their properties rather than arrays.

In this blog entry Arnold Daniels talks about an issue he had in the past (needing a bit more functionality than the PEAR DB library could offer) and how he ended up solving it with what he calls a "dark corner" of PHP - class casting.

PHP has a function serialize, which can create a hash from any type of variable, scalars, array, but objects as well. Using the unserialize function, PHP can recreate the variable from the serialized hashed. If we look at how an object is serialized, we see only the properties and the class name are stored.

His method allows for class manipulation via changes to the serialized class information (like changing the value of the name parameter). His "casttoclass()" function makes changing this value simple.

In a new post, Christopher Jones talks about some difficulty a friend of his was having with returning a connection type from Oracle back to a script. In his case, it was a Ruby script and, unfortunately, there's no direct support for it. So, Christopher jumped in to help out.

PHP's oci8 extension oci_bind_array_by_name() can bind collections but there is no equivalent in ruby-oci8.

Justin outlines a solution on his blog Ruby: Invoking a PL/SQL Package with Array args. His example relies on some company infrastructure so I came up with this standalone example. This first SQL*Plus script sets up the scenario.

Stick with me on this one - there's some PHP right there at the end. He shows how much simpler the same kind of operation would be in PHP thanks to the oci_bind_array_by_name functionality understanding the return value. What took about 20 lines for just the Ruby code to handle the result correctly takes only five in PHP.

In a new post, Christopher Jones talks about some difficulty a friend of his was having with returning a connection type from Oracle back to a script. In his case, it was a Ruby script and, unfortunately, there's no direct support for it. So, Christopher jumped in to help out.

PHP's oci8 extension oci_bind_array_by_name() can bind collections but there is no equivalent in ruby-oci8.

Justin outlines a solution on his blog Ruby: Invoking a PL/SQL Package with Array args. His example relies on some company infrastructure so I came up with this standalone example. This first SQL*Plus script sets up the scenario.

Stick with me on this one - there's some PHP right there at the end. He shows how much simpler the same kind of operation would be in PHP thanks to the oci_bind_array_by_name functionality understanding the return value. What took about 20 lines for just the Ruby code to handle the result correctly takes only five in PHP.