This is especially true when you’re writing a library which is meant to be absorbed into a larger codebase, but also true of a codebase in which you know you will be using foreign libraries to accomplish tasks. And I’m as guilty as anybody when it comes to this!
When you are naming your functions and classes be mindfull of the possibility of collision. I think that we (as a group of programmers) are generally mindful of this when we lay out things like our database schema, but can overlook this when we’re writing our libraries.
For example a class/function name of something like “database” seems good ad first glance: It’s clear, to the point, and descriptive (okay… *somewhat* descriptive). However consider that anyone who’se writing anything even remotely related to a database (and these days what *isnt* tied to a database?) will think to themselves at one point “hmm if i name the class database, it’ll be short enough not to be annoying to type, long enough to describe what its used for, and no one’s going to think its used for processing text strings!”

So, now, its possible that every library has a right to use this class name for their code because of its qualifications. But then you will be limited to only using one persons external libs (assuming that your internal libs arent already using it)

What we *ought* to do is, for our project Foo, call the class “databaseFoo”, then we can simply use something like $database = new databaseFoo; and we loose basically nothing, and be assured of compatibility with other libs.

DK