On 9 April 2013 02:01, Vadim Zeitlin <vz-s...@zeitlins.org> wrote: > On Tue, 9 Apr 2013 01:39:29 +0100 Mateusz Loskot <mate...@loskot.net> wrote: > > ML> Here are some of the revolutions [2] dangling in my head > ML> that I would like to propose and discuss: > ML> > ML> 1) I'm going to remove /soci/build as deprecated legacy > ML> and move /soci/www out to SOCI/soci.github.com reposiory. > > Either this or moving cmake files under /build would make sense.
cmake at top level is a very common approach (i.e. clang), so I'd like to keep it there. > ML> 2) Move content of /soci/src one level up > > I'm not sure about this, having src and doc as siblings is pretty standard > and I don't see any pressing reason to change this. Of course, I'm a bit > biased here as we use our own build system for SOCI so this change would > mean that we need to change it to adopt to the new file paths and, as any > aspiring good programming, I'm naturally lazy [1] and would rather avoid > doing something that doesn't seem to have any clear benefits. > > ML> 3) Add /soci/soci folder for all public headers > ML> Installation by copying: cp -a soci/soci /usr/include > ML> will effectively deploy headers buried in /usr/include/soci > > If we do keep src subdirectory it would really make sense to have the > includes in include/soci. Intentionally or not, you seem to suggest the GNU-style layout, aren't you? Generally, I have no problem with it and I have introduce /src + /include layout myself in projects (i.e. http://svn.osgeo.org/geos/trunk/). On the other side, less directory levels makes it easier (quicker) to navigate and easier to search, shorter paths to type, either in console or browsers like NERDTree, or less clicks in IDE. So, here my laziness kicks in :) I find the flattened Boost layout without /include directory a bit friendlier, as /include would only store soci folder, it feels somewhat artificial. There are more sub-folders in /src, just like Boost's /libs, but libs is of no meaning for us. > ML> 4) Add /soci/tests directory > > Yes, having tests in their separate directory would definitely be more > tidy and allow finding them immediately. Once I (or we) look into CATCH in action, we will decide if and how to structure content of /soci/tests. > ML> 5) Move all current tests into common /soci/tests/old > ML> or /soci/tests/v3 to indicate they target SOCI<=3. > > Do you plan on keeping the current tests? I thought we'd make a push to > convert them to CATCH. Good question. I didn't want to suggest too disruptive changes, so I thought we may keep them archived there. But, if we manage to port 100% of the current tests to CATCH before SOCI 4.0.0, then I don't mind removing them completely. > ML> Do we all agree those changes make sense? > > Somewhat :-) Let's see /soci/ > ML> Perhaps, we should rename headers a bit: > ML> 1) Switch C++ headers to use .hpp extension (keep .h for simple C API) > ML> 2) Replace '-' with '_'. Underscore seems de facto a file naming > ML> standard in C++. > ML> How does it sound? > > Well, again, I'm naturally conservative so I'd like to avoid changing > things for change sake and forcing people to update their code (e.g. > mine includes soci-odbc.h) without some good reasons. Yes, personally I agree, I'm with you there. I used the word "Perhaps" to indicate a form of request. For example, someone out there may actually have been looking for such changes due to some good reasons. So, I wanted to indicate that this is the right moment (before SOCI 4 is released) to discuss and plan any such changes, if backed up by good reason of course. > Anyhow, both of these points could probably be resolved if we did keep > compatibility with the old headers by keeping them but just including the > new headers from them, e.g. include/use-type.h would include > include/soci/use_type.hpp > > But without this (and I think currently there are no plans to provide such > "compatible" headers), I think it'd be better to avoid changing things that > are not really that important in the grand scheme of things. Compatibility layers mean more maintenance, and more maintenance just to support changes for sake of changes is not kosher for idealism of lean thinking :-) So, I'm not in favour of it. If no good reasons for renaming appear, we won't rename anything. > ML> Also, I've been wondering if it would make sense to introduce > backend-specific > ML> namespaces. Then, class soci::postgresql_vector_into_type_backend would > ML> become soci::postgresql::vector_into_type_backend. > ML> I sense, this would make sense if we aim to introduce some generic > ML> and backend-specific exception hierarchies, etc. > ML> Also, soci-postgresql.h could become <soci/backends/postgresql.h> > ML> reaching into <soci/backends/postgresql/...> > ML> > ML> What you say on that? > > It's clear that if we use the subdirectories, then using namespaces would > be natural, although if you want to be 100% consistent we'd also need > "backend" namespace which is clearly superfluous, so it's still going to be > a compromise. Good point. > But, and sorry for the lack of enthusiasm, it's a bit hard to > be excited about all these more or less trivial changes which nevertheless > risk taking quite some time. Perhaps we could leave the introduction of > namespaces until some unspecified later time? :-) Also, notice that adding > namespaces is backwards incompatible too, e.g. soci::odbc_soci_error I > currently use would need to be replaced with soci::odbc::error... Which, > BTW, doesn't make much sense considering that we have soci::soci_error > instead of just soci::error... In fact, whatever we discuss and decide as planned has unspecified time, unless someone chimes in and offers a contract to complete certain tasks within a given timeframe :) Otherwise, volunteering is assumed. I consider SOCI 4 as version that potentially breaks backward compatibility. The question is how much we want to break, that's why I post such topics for discussion, so we have more or less clear picture what is our wishlist, and where we agree to compromise the compatibility for. I assume everyone has various thoughts and ideas, less or more interesting or sensible. SOCI 4 is a good opportunity to put them for discussion and either adopt or forget. I also assume, that if someone makes a proposal that is eventually agreed to be implemented, then that person is expected to deliver implementation, no delegating, unless other volunteers appear :) Back to namespaces, I assumed we can forget about compatibilities for SOCI 4 and let to carry away ourselves a bit ;-) Thus, I thought it may be a good idea to structure SOCI into namespaces was perspective some larger number of new types and definitions getting into the codebase. IMHO, namespaces increase quality, make interfaces discoverable and make most aspects of working with code easier on both ends, developer's and user's. But, as you raise importance of backward compatibility and perhaps others will do expect such promise too, then we certainly won't make any changes there. p.s. One thing, traditionally, SOCI never promised ABI compatibility between releases and I personally won't make such promises either. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ 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
