Tuesday, 14 October 2014

I'm all about the context

Fig 1. Meghan Trainor
PHP is a dynamically typed language written in C, C is anything but dynamic. So then, in some sense variables are not dynamically typed, so why, when at least some of the infrastructure exists to allow users to work with types, do we always stop short of actually allowing it.

This morning I'm going to try to explain the obsession with context, even justify it.

What really makes PHP "dynamic" ?

We stop short of exposing the strict typing that already partly exists in internals because the thing that makes PHP a dynamic language, is its ability to coerce the type of a variable depending on the context the variable was used in.

This is, in practice, what makes PHP dynamic, it is the reason that a function expecting a string can accept an integer and still continue executing.

What could change that ?

There are some RFCs and ideas floating around the community that, on the face of it at least, would be brilliant for PHP, they really solve problems.

The first example is scalar type hints, this subject has been in RFC many times, in many different forms.

The strictest forms, when the implementation will cause Zend to barf if the wrong type is passed are always flat out rejected. That's obviously an approach that is far too strict for PHP.

Other patches exist for scalar hints that perform the same kind of coercion as Zend does for internal functions, this seems to be the most suitable implementation, but even still can create unexpected behaviour because of the way Zend currently performs coercion.

The solution to this problem is likely to fix the way Zend performs coercion first, so that coercion performed by internal and user functions are always the same, and both are more intuitive.

Another, more complicated example is the Scalar Objects work done by Nikita Poppov.

I love this idea, it does solve problems, however it causes some too: what should happen if you call ::length() on an integer ?

Today, strlen will accept an integer and treat it as a string, because in the context of a call to strlen, the first parameter is a string.

There doesn't seem to be a reasonable way around this, so that if we introduce this kind of functionality in core in its current form, we are undoubtedly changing the nature of PHP. Not quite changing from dynamic to strict, but we're changing it, blurring the line even further.

Being PHP, hopefully means remaining dynamic

There probably are solutions to the problem of introducing the kinds of things experienced developers seem to want, while keeping PHP as dynamic as it is today. But, we should think very carefully before getting behind something that is only good for a very very small percentage of us.

Easy to get started has all kinds of positive, very valuable, knock on affects. You could argue that this effects how easy it is to train new developers, how easy it is for new teams to reach productivity, how easy it is for a project to actually succeed.

Since being dynamic and easy appear to go hand in hand, we should value the current dynamic nature of PHP, as much as we value how easy it is to get going.

1 comment:

  1. > But, we should think very carefully before getting behind something that is only good for a very very small percentage of us.

    I think this is key to resolving the scalar type hinting drama.

    The problem is that neither the internals list nor the community in general can agree on a single solution. Yet (at least on php-internals) everybody is still looking for the silver bullet. I don't see how that could ever work out.

    ReplyDelete