On the Laravel News site there's a new tutorial posted showing you how to use the "optional" helper and closure to help control issues where a property or method doesn't exist (or can't be accessed).

The Laravel Optional class and accompanying optional helper were introduced in Laravel 5.5. This class is useful to avoid those pesky Trying to get property of non-object errors in your code.

Joseph Sibler submitted an improvement to the Laravel optional helper that we covered in Laravel 5.6.13 which now allows a closure that is only called when the object is not null

They compare the "optional" functionality to the null coalesce operator and the cases when the former should be used over the latter. A few code snippets also help to illustrate the difference. For more information about this helper and other handy features, check out their other article with a "top 5" list of their favorite helpers.

Robert Basic has a quick post to his site sharing a method he uses for creating datetimes from a format with a timezone. In his examples, he makes use of the createFromFormat handling in PHP's DateTime functionality to more correctly handle processing strings with timezone offsets rather than a DateTimezone parameter.

I wouldn’t be writing this blog post if I’d read all the “fineprints” in the PHP manual. Alas, here we are.

The DateTime and DateTimeImmutable classes have a createFromFormat method. As you can probably guess from its name, it creates a datetime object from a datetime string formatted in the specified format. [...] When the format has a timezone offset though, that’s… the part I skipped in the manual.

He found that the createFromFormat handling ignores the provided timezone as the optional third parameter if there's an offset included with the date/time string to parse. No error is thrown, it just silently ignores the third parameter and sets the "timezone" value of the resulting object to an odd value.

The MyBuilderTech.com site has a new tutorial posted talking about the use of traits and magic methods for optional value handling.

Recently I have been interested in experimenting with different ways to handle optional values. Their are many examples that exist demonstrating the use of the Maybe/Optional structure within the PHP landscape. I would instead like to focus my attention on only looking into the concept of 'orElse', which I have found to be a prominent control-flow whilst using these types of value. Typically, in an imperative mind-set we are accustom to evaluating a value, and based on its existence - defined as falsely in this regard - follow a different course of action, and by-way result.

He gives an example of where a value is checked for null and something else happens when it is. This is a common practice in PHP development, but he's more interested in other ways of handling. The first of these ways is with traits. His example shows an "OrElse" trait that can be used to perform the same evaluation but does some extra magic based on the method name called (his example is "findByIdOrElse"). If the trait method isn't for you, he also offers another possible solution around the use of composition. In this case he uses the same trait but makes it a part of its own class that's then given the object to work with (his "repository").

The post ends with one more "bonus" method for handling optional values - a simple function ("_or") that evaluates the arguments given and returns the first that's "truthy".

In his latest post Matthias Noback suggests the idea that there's no such thing as an optional dependency when it comes to working with packages and Composer.

On several occasions I have tried to explain my opinion about “optional dependencies” (also known as “suggested dependencies” or “dev requirements”) and I’m doing it again: "There’s no such thing as an optional dependency." I’m talking about PHP packages here and specifically those defined by a composer.json file.

So that everyone's on the same page, he starts with an example of a true dependency in a sample adapter class. He asks the usual question - "what's needed to run this code?" - and looking a bit deeper at the "suggested" packages. As it turns out, some of these dependencies turn into actual requirements when you need certain features of the tool. He points out that this is a problem with quite a few packages in the Composer ecosystem and proposes a solution - splitting packages based on requirements. He gives an example based on his adapter with a Mongo requirement split off into a "knplabs/gaufrette-mongo-gridfs" package that's more descriptive of the requirements.

Michael Nitschinger has written up a post looking at avoiding nulls in your applications in favor of a better kind of value handling - the introduction of "Optional" handling.

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".

Anthony Ferrara has a new post to his blog sharing some inconsistencies with iterators that he discovered as discussed with a fellow developer - why some iterators only accept Iterator arguments and others don't.

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.

In a project she's been working on Lorna Mitchell was frustrated with something the CodeIgniter framework does natively - escape SQL statements done through the databaase layer's "select()" method. Thankfully, there was a simple fix to turn this behavior off.

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.

Harun Yayli came across a slight problem in his development using the oci_bind_by_name function for one of his queries:

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.