Closed kainjow closed 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.
You could use your username.
tp
as TinyProcess?
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).
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.
I'd say you go for a longer namespace name, users can alias it, if they want.
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.
Well, that's what I think, too: http://foonathan.net/blog/2016/01/26/namespace-alias.html ;)
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?
And I forgot: thank you all for your valuable input!
I say go 2.0 to keep semantic versioning.
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.
I just realized the Process class is in the global namespace. Maybe one should be added, to limit scope, since "Process" is fairly generic.