oop

I am not satisfied with our REST support. Ironic given my role, but there you go. Core's REST support is orders of magnitude better than Drupal 7's, but we didn't go far enough. Despite our best efforts Drupal 8 not truly a REST-first system. Some of that is simple hindsight being 20/20; there's a number of things I would have recommended we do differently had I known 2 years ago what I know now, mostly around decoupling storage and serialization.

Mark said, “I have a personal aversion to being too tied to one tool, so I want to make sure developers are thinking about their career right now but also 5, 10, 20 years from now.” Who can argue against this? At face value, these words are plain and simple and true. I can’t speak for every supporter of Backdrop CMS, but I personally will be learning both. I choose to do this because I can and I believe it opens many doors to what Drupal can do and how it innovates. I was working in Procedural PHP before I found Drupal in 2007.

Traits: Just gimme the codez Enter traits. Traits don't imply a relationship. They're purely code reuse. At runtime, traits no longer exist. They say nothing about an object that uses them, how they behave, what you can do with them, or anything else. They are purely code reuse. In that sense, they are completely orthogonal to interfaces; whereas an interface is purely interface reuse, a trait is purely code reuse.

after a decade as a procedural application with procedurally-minded developers, the transition from an all-procedural to a mixed object-oriented/procedural system is likely to be bumpy, especially for developers who are still new to object-oriented code. While a complete treatment of the entirety of object-oriented programming (OOP) would more than fill this entire magazine, a firm grounding in the concepts and syntax of OOP should fit in just a few pages.

Modules and themes (and engines) would have a namespace such as
namespace drupal\taxonomy;
or
namespace drupal\bartik;
Function prefixes, such as 'taxonomy_' would be dropped.
However, this makes Drupal code really ugly.
Calling functions not in a module from a module would look like this:
\drupal\set_message();
Calling a db function would look like this:
\drupaldb\select('node');
Calling an API function in another module would look like:
\drupal\taxonomy\select_nodes();
The solution? Namespace importing.