On Tue, 9 Apr 2013 03:08:26 +0100 Mateusz Loskot <mate...@loskot.net> wrote:
ML> > ML> 3) Add /soci/soci folder for all public headers ML> > ML> Installation by copying: cp -a soci/soci /usr/include ML> > ML> will effectively deploy headers buried in /usr/include/soci ML> > ML> > If we do keep src subdirectory it would really make sense to have the ML> > includes in include/soci. ML> ML> Intentionally or not, you seem to suggest the GNU-style layout, aren't you? I didn't know it was called like this but yes, I like separating (public) headers from the implementation files. ML> On the other side, less directory levels makes it easier (quicker) to navigate ML> and easier to search, shorter paths to type, either in console or ML> browsers like NERDTree, or less clicks in IDE. ML> So, here my laziness kicks in :) I don't know about the IDE but having foo.h and foo.cpp in different directories often results in *less* key strokes when typing the path to them than having them in the same one because you can TAB-complete without ambiguity. ML> I find the flattened Boost layout without /include directory a bit friendlier, ML> as /include would only store soci folder, it feels somewhat artificial. ML> There are more sub-folders in /src, just like Boost's /libs, ML> but libs is of no meaning for us. Well, boost layout is really idiosyncratic to boost, I've never seen another project that used it and am willing to bet that those that do have copied it from boost. I have no idea why did they do it like this but most C and C++ projects have either a single directory (which is fine until you start having too many files and I think SOCI does fall in this case) or include and src subdirectories. ML> > But, and sorry for the lack of enthusiasm, it's a bit hard to ML> > be excited about all these more or less trivial changes which nevertheless ML> > risk taking quite some time. Perhaps we could leave the introduction of ML> > namespaces until some unspecified later time? :-) Also, notice that adding ML> > namespaces is backwards incompatible too, e.g. soci::odbc_soci_error I ML> > currently use would need to be replaced with soci::odbc::error... Which, ML> > BTW, doesn't make much sense considering that we have soci::soci_error ML> > instead of just soci::error... ML> ML> In fact, whatever we discuss and decide as planned has unspecified time, My joke clearly fell flat but IME of project management postponing something without specifying a deadline is just another word for not doing it at all. ML> Back to namespaces, ML> I assumed we can forget about compatibilities for SOCI 4 and ML> let to carry away ourselves a bit ;-) ML> Thus, I thought it may be a good idea to structure SOCI into ML> namespaces was perspective some larger number of new types and definitions ML> getting into the codebase. IMHO, namespaces increase quality, make interfaces ML> discoverable and make most aspects of working with code easier on both ends, ML> developer's and user's. I am somewhat sceptical about these claims. Clearly, namespaces are nice, but I hardly see them as revolutionary, they're not very different from the prefixes that all (good) C libraries have been using since 40 years or so. There are 2 practical differences between such prefixes and C++ namespaces: 1. Using directives. This is however unlikely to be useful in SOCI case for the backend namespaces because there are a lot of identifiers with too common names and also because doing this would preclude you from using more than one backend in your code which looks like a bad idea. 2. Koenig lookup. But this doesn't seem to be very useful in SOCI case neither unless I'm missing something. So while namespaces are clearly more elegant and more C++ way of doing things, I just don't see what do we gain in practice. ML> p.s. One thing, traditionally, SOCI never promised ABI compatibility ML> between releases and I personally won't make such promises either. Yes, I agree here, I don't think SOCI is at the stage where this is really important and keeping ABI requires a serious effort. The only thing we need to do at this point is to ensure that different versions of SOCI use different versions in the SO names of the shared libraries under Unix. I don't know if Cmakefiles already take care of this or not. Regards, VZ
pgpHgFDzNH9Qz.pgp
Description: PGP signature
------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________ soci-devel mailing list soci-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/soci-devel
