Deprecate Magic Constructors in PHP

Along the lines of the argument to make code easier to understand for quick readers, I want to propose something a little less radical and just as useful for devs: Deprecate the magic `__construct()` function.

The PHP community is currently voting on whether or not to deprecate var in favor of public for classes starting in version 7.1. This is an interesting idea, to say the least, but the arguments against it are even more compelling.

So there’s a small mental tax for a human to read and interpret the entire line. It’s generally accepted that shorter lines are better, and when ‘scanning’ a file from top to bottom, it’s better that the important keywords (the name of the function) are closer to the left-edge of the screen.

Along the same lines of this argument – to make code easier to understand for quick readers – I want to propose something a little less radical and just as useful for devs: Deprecate the magic __construct() function.

Rationale: It’s Ugly!

PHP is one of the easiest-learned languages available for fledgling developers. Documentation is deep, code examples exist just about everywhere, and it’s such a flexible language that you can write horrible code and have it still just work.[ref]I’ve seen bugs in PHP code only surfaced and fixed when the maintaining dev team has started refactoring the code for a new system like Ruby. The old bug had been there for years without impacting the function of the application. Isn’t that awesome?![/ref] But we still have certain “magic” functions in our code layer that make things harder for non-experts to understand.

I’m looking at you, __get(), __set(), and __construct().

The getters and setters can easily be ignored by merely making everything public to begin with. After all, even internal var properties are public by default, so why even use a getter? It’s just additional OO cruft added to confuse newcomers.

Reading through a class quickly, catching the reference to a __-prefixed magic method can be difficult. It makes a developer pause to consider what they’re doing. It’s even more confusing since, traditionally, leading underscores used to mark a method as “private.” With a double underscore, it almost makes it look like the constructor is “double private.”

And who ever wants to call MyClass::__construct() to build an object? That’s just nonsense!

Alternative

Instead, we should introduce a completely new paradigm in future versions of PHP that support a constructor named identically to the class itself:

When you read that code, it's obvious the function is the constructor because of their shared name. You'd never want to write MyClass::MyClass() - that would just look dumb - so remembering to use the new keyword for instantiation is an intuitive bonus this pattern wins for us.

Thoughts?

Once we get the ball rolling with removing the ugly __construct() setup, we can start targeting the other magic methods and truly make PHP an accessible language for even those who don't know how to write code. That's the dream of programming, after all.

What other features of PHP should we drop as we move forward with future versions?

#