Nicola Musatti wrote:
Mateusz Loskot <mateusz <at> loskot.net> writes:
Nicola Musatti wrote: [...] Could you elaborate what you consider as boostable or boostified intefrace/library? May be you could point a document where I can find general guidelines about Boost conforming library interface design?
The most reasonable starting point is: http://boost.org/more/lib_guide.htm .
Yes, I know these documents and I've already started to analyze SOCI according these docs.
I noticed you're using these terms like "boostified version of SOCI" or "suitability of some of the interface choices" or "with Boost compliance in mind" but I have no idea how to understand them.
Understanding of these terms may be crucial to identify if SOCI is or isn't compliant with Boost library interface design guidelines, etc.
I believe, it's not only a matter of taste, is it?
In part. Coding and naming conventions, library organization and directory structure are objective issues which are documented in the page I linked above or elsewhere in the Boost web site and other details may be gathered from how existing Boost libraries are organized, especially the most recent ones.
Thank you! This is what I've expected to hear. I absolutely agree and I'm sure our understanding of boostification is very similar. I also understand what you mean as "the suitability of some of the interface choices made by the SOCI developers." Personally, I can't talk for the whole SOCI team, I'd like to follow all Boost guidelines and conventions, regarding naming, project layout, etc. Initially, I misunderstood you a little having an impression there are some conventions SOCI actually breaks regarding operator overloading or using get(index) instead of operator[], etc. Thanks again for clarification.
On the other hand defining what consititutes a suitable interface for a Boost or a standard library has to do with personal expectations and experience, and can only be subject to consensus among interested developers.
Yes. AFAIK, Boost gives developers some liberty in this subject.
Row r; sql << "select * from ex2", into(r);
// Columns may be accessed by position... std::cout << r[0].as<long>() << "\t ";
SOCI equivalent: r.get<long>(0) I consider this a small abstraction mismatch: you apply the index to the row and then you convert the field value to a C++ type. By the way, in this case operator[] is the natural way to express indexing, so I believe that operator overloading should be preferred.
I agree, only and only if elements of a sequence can be identified only by index. In SOCI, when working with Row representation the situation is different - elements of Row can accessed *also* via name, what's natural in DBMS, where columns are named. So, SOCI interface is consistent and intuitive in this case:
r.get<long>(0) r.get<long>("column1)
I do not agree. The use of square brackets with non integer arguments is common when speaking of associative maps and is present in the standard library in std::map's interface.
Yes, I think I've been convinced :-) I'm sure we will discuss in SOCI team all concepts proposed here.
Moreover, I was pointing out another issue: when you have a row you first index it to get a field and then you translate its value to your destination. What I wrote as
r[0].as<long>()
could be expressed in a more SOCI-like syntax as
r.field(0).get<long>()
Hmm, it's very interesting point, again. Yes, I agree, these subtle differences can make a difference. I'm inclined to discuss about incorporating it to SOCI. Thank you for your valuable comments! Cheers -- Mateusz Loskot http://mateusz.loskot.net