On Wed, Aug 11, 2010 at 11:29 PM, Joel de Guzman <joel@boost-consulting.com>wrote:
On 8/12/10 9:46 AM, David Sankel wrote:
On Sat, Jul 31, 2010 at 9:02 AM, Christopher Schmidt< mr.chr.schmidt@online.de> wrote:
Joel de Guzman schrieb:
On 7/30/2010 6:35 AM, Stefan Strasser wrote:
Zitat von Hartmut Kaiser<hartmut.kaiser@gmail.com>:
Have you seen the new BOOST_FUSION_ADAPT_CLASS() family of utilities which allow using (member-) functions instead of direct access to the data members of a class/struct?
no I had not, I was using 1.41. where can I see those? can't seem to find them in 1.43 or the trunk.
The BOOST_FUSION_ADAPT_xxxCLASSxxx-macros are not documented yet. For more information, refer to the code and the testcases:
https://svn.boost.org/trac/boost/browser/trunk/boost/fusion/adapted/class https://svn.boost.org/trac/boost/browser/trunk/libs/fusion/test/sequence
https://svn.boost.org/trac/boost/browser/trunk/libs/fusion/test/sequence/ada...
I think the ADAPT_CLASS macros fundamentally change the expected behavior of struct adaptation in a negative way. A non-template class/struct is a collection of
a) types (declared as nested typedefs or other structs) b) values of the following variety i) static member variables (values that are non-functions) ii) static member functions (values that are functions) iii) member functions (values that are "special" functions over the instance record) c) an instance record, which includes member variables
Up until this point, struct adaptation has exclusively been over the instance record, point c) above. This is very simple to understand and implies exactly one canonical adaptation for every struct/class.
ADAPT_CLASS mixes point c) and point iii) in an arbitrary way. Stefan's suggestions, on the other hand, are a straightforward extension of the original semantics. I'd personally like to see the latter incorporated and the former removed.
What's wrong with having both? Non-intrusive class adaptation, IMO, is very important too. I like Stefan's suggestions too but I don't understand why we can't have both.
I've given this some further thought and I think my problems are: a) the use of the word CLASS. This is inappropriate since that family of functions applies to a subset of classes and structs that use the getter setter idiom (GSI). b) the GSI is one of many possible idioms. One might also wish to include static member variables in the sequence, for example. c) I don't think GSI should have the same "status" as the STRUCT family since it is one of many possible idioms and one that is particularly bad (I can elaborate on why if someone wants). So, I suppose I would be in support of the CLASS family if it was renamed to GSI and put in a separate header for GSI support functions. David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)