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.
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.
ML> 4) Add /soci/tests directory
Yes, having tests in their separate directory would definitely be more
tidy and allow finding them immediately.
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.
ML> 6) All new tests can live directly in /soci/tests
Yes.
ML> Do we all agree those changes make sense?
Somewhat :-)
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. And while I can at
appreciate the desire to have different extension for C++ and C headers
(although practically speaking, plenty C++ libraries use .h), I really see
no point in replacing the dashes with underscores. It's true that
underscores are more common, as my highly scientific test shows:
% lsb_release -d
Description: Debian GNU/Linux 6.0.7 (squeeze)
% ls /usr/include/**/*_*.h*|wc -l
6193
% ls /usr/include/**/*-*.h*|wc -l
598
but there are quite a few files with dashes in them too.
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.
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. 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...
Regards,
VZ
[1] http://c2.com/cgi/wiki?LazinessImpatienceHubris
pgp3N5mL0YB2d.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
