www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - fromString naming convention

reply "Ben Hinkle" <bhinkle mathworks.com> writes:
We have toString as the mechanism to convert types to char[]. How about 
adding fromString templates/functions to std.conv (and other places) that 
handle the numeric types so that one doesn't have to worry about when to use 
toInt and when to use scanf (like for floats) or some other mechanism. 
Similarly the std.date.parse function could be renamed fromString. Other 
module might also have fromStrings. For std.conv I'm thinking

template fromString(T : int) {
  T fromString(char[] str) {
    return toInt(str);
  }
}
template fromString(T : uint) {
  T fromString(char[] str) {
    return toUint(str);
  }
}
... etc...

The date module could use a function instead of a template since there would 
be only 1 fromString in the module and so there's no need to use templates 
to specify the return type.

thoughts?
-Ben
Mar 11 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d0sc5n$25m8$1 digitaldaemon.com...

 We have toString as the mechanism to convert types to char[]. How about 
 adding fromString templates/functions to std.conv (and other places) that 
 handle the numeric types so that one doesn't have to worry about when to 
 use toInt and when to use scanf (like for floats) or some other mechanism. 
 Similarly the std.date.parse function could be renamed fromString. Other 
 module might also have fromStrings.


I should add an alternative is to add more toFoo's like toDouble, toFloat, 
toDate, etc.
- I don't really mind either convention actually.
Mar 11 2005
next sibling parent reply David L. Davis <SpottedTiger yahoo.com> writes:
In article <d0sdv0$27io$1 digitaldaemon.com>, Ben Hinkle says...

"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d0sc5n$25m8$1 digitaldaemon.com...
I should add an alternative is to add more toFoo's like toDouble, toFloat, 
toDate, etc.
- I don't really mind either convention actually.


Ben: I recently passed some D code to Walter to fill in the blanks within
std.conv for string to real conversions. Functions like toFloat(), toDouble(),
toReal(), toIfloat(), toIdouble(), toIreal(), toCfloat(), toCdouble(), and
toIreal(), which hopefully if he has some time they'll be added in the near
future. But a toDate() and maybe even a toTime() conversion, sounds like a good
idea to add these functions to std.conv too! :)

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Mar 11 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 Ben: I recently passed some D code to Walter to fill in the blanks within
 std.conv for string to real conversions. Functions like toFloat(), 
 toDouble(),
 toReal(), toIfloat(), toIdouble(), toIreal(), toCfloat(), toCdouble(), and
 toIreal(), which hopefully if he has some time they'll be added in the 
 near
 future.


Cool. I hope it makes it in. Then we wouldn't need any fromString mumbo 
jumbo.


 But a toDate() and maybe even a toTime() conversion, sounds like a good
 idea to add these functions to std.conv too! :)


I think they would be better to be in the "natural" module std.date. 
Personally I'd even consider replacing the "parse" function in std.date 
since that is a pretty generic name. What were you thinking of for toTime? I 
haven't thought about it.
Mar 11 2005
parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <d0sp83$2kcg$1 digitaldaemon.com>, Ben Hinkle says...

 Ben: I recently passed some D code to Walter to fill in the blanks within
 std.conv for string to real conversions. Functions like toFloat(), 
 toDouble(),
 toReal(), toIfloat(), toIdouble(), toIreal(), toCfloat(), toCdouble(), and
 toIreal(), which hopefully if he has some time they'll be added in the 
 near
 future.


Cool. I hope it makes it in. Then we wouldn't need any fromString mumbo 
jumbo.


 But a toDate() and maybe even a toTime() conversion, sounds like a good
 idea to add these functions to std.conv too! :)


I think they would be better to be in the "natural" module std.date. 
Personally I'd even consider replacing the "parse" function in std.date 
since that is a pretty generic name. What were you thinking of for toTime? I 
haven't thought about it. 


*knocks head* Yeah you're right! My mistake, toDate() would go into std.date
duh! :) And about the toTime() function, I was thinking that it and toDate()
would make more sense as wrappers around parse() instead of using it directly.
But now that I think about it, Walter added a couple of functions like "char[]
toTimeString(d_time time)," "d_time toDtime(DosFiletime time)," and "d_time
toUTCString(d_time time) back in the dmd v0.111 build. Which he also fixed a
parse() problem in handling years < 1970 correctly, at the time I was having
problems with this bug while writing some simple date functions for a
sub-project on my website. 

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Mar 11 2005
prev sibling parent "Charles" <cee-lo green.com> writes:
Good idea.


"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:d0sdv0$27io$1 digitaldaemon.com...

 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:d0sc5n$25m8$1 digitaldaemon.com...

 We have toString as the mechanism to convert types to char[]. How about
 adding fromString templates/functions to std.conv (and other places)




that

 handle the numeric types so that one doesn't have to worry about when to
 use toInt and when to use scanf (like for floats) or some other




