www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Extending readf?

reply "monarch_dodra" <monarchdodra gmail.com> writes:
Not so long ago, there was an amazing article about how user 
defined types and formated writes behaved:

http://wiki.dlang.org/Defining_custom_print_format_specifiers

As cool as it is, I was writting a little user defined type, and 
I wanted to the the contrary: un-format it to read it.

Apparently. You can't do it. I'm not talking about "you can't 
customize it", I mean "you can't do it, at all."

For all the bashing C++'s ">>" and "<<" operators get, they at 
least work both ways for UDTs.

I found this thread:
http://forum.dlang.org/thread/mailman.2107.1335304266.4860.digitalmars-d-learn puremagic.com
And the forked thread:
http://forum.dlang.org/thread/20120424215103.GA28525 quickfur.ath.cx

Which basically amounts to "Maybe do you want to open this 
discussion in the main D newsgroup?" and the suggestion "Does it 
make sense to add a fromString() method to user-defined types for 
this? D's toString support is awesome (you can basically call 
to!string on just about anything and it works). It would be nice 
to have similar support for the reverse operation." To which no 
one added anything.

That was in .learn, so it might not have gotten much coverage.

How complicated wold it be to have things specify a "fromString" 
method? Is it worth the effort?

Is it possible to have a "fromString" default generated? If not, 
would it be OK if formatted read could work for only on things 
that define "fromString"?

In any case, it feels like a pretty wide hole in regards to a 
high level statically typed language.
Feb 07 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 7 February 2013 at 13:27:14 UTC, monarch_dodra wrote:

 ...
 For all the bashing C++'s ">>" and "<<" operators get, they at 
 least work both ways for UDTs.

 ...


I never understood why people like to bash about them.

I am yet to find a codebase in production where it is not obvious 
from context that streams are being used and not bit manipulation.

--
Paulo
Feb 07 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/7/13 8:47 AM, Paulo Pinto wrote:

 On Thursday, 7 February 2013 at 13:27:14 UTC, monarch_dodra wrote:

 ...
 For all the bashing C++'s ">>" and "<<" operators get, they at least
 work both ways for UDTs.

 ...


 I never understood why people like to bash about them.

 I am yet to find a codebase in production where it is not obvious from
 context that streams are being used and not bit manipulation.


Syntax is the least of iostreams' problem.

Andrei
Feb 07 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 07, 2013 at 02:27:12PM +0100, monarch_dodra wrote:

 Not so long ago, there was an amazing article about how user defined
 types and formated writes behaved:
 
 http://wiki.dlang.org/Defining_custom_print_format_specifiers
 
 As cool as it is, I was writting a little user defined type, and I
 wanted to the the contrary: un-format it to read it.
 
 Apparently. You can't do it. I'm not talking about "you can't
 customize it", I mean "you can't do it, at all."
 
 For all the bashing C++'s ">>" and "<<" operators get, they at least
 work both ways for UDTs.
 
 I found this thread:
 http://forum.dlang.org/thread/mailman.2107.1335304266.4860.digitalmars-d-learn puremagic.com
 And the forked thread:
 http://forum.dlang.org/thread/20120424215103.GA28525 quickfur.ath.cx
 
 Which basically amounts to "Maybe do you want to open this
 discussion in the main D newsgroup?" and the suggestion "Does it
 make sense to add a fromString() method to user-defined types for
 this? D's toString support is awesome (you can basically call
 to!string on just about anything and it works). It would be nice to
 have similar support for the reverse operation." To which no one
 added anything.
 
 That was in .learn, so it might not have gotten much coverage.


+1.

Using a similar design to the way Format() works, we can make fromString
such that the format specifier gets passed to the user-defined type,
complete with all information like field width, precision, etc., that it
can use to correctly parse the input. The input itself, of course,
will be in the form of an input range. At the very least, this should be
how it works under the hood.

Once that is working, we can build more convenient interface on top of
it, such as "simplified" fromString methods that gets called when a
default format specifier (probably %s) is used, and the user-defined
type doesn't want to bother with dealing with the nitty-gritty details
of format specifiers.



 How complicated wold it be to have things specify a "fromString"
 method? Is it worth the effort?


Yes.



 Is it possible to have a "fromString" default generated? If not,
 would it be OK if formatted read could work for only on things that
 define "fromString"?


I see fromString as the dual operation to toString. So I'd say, if the
default toString for a particular type is non-reversible, then there's
no need to make the reverse work as well. For example, class objects'
default toString just prints the class name. That's non-reversible,
because there's no way to specify ctor arguments in the format string or
current object state, etc., even if you wanted to. So there's probably
no need to have a default class fromString.

But all POD types should have a default fromString (structs, for
example, will be formatted with default values, so it's reversible).



 In any case, it feels like a pretty wide hole in regards to a high
 level statically typed language.


So let's fill that hole. :)


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. --
Sammy
Feb 07 2013
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 7 February 2013 at 16:05:34 UTC, H. S. Teoh wrote:

 So let's fill that hole. :)


 T


I'll try to write a DIP then :)
Feb 08 2013