View mode: basic / threaded / horizontal-split · Log in · Help
March 11, 2005
fromString naming convention
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
March 11, 2005
Re: fromString naming convention
"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.
March 11, 2005
Re: fromString naming convention
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!"
March 11, 2005
Re: fromString naming convention
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.
>
>
>
March 11, 2005
Re: fromString naming convention
> 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.
March 11, 2005
Re: fromString naming convention
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!"
March 11, 2005
Re: fromString naming convention
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
>
>
March 11, 2005
Re: fromString naming convention
:-)

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
>>
>> 
>
>
March 11, 2005
Re: fromString naming convention
"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.
March 11, 2005
Re: fromString naming convention
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
>
>
Top | Discussion index | About this forum | D home