"Doug Gregor" <dgregor@cs.indiana.edu> wrote in message news:E19435DE-34B0-11D9-A026-000A95B0EC64@cs.indiana.edu... The formal review of the Named Parameters library by David Abrahams and Daniel Wallin starts today and runs until Monday, November 22nd. - What is your evaluation of the design? Overall I like the idea of named parameters, basically because they are an aid to code legibility as staed in the docs. Anything that provides in place documentation is extremely useful facility. Therefore In contrast to the BGL approach I think this is more legible. I am assuming that the BGL approach must uses member functions in some class ruling out the assignment style syntax, and presumably requiring the class to be written, so this must be more 'generic'.... After trying out the library to see if it might help make initialisation of a transform matrix more legible. (Note obviously more efficient to pass in the matrix as a non const reference, but the legibility starts to suffer. OTOH Ideally It woould be nice to use something similar to named params in a constructor... but I assume that the lib wont support that ?. However at the end of the day Some equivalent to this libraray might actually be more useful in constructors than for functions ) //bgl style ? tx_matrix<units> t = make_matrix( translation (xy_pair<units>(units(1),units(1))). rotation (angle::rad(1)). scaling (.5) ); tx_matrix<units> t = make_matrix( translation = xy_pair<units>(units(1),units(1)), rotation = angle::rad(1), scaling = .5 ); I come to the conclusion that the second format is aesthetically better than the first, which I guess covers the design. I cant see a better way to do it. - What is your evaluation of the implementation? As far as looking into the implementation is concerned I was interested to see a custom list used. I guess there are good reasons for this, but I thought mpl and tuple were designed for this type of job?. Whatever I dont really have the experience to make any assessment of the implementation The Helper macro BOOST_NAMED_PARAMS_FUN is very useful as far as it goes. Of course in the make_matrix function above the return type would be a template type. Obviously the macro cant deal with that or can it?, which is annoying as implementing the thing manually is relatively time consuming. OTOH I have no idea what the alternative might be though. Although it makes life easy for users, at the implementation level a fair amount of work is required once you stray from simple use. - What is your evaluation of the documentation? Well I followed through on the examples and finally got it to run. It is slightly *amusing* to keep writing the code for the examples and then be told 'but of course that doesnt work' (2.3 Defining the implementation function) - What is your evaluation of the potential usefulness of the library? I think it is very useful for increasing source code legibility. Though bear in mind that a reasonable amount of time needs to be spent by the implementor to make the users life easy ( I suspect the BOOST_NAMED_PARAMS_FUN MACRO doesnt work except in the simplest cases). No gain no pain I guess.. - Did you try to use the library? With what compiler? Tested on VC7.1 Did you have any problems? I had some problems with the boost::mpl::_ widget ... but I guess this shouldnt be used with the BOOST_NAMED_PARAMS_FUN macro.. not further explored for lack of time. The SFINAE looks like it may get quite hairy, where a number of types need to be restricted, though I'm not sure that this cant be done simply by using enable_if in the return type of the function?:-) - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I played around for an hour or so. - Are you knowledgeable about the problem domain? If the domain is function parameters ... I guess I use them from tine to time .. As always, please remember to clearly state whether you believe the library should be accepted into Boost. Yes. Thank you Doug Gregor Review Manager, Named Parameters library _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost