On 3 February 2013 21:26, Vadim Zeitlin <[email protected]> wrote: > On Sat, 2 Feb 2013 20:39:00 +0000 Mateusz Loskot <[email protected]> wrote: > ML> Obviously, there is lots of variants to consider: > ML> into_as_raw_text() > ML> into_as_text() > ML> into_as_raw() > ML> into_raw() > ML> into_text() > ML> into_to_string() > ML> into_convert() > ML> > ML> I'd also consider name aligned with the C++11 converter std::to_string > ML> > ML> into_to_string() > > "into" + "to" seems a bit strange to me. As for "into_text" or > "into_string", this seem to easy to confuse with the function for > retrieving a normal field value of a string type, i.e. I could imagine > people using this instead of a simple "into()" for no good reason. So IMHO > using "raw" is important.
Yes, I just realised that. The "raw" reflects advanced purposes. > The choice between "into_as_raw_text", > "into_as_raw" and "into_raw" is, AFAICS, purely subjective and personally I > rather like the latter as it's the shortest while still retaining the > really significant part of the name. But my initial reason for recommending > "into_as_raw_text" was that > > (1) the purpose of this function was not completely obvious > (2) it shouldn't be used very often > > and, based on this, it didn't seem like a good idea to optimize its name > for brevity. Good point. Taken. Assuming we don't want to support any other sink types than std::string, then into_as_raw_text() sounds good to me too. (Otherwise, the "_text" suffix could be confusing.) Thanks! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
