OpenFrameworks Namespace?

feature requests
#1

Hm, is there any particular reason for not putting the api into a namespace instead of the ‘of’ prefix? Unsupported on a target compiler? just…general dislike for them?

It’s not a huge problem, but there is a risk of collisions, and generally polluting the global name space as well as the “of” does hurt readability slightly.

If you were to introduce them, the change to applications could be as small as one line, even if you don’t remove the “of” from the front of the API calls, it still holds some benefit.

#2

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

take are,
zach

#3

In response to (a), it’s possibly to hide it completely, if simplification were the goal, by just doing “using namespace OpenFrameworks;” at the end of ofMain.h which would be very similar to how it’s set up now, except that you give the application the ability to differentiate between two ambiguous calls.

If it’s just a subjective matter, I can’t really argue either way, I wouldn’t say of::Circle() or even of::ofCircle() is any less legible if you wanted to really explicitly use the namespace, though this would more be a matter of compatibility.

I think just including the namespace is a decent idea even if you don’t change the API calls at all, I’m sure you don’t have any collisions currently, or with other libraries, but as a hypothetical, imagine that you implement something that was once in an addon and bring it into core, but don’t bring that whole addon into the core of OF, people might still want to use a different part of the addon. Then someone might end up with a problem and the only way to solve it would be for people to delete one versions from either the addon, or from OF itself.

Ideally addons would be using their own namespaces, but even if the difference between yours and theirs was that yours was in OpenFrameworks:: and theirs was in Global, then an application has an easy way of resolving it.

#4

Knowing where things come from is extremely useful to me. It reads much better. Many people suggest using namespaces this way with the namespace in front of every symbol. Personally I prefer using ofRect over of::rect. Latter is more flexible but then again this is why c++ is so hard. It is endlessly flexible and everybody end up doing things differently.

One thing that might be useful in the future is placing the entirety of OF in a namespace and then just merging it with the global one in the main.cpp. This way when people run into collisions they can remove the merge and have better control of the global symbols.

#5

[quote author=“stefanix”]Knowing where things come from is extremely useful to me. It reads much better. Many people suggest using namespaces this way with the namespace in front of every symbol. Personally I prefer using ofRect over of::rect. Latter is more flexible but then again this is why c++ is so hard. It is endlessly flexible and everybody end up doing things differently.

One thing that might be useful in the future is placing the entirety of OF in a namespace and then just merging it with the global one in the main.cpp. This way when people run into collisions they can remove the merge and have better control of the global symbols.[/quote]

Well the good thing about the using statement is that you don’t need to remove the merge to explicitly declare where the symbols are coming from, you can just explicitly use the namespace. For instance.

  
  
#include <iostream>  
  
namespace Blah   
{  
	const int myInt = 1;  
	const int blahInt = 2;  
}  
  
namespace OpenFrameworks  
{  
	const int myInt = 3;  
	const int ofInt = 4;  
}  
  
	const int myInt = 5;  
  
using namespace OpenFrameworks;  
using namespace Blah;  
  
//--------------------------------------------------------------  
int main(){	   
  
	std::cout<<Blah::myInt<<"\n";  
	  
	std::cout<<OpenFrameworks::myInt<<"\n";  
  
	std::cout<<blahInt<<"\n";  
  
	std::cout<<ofInt<<"\n";  
  
	std::cout<<::myInt<<"\n";  
}

gives the output 1,3,2,4,5