From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2006-10-05 22:18:54
Nicola Musatti wrote:
> Mateusz Loskot <mateusz <at> loskot.net> writes:
>> Nicola Musatti wrote:
>> Could you elaborate what you consider as boostable or boostified
>> 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.
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.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:
> 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
> could be expressed in a more SOCI-like syntax as
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!
-- Mateusz Loskot http://mateusz.loskot.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk