we’ve thought about it – and decided against it, for several reasons:
a) we’ve tended to shy away from c++ constructs that make it harder for non c++ programmers to get into the language, ans espeically, to feel comfortable looking through and using the OF code. For example, we try to avoid using templates, and more “fancy” aspects of c++, to make the OF codebase easier to read and get into.
b) as in (a) alot of our design choices are about minimizing compiler errors, since this is the biggest stumbling block for beginners - not knowing how to read or interpret syntactical errors. I think adding a namepsace requirement to use OF would bring errors that are hard to understand. I know from my own experience being very frustrated trying to get namespaces to work properly. I understand how valuable they are, but at the same time, we spend alot of energy and time fixing errors for people, so I’d be personally worried about this…
c) we are a bit old school, raised on opengl, so calls to opengl (glVertex…) make alot of sense to us. the same thing is true with OF - it’s clear looking at the code, that’s an OF call, that’s an opengl call, etc. By dropping the of, we’d risk making things alot less clear. I actually think it would hurt legibility, for example:
ofCircle vs circle
ofRect vs rect
if you look at a snippet of code, you might not know that this is openframeworks code. We do not use of as a prefix inside of objects (draw, getPixels, etc) since these are part of an “of” object.
d) Since ©, we will continue to use of as a prefix, and because of that, we don’t seem to have any collisions. If we do wind up having collisions, I think it’d make sense to consider using namespace.
It’s not the first time we’ve been asked about this and it’s definitely worth considering. It just hasn’t proven to be an issue yet. If there are other namespace advocates, I think’d it’d be nice to hear more. I think this is an open question for the future… thanks for bringing it up