search

eidheim / tiny-process-library

A small platform independent library making it simple to create and stop new processes in C++, as well as writing to stdin and reading from stdout and stderr of a new process
MIT License
338 stars 73 forks source link

C++ namespace? #20

Closed kainjow closed 7 years ago

kainjow commented 7 years ago

I just realized the Process class is in the global namespace. Maybe one should be added, to limit scope, since "Process" is fairly generic.

eidheim commented 7 years ago

I decided to drop a namespace since this library only contains one class, but you are right, we should probably have a namespace. Now the main problem is what we should call this namespace.

kainjow commented 7 years ago

You could use your username.

ghost commented 7 years ago

tp as TinyProcess?

grasmanek94 commented 7 years ago

eidheim::tpl::

tp itself is too generic and I would appreciate if it were avoided (to avoid conflicts if anyone ever decides to use tp anyway).

eidheim commented 7 years ago

Thank you for your suggestions, but how about Tiny::, TinyProcess:: or TinyProcessLibrary::? I'm leaning towards Tiny:: but this namespace is too generic as well, maybe my vote goes to TinyProcess::. Also, I'm used to CamelCase in class/class like names (like namespaces) and snake_case elsewhere, but not sure how common this is anymore.

foonathan commented 7 years ago

I'd say you go for a longer namespace name, users can alias it, if they want.

grasmanek94 commented 7 years ago

Well my stance would be, if the namespace begins with something unique to each developer (e.g. boost uses boost, other developers use username or some mainproject namespace) then what comes after I totally don't mind. be it tpl or Tiny or TinyProcess or TinyProcessLibrary or tp or tiny_process.. :) tp could be a 'shot myself in the foot' choice in the future.. for example if you make a ToiletPaper library! (that could be tp or tpl too)

Also what if you make a large process library one day? :) uniquenamespace::process::large / uniquenamespace::process::small would be smart future proof choices as well.

In most cases I just do using whatever_i_preffer = some::other::namespace anyway, probably other devs too, so you shouldn't sweat too much on coming up with a name. Pick with a dice roll if you really can't decide.

foonathan commented 7 years ago

Well, that's what I think, too: http://foonathan.net/blog/2016/01/26/namespace-alias.html ;)

eidheim commented 7 years ago

Alright, I think I have finally decided: TinyProcessLib

That is, I'm going with Gtkmm/Gdkmm/Glibmm's CamelCase for namespaces and classes, and snake_case elsewhere. TensorFlow for instance uses lowercase for namespace and Gtkmm/Gdkmm/Glibmm style elsewhere, which looks a bit weird, but then again LLVM uses the same style as TensorFlow. My argument is that namespace and class/stuct are somewhat related, but feel free to argue with me on this!

Now the next question is, since we now would kinda break backward compatibility, should we bump the version to v2.0.0, or is v1.1.0 enough in this case?

eidheim commented 7 years ago

And I forgot: thank you all for your valuable input!

kainjow commented 7 years ago

I say go 2.0 to keep semantic versioning.

eidheim commented 7 years ago

Would have to bump to 2.0 yes, and sorry for this taking so long. I'm currently considering if there are other backward compatibility breaking things I would like to do before a major version bump. And of course I'll do a minute version bump release before this happens.