[MultiIndex] interface comments
Just reading through the docs for this very useful library and I had a few notes: 0. The term /typelist/ (italicized) is used in the tutorial without definition. Do you mean an MPL type sequence, or something else? 1. Seems like the tags functionality could take advantage of Boost.Parameter to provide a nicer interface and save some code. 2. The "shortcuts" save exactly 1 character. Each index of a multi_index_container uses its own iterator types, which are different from those of another indices. As is the rule with STL containers, these iterators are defined as nested types of the index: employee_set::nth_index<1>::type::iterator it= es.get<1>().find("Judy Smith"); <snip> Additionally, multi_index_containers provide shortcut definitions to the iterator types of their constituent indices: employee_set::nth_index_iterator<1>::type it= es.get<1>().find("Judy Smith"); There is a variation of the expression above for use with tags: employee_set::index_iterator<name>::type it= es.get<name>().find("Judy Smith"); // get<1> would also work Notice the column in which "it" appears in both versions. IMO these interfaces should be deprecated (i.e. not documented, and eventually removed) as they provide no readability advantage, hurt learnability, and complicate usage. Regards, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams <dave <at> boostpro.com> writes:
Just reading through the docs for this very useful library and I had a few notes:
0. The term /typelist/ (italicized) is used in the tutorial without definition. Do you mean an MPL type sequence, or something else?
Yep, strictly speaking it is an MPL forward sequence, as stated in the reference. I wrote "typelist" instead of plain "list" lest anyone took the latter as somehow related to run-time lists (std::list etc.) But not explaning the term "typelist" in advance is even more confusing, as I realize rereading the paragrapah. So I guess I'll revert to unitalicized "list". Do you think this would be clearer for an entry-level reader?
1. Seems like the tags functionality could take advantage of Boost.Parameter to provide a nicer interface and save some code.
I don't see how... Would you care to elaborate? <shameless plug>For a very extensive and, IMHO, effective use case of Boost.Parameter have a look at the free-order template parameter interface of the (soon to be included in Boost) Boost Flyweight Library (http://tinyurl.com/6xxdkm ).</shameless plug>
2. The "shortcuts" save exactly 1 character.
[...]
Notice the column in which "it" appears in both versions. IMO these interfaces should be deprecated (i.e. not documented, and eventually removed) as they provide no readability advantage, hurt learnability, and complicate usage.
Yes, you're absolutely right. I don't recall why I included the iterator "shortcuts" in the first place, but they probably confuse more than hurt. I'll do as you propose and begin their deprecation process in Boost 1.38. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
on Sat Nov 01 2008, Joaquin M Lopez Munoz <joaquin-AT-tid.es> wrote:
David Abrahams <dave <at> boostpro.com> writes:
Just reading through the docs for this very useful library and I had a few notes:
0. The term /typelist/ (italicized) is used in the tutorial without definition. Do you mean an MPL type sequence, or something else?
Yep, strictly speaking it is an MPL forward sequence, as stated in the reference. I wrote "typelist" instead of plain "list" lest anyone took the latter as somehow related to run-time lists (std::list etc.) But not explaning the term "typelist" in advance is even more confusing, as I realize rereading the paragrapah. So I guess I'll revert to unitalicized "list". Do you think this would be clearer for an entry-level reader?
That might be clearer, yeah, if you're not going to say that indices<...> is an MPL sequence. You could also link the word "list" to the place in the reference where you give more detailed info on it.
1. Seems like the tags functionality could take advantage of Boost.Parameter to provide a nicer interface and save some code.
I don't see how... Would you care to elaborate?
instead of: employee_set::index<name>::type& name_index=es.get<name>(); you could have employee_set::index<tag::name>::type& name_index = es[name]; I guess it's not a huge win.
<shameless plug>For a very extensive and, IMHO, effective use case of Boost.Parameter have a look at the free-order template parameter interface of the (soon to be included in Boost) Boost Flyweight Library (http://tinyurl.com/6xxdkm ).</shameless plug>
Nice, but especially since those parameters are optional I wouldn't try to exhaustively list all the combinations; the doc gives the impression that they all need to be passed. If the point is to make it easy for the reader, I suggest you not overwhelm her with code ;-) The Boost.Python docs explain this stuff in a simple way that nobody *ever* asks me about, and doesn't require me to enumerate all the argument orders.
2. The "shortcuts" save exactly 1 character. [...] Notice the column in which "it" appears in both versions. IMO these interfaces should be deprecated (i.e. not documented, and eventually removed) as they provide no readability advantage, hurt learnability, and complicate usage.
Yes, you're absolutely right. I don't recall why I included the iterator "shortcuts" in the first place, but they probably confuse more than hurt. I'll do as you propose and begin their deprecation process in Boost 1.38.
Thanks for keeping an open mind about that :-) Cheers, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams escribió:
on Sat Nov 01 2008, Joaquin M Lopez Munoz <joaquin-AT-tid.es> wrote:
1. Seems like the tags functionality could take advantage of Boost.Parameter to provide a nicer interface and save some code.
I don't see how... Would you care to elaborate?
instead of:
employee_set::index<name>::type& name_index=es.get<name>();
you could have
employee_set::index<tag::name>::type& name_index = es[name];
I guess it's not a huge win.
I guess not. I'd rather leave it like it stands.
<shameless plug>For a very extensive and, IMHO, effective use case of Boost.Parameter have a look at the free-order template parameter interface of the (soon to be included in Boost) Boost Flyweight Library (http://tinyurl.com/6xxdkm ).</shameless plug>
Nice, but especially since those parameters are optional I wouldn't try to exhaustively list all the combinations; the doc gives the impression that they all need to be passed. If the point is to make it easy for the reader, I suggest you not overwhelm her with code ;-) The Boost.Python docs explain this stuff in a simple way that nobody *ever* asks me about, and doesn't require me to enumerate all the argument orders.
I've skimmed thru B.Py docs and can't seem to find the material you mention. Could you please provide me with a URL?
Thanks for keeping an open mind about that :-)
Thanks for challenging my assumptions. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
on Wed Nov 05 2008, joaquin-AT-tid.es wrote:
I've skimmed thru B.Py docs and can't seem to find the material you mention. Could you please provide me with a URL?
http://www.boost.org/doc/libs/1_37_0/libs/python/doc/v2/class.html#class_-sp... http://www.boost.org/doc/libs/1_37_0/libs/python/doc/v2/def.html#def-spec HTH, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (3)
-
David Abrahams -
Joaquin M Lopez Munoz -
joaquin＠tid.es