NYCPHP Meetup

[David Krings]

Kenneth Downs wrote:
> Namespaces are an organizing mechanism, usually associated with classes.
> 
> Think:   Class::functions   as   Namespaces::classes
> 
> So let's begin with functions.  David Krings writes a nifty function 
> called "ValidateEmail()" and puts in a library.  Then Ken Downs writes 
> the same function in a different library.  Somebody tries to use both 
> libraries but gets an error on a naming collision.  If each of us put 
> our functions into classes, and the classes had different names, then 
> the collision would be avoided.
> 
> But what if we have the same name for our classes, such as 
> "EmailUtils?"  You have a class called EmailUtils and so do I, and 
> somebody wants to use a little of yours and little of mine, but there is 
> a naming collision.  Namespaces can solve that.  In this example, my 
> classes might all be in a "kendowns" namespace and yours might be in a 
> "davidkrings" namespace.
> For a more rigorous look, take a look at Java and how its functions are 
> organized.  All functions are organized into classes and the classes are 
> grouped together into namespaces.  If Java needs a function to trim 
> spaces off the right side of a string, they won't call it "RTrim()", 
> they will call it: string.valueChangers.Reducers.Trimmers.Right()
> 
> I'm sure a disciple of object orientation would point out all of the 
> flaws in the above explanation, but it does portray the practical reality.


Thank you for the great explanation. It triggers yet another question: What to 
do if two namespaces are identical? Doesn't that end up to be the same 
problem? And if one changes the namespace for one, doesn't that require to 
change code referencing functions and classes from that namespace as well? 
Sure, it makes collisions less likely, but it really doesn't fix the ultimate 
problem, does it?

David