Monday, January 25, 2016

NamesSpaces and Base Instincts

PHP 5.3 included a new superstructure called "namespaces" that allows people to divide functions (and consequently the people who write functions) into a hierarchical structure.

Just as titles go before the names of Dukes, Lords and Kings. The namespace syntax goes at the top of the function. When the compiler sees the magical word "namespace" it takes a extra step to parse the file and prepend all of the functions with backslash delimited strings to put each function in its place in the the hierarchy.

If I put the line:

namespace Lord\Kevington;

at the top of my code, the program would add the string "\Lord\Kevington\"  to my programs.

If I put the code:

namespace musings\of\peasants;

At the top of your programs; then the compiler would properly encode your work as the musings\of\peasants. The backslash denotes the different layers in the programmatic hierarchy.

If I had a function called said(). The compiler would automagically change the function name to: \Lord\Kevington\said() before compiling the programs.

It would do the same to the \musings\of\peasants ... but ... sorry, while I am thinking of profound things to put in \Lord\Kevington\Said(), I am just not all that interested in the musings of peasants.

The stated purpose of namespaces is to avoid name collisions. Collisions occur when two programmers use the same function name. The compiler balks when the programmers try to combine their code in a single unit and one of the programmers has to change a function name to make the code work.

Now, PHP is a language designed to produce web pages. Web pages require highly optimized code that is executed in a single call.

A good web program is streamlined and a good web developer knows each and every line of code used in the production of the production of the page.

To be frank, if the framework used to create web pages is having problems with namespace collisions, then the proper course of action is to streamline the framework.

And, to be fair, PHP was one of the last programs to implement namespaces. I suspect that a primary reason that PHP implemented namespaces was simply to be consistent with Java and what is taught at the university.

I took a long and serious look at namespaces when namespaces were released with PHP 5.3..

Since namespaces are simply about the internal organization of code and do not in anyway enhance the experience of visitors to my site, I decided not to implement namespaces.

I've noticed a large number of extremely loud voices on Stackoverflow and GitHub pushing namespaces. So I gave them a good second look over these last several days.

Namespaces seem to be preferred tool by the political animals that programmers should try to keep out of the programming department.

The problem of namespaces is that, since namespaces were designed as a meta-element that underlies all of the code in a program, once one person starts implementing namespaces the namespaces soon take over all code.

Namespace technology is very similar in form to the ideologies developed by Hegel and Marx. The technology works at a root level to divide things up so that things can be captured and controlled by a ruling class.

When people set in to dividing things up at a root level, you can become powerful and force your political enemies into subservience.

People who the little reindeer games called "namespaces" are political enemies.

If you are politically ambitious programmer, you can start simply by including namespaces in your projects. This sets you up to becoming the politically powerful keeper of the keys.

The cool part about the game is that, since it takes place at a root level, once the namespace game is started everybody has to play or get excluded.

Namespace technology is a political tool used by base political element of the IT world to decide who gets included and who gets excluded. Sadly, IT Departments are often the hotbeds of interoffice politics.

The keeper of the namespaces is one of the most powerful hacks in an IT department full of hacks because, the person who designs the namespace hierarchy gets to decide who is included and who is excluded.

Isn't that spiffy?!

Of course, the really, really, really funny thing about namespaces is that the technology doesn't actually solve a problem.

Namespaces are as susceptible to name collisions as are all of the other conventions programmers adopted to avoid name collisions. In fact I can guarantee that name collisions will take place.

Imagine a situation where a large project branches. Two groups begin to develop extremely similar code. Anyone that tries to combine elements of these divergent project will have name collisions taking place at both the namespace level and the code level.

Yes, people will try to solve the conflicts by adding layers to the namespaces hierarchy, but each of these layers simply add to the long term administrative cost of the code.

Anyway, I spent the last several days researching namespaces and deciding if I want to use the insipid technology. I hate the technology, but since its a root technology, I know that those that don't play along with the game get excluded.

My heart screams RESIST, while my brain says you must go along to get along. As for now, I will maintain two versions of my code. One that uses namespaces and one that does not and I'll decide later which project to keep and which to ditch.

I really hate these political drones who want the world separated in political hierarchies. All they do is make work while adding no value.

The really funny part about namespaces is that namespaces themselves create

Namespaces and Security

 Note, I haven't examined all of the security ramifications of namespaces. Namespaces allow programmer to create two very similar code bases. (This is not hard to do with the copy command.)

I imagine that one could play some really good jokes on fellow programmers by switching namespaces. What is the difference between:

namespace all;
namespace a11;
Anything that makes it easy to switch code on a project gives me the willies.

No comments: