On Sat, 2 Feb 2013 20:39:00 +0000 Mateusz Loskot <[email protected]> wrote:

ML> On 29 January 2013 17:40, Pawel Aleksander Fedorynski <[email protected]> 
wrote:
ML> > into_as_raw_text() sounds good to me.  The final decision belongs to
ML> > Mateusz.
ML> 
ML> Nah, we should get this as well as other similar things agreed
ML> collaboratively, as a team :)
ML> 
ML> Let's summarise things up, so I'm clear about the idea:
ML> 
ML> 1. into(sink) stores a value fetched from query results in the sink
ML> 
ML> 2. into(sink) has some capacity to perform value type to sink type
ML> conversion, sort of a type promotion triggered by the difference between
ML> value type and sink type.
ML> 
ML> 3. into(sink) has no capacity to perform advanced explicit conversions if
ML> distance between value type and sink type is significant.
ML> 
ML> We don't want to equip the existing into(sink) machinery with advanced
ML> conversion ability because it would easily conflict with the implicit type
ML> promotion that's already there.
ML> 
ML> So, we need a new tool.
ML> 
ML> I guess, don't need a tool capable to perform any value type to any sink 
type
ML> conversion, but any value type to text is sufficient. Thus, we're gonna have
ML> single into_xxx(std::string) utility.
ML> 
ML> Am I getting it?
ML> The sink type is hard-wired std::string, right?

 Hello,

 This was exactly what I was proposing, thanks for your nice summary!


ML> Regarding name, I don't have a clear winner candidate, but I guess that
ML> it should suggest it's related to into():

 Yes, again, I can't but agree.

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. 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.

 Regards,
VZ

Attachment: pgpeF2iYfCokp.pgp
Description: PGP signature

------------------------------------------------------------------------------
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

Reply via email to