mechanism.

 Similarly the std.date.parse function could be renamed fromString. Other
 module might also have fromStrings.


 I should add an alternative is to add more toFoo's like toDouble, toFloat,
 toDate, etc.
 - I don't really mind either convention actually.
Mar 11 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Well, er, the obvious fly in this ointment is that we don't overload on 
return type, which would confine the entire set of fromString() 
functions to template ones (for which the language currently requires 
explicit instantiation).

This prevents non-template ones, and also ignores the possibility of 
future (albiet limited) implicit instantiation, that Walter's hinted at 
from time to time (and that many have asked for).

So, I think it's not a flyer.

"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d0sc5n$25m8$1 digitaldaemon.com...

 We have toString as the mechanism to convert types to char[]. How 
 about adding fromString templates/functions to std.conv (and other 
 places) that handle the numeric types so that one doesn't have to 
 worry about when to use toInt and when to use scanf (like for floats) 
 or some other mechanism. Similarly the std.date.parse function could 
 be renamed fromString. Other module might also have fromStrings. For 
 std.conv I'm thinking

 template fromString(T : int) {
  T fromString(char[] str) {
    return toInt(str);
  }
 }
 template fromString(T : uint) {
  T fromString(char[] str) {
    return toUint(str);
  }
 }
 ... etc...

 The date module could use a function instead of a template since there 
 would be only 1 fromString in the module and so there's no need to use 
 templates to specify the return type.

 thoughts?
 -Ben
Mar 11 2005
next sibling parent Kris <Kris_member pathlink.com> writes:
:-)

This is exactly why the mango.format package is the way it is;


In article <d0t05i$2rqv$1 digitaldaemon.com>, Matthew says...

Well, er, the obvious fly in this ointment is that we don't overload on 
return type, which would confine the entire set of fromString() 
functions to template ones (for which the language currently requires 
explicit instantiation).

This prevents non-template ones, and also ignores the possibility of 
future (albiet limited) implicit instantiation, that Walter's hinted at 
from time to time (and that many have asked for).

So, I think it's not a flyer.

"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d0sc5n$25m8$1 digitaldaemon.com...

 We have toString as the mechanism to convert types to char[]. How 
 about adding fromString templates/functions to std.conv (and other 
 places) that handle the numeric types so that one doesn't have to 
 worry about when to use toInt and when to use scanf (like for floats) 
 or some other mechanism. Similarly the std.date.parse function could 
 be renamed fromString. Other module might also have fromStrings. For 
 std.conv I'm thinking

 template fromString(T : int) {
  T fromString(char[] str) {
    return toInt(str);
  }
 }
 template fromString(T : uint) {
  T fromString(char[] str) {
    return toUint(str);
  }
 }
 ... etc...

 The date module could use a function instead of a template since there 
 would be only 1 fromString in the module and so there's no need to use 
 templates to specify the return type.

 thoughts?
 -Ben
Mar 11 2005
prev sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d0t05i$2rqv$1 digitaldaemon.com...

 Well, er, the obvious fly in this ointment is that we don't overload on 
 return type, which would confine the entire set of fromString() functions 
 to template ones (for which the language currently requires explicit 
 instantiation).


Yeah - it would be pretty clunky. There isn't that much difference between 
toInt(str) and fromString!(int)(str) aside from the ability to have "int" a 
template parameter. Plus with name lookup rules one would probably have to 
write out tons of package and module names so it would get more and more 
verbose. yuck.


 This prevents non-template ones, and also ignores the possibility of 
 future (albiet limited) implicit instantiation, that Walter's hinted at 
 from time to time (and that many have asked for).


I was thinking the non-template ones would use name lookup rules to find the 
right ones. But that's still pretty verbose.


 So, I think it's not a flyer.


The toDouble etc solution is better. My goal was to have something 
consistent so that is fine - even though it includes the type in the name.
Mar 11 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
Hi, Ben

I am using two forms:

bool fromString(in string token, out T value)
bool fromString(in string token, out T value, in T defaultValue)

both of them return true if conversion were successfull.

I've found that blind forms like
      T fromString(in str token)
are not useful in most cases if they are not generating exceptions.

And also signatures like
bool fromString(in str token, out T value)
do not need to be templates.

Andrew Fedoniouk.



"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d0sc5n$25m8$1 digitaldaemon.com...

 We have toString as the mechanism to convert types to char[]. How about 
 adding fromString templates/functions to std.conv (and other places) that 
 handle the numeric types so that one doesn't have to worry about when to 
 use toInt and when to use scanf (like for floats) or some other mechanism. 
 Similarly the std.date.parse function could be renamed fromString. Other 
 module might also have fromStrings. For std.conv I'm thinking

 template fromString(T : int) {
  T fromString(char[] str) {
    return toInt(str);
  }
 }
 template fromString(T : uint) {
  T fromString(char[] str) {
    return toUint(str);
  }
 }
 ... etc...

 The date module could use a function instead of a template since there 
 would be only 1 fromString in the module and so there's no need to use 
 templates to specify the return type.

 thoughts?
 -Ben
Mar 11 2005