While every developer has kind of accepted their existence, they are suddenly there when we'd desperately need them to not show up. How often did you writeif($obj === null) in your PHP code? Can't there be a better, more elegant and fault-tolerant solution to the problem?

His solution is to create a PHP version of this "Optional" functionality (via an abstract class) that allows some evaluation of the returned value from method calls on the object. Methods like "isPresent", "getOrElse", "of" and "fromNullable" make it easier to work with null values instead of just the triple-equals checking. He includes not only the code for the classes you'll need to implement it but examples of it in use - an "Optional" abstract class and two child classes, "Present" and "Absent".

We were talking about why some of the SPL Iterators accept only an Iterator as the constructor argument (Such as LimitIterator), and others accept either an Iterator or an IteratorAggregate as the argument (Such as IteratorIterator). Feeling that this would be a useful feature to add (having all of them accept an IteratorAggregate), I opened up the PHP source and started looking at how hard of a change this would be. What I found was... Interesting...

He shares some of the C code he came across in his investigation including a "WTF" moment when he found a case statement for DIT_IteratorIterator in a constructor. Because of some of the logic in this constructor, the inputted iterator is "cast down" to a class. This is shown in a few code examples comparing simple iteration objects and arrays and how it seems to be able to bypass class inheritance to use methods from other classes.

I've been getting increasingly impatient with its tendency to try to escape my SQL code for me - this is a really useful default feature but it seems to assume I don't know what I'm doing and so it puts backticks all over perfectly acceptable SQL code, very annoying!

Thanks to a reply on twitter from damiangostomski to her frustrations she found the optional second parameter you can give the "select()" method, a boolean that tells it whether or not to escape the query (it's mentioned here) for those that were wondering.

If you think that the maxlength parameter in the documentation of oci_bind_by_name is optional, see this example and think again.

His sample code gave him a "can bind a LONG value only for insert into a LONG column..." error from his Oracle database. His fix was to add that length parameter (his max column length) and all was well. One of his comments (from cj) helps to explain things a bit more:

It makes senses that a length would be required because when the oci_bind_by_name() call is made, there is no data in $$key (a.k.a. $a, $b or $c). Without a length passed, PHP tells the DB to expect a single byte string.