On Wed, 07 Sep 2011 03:30:17 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2011-09-06 19:39, Steven Schveighoffer wrote:
>> I like enums in terms of writing code that processes them, but in terms
>> of calling functions with them, I mean look at a sample fstream
>> constructor in C++:
>>
>> fstream ifs("filename.txt", ios_base::in | ios_base::out);
>>
>> vs.
>>
>> File("filename.txt", "r+"); // or "rw"
>>
>> There's just no way you can think "rw" is less descriptive or
>> understandable than ios_base::in | ios_base::out.
>>
>> -Steve
>
> BTW, I think that using:
>
> Mode.read | Mode.write
>
> Instead of "rw" is the same thing as one should name variables with a proper descriptive names instead of just "a" or "b".

It's not the same.  "a" and "b" do not have any meaning, they are just variable names.  "r" stands for read and "w" stands for write.  It's pretty obvious that they do, especially in the context of opening a file.

I'd equate it to using i, j, k for index variables -- they are not descriptive, but in context, everyone knows what they mean.

And in response to the discussion about enum flags not being & or | together, I emphatically think enums should be used for bitfields.  Remember, enum is not just an enumeration, it's a manifest constant.  I see no reason that we should not use the namespace-creation ability of enum to create such constants.  I don't see the downside.

-Steve

On Tue, 06 Sep 2011 18:57:00 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Tuesday, September 06, 2011 18:48:24 bearophile wrote:
>> Paul D. Anderson:
>> > I think this is a terrific suggestion.
>>
>> I have suggested std.io time ago, but someone doesn't like it:
>> http://d.puremagic.com/issues/show_bug.cgi?id=4718
>
> It's not enough of an improvement to rename std.stdio to std.io just to rename
> it. However, if Steven's ultimate changes are different enough that a separate
> module is needed for a clean migration path, and those changes do get accepted
> into Phobos, then naming the new module std.io makes good sense.

When I get my re-revamped stdio working, it will likely involve std.io (which I independently decided to use).  It will not be a replacement for stdio, but will be used by stdio.

So I'm glad others think this is a good idea.

-Steve

On Tue, 06 Sep 2011 17:59:44 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Tuesday, September 06, 2011 23:51:48 Marco Leise wrote:
>> Am 06.09.2011, 22:28 Uhr, schrieb Timon Gehr <timon.gehr@gmx.ch>:
>> > On 09/06/2011 09:36 PM, notna wrote:
>> >> Sorry upfront, I didn't read this hole thread, so maybe I'm missing  
>> or
>> >> mixing something...
>> >>
>> >> How about a D binding for http://www.xmlsoft.org/ ?
>> >>
>> >> In other words, taking the "curl or sqlite3 path", something like
>> >> /etc/c/xml2
>> >
>> > That is about 4 times slower than the Tango XML parser:
>> >
>> >  
>> http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-updated-graphs
>> > -with-rapidxml/
>> You are so right, Timon. How deep is the trench between Phobos and Tango
>> devs? Tango's XML parser should really make it into Phobos.
>
> A new std.xml is already in the works. It'll be range-based, unlike the Tango
> parser. But there's no reason why Phobos shouldn't be able to have a
> similarly-fast XML parser. As I understand it, the primary reason that the
> current std.xml is slow is because it uses delegates quite a bit, but I
> haven't used it myself, so I don't know all of the details.

No, the issue is, and always will be, buffer access.  C's FILE * just doesn't provide anything decent.  It's the primary motivation for wanting to revamp it.  With slicing and copy avoidance (i.e. only read into a buffer, never copy out), we can achieve the same with Phobos, but I think we have to replace C's buffering system (at least for this usage).

Tango's I/O libraries use delegates and virtual functions galore.  I think too big a stigma is attached to those.  The difference between calling a virtual function/delegate and calling a normal function is very insignificant, the real savings for not using virtual functions is to allow inlining.

However, in this case, I/O is so diverse that you *need* polymorphism.

-Steve

On 09/08/2011 01:13 PM, Steven Schveighoffer wrote:
> On Wed, 07 Sep 2011 03:30:17 -0400, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2011-09-06 19:39, Steven Schveighoffer wrote:
>>> I like enums in terms of writing code that processes them, but in terms
>>> of calling functions with them, I mean look at a sample fstream
>>> constructor in C++:
>>>
>>> fstream ifs("filename.txt", ios_base::in | ios_base::out);
>>>
>>> vs.
>>>
>>> File("filename.txt", "r+"); // or "rw"
>>>
>>> There's just no way you can think "rw" is less descriptive or
>>> understandable than ios_base::in | ios_base::out.
>>>
>>> -Steve
>>
>> BTW, I think that using:
>>
>> Mode.read | Mode.write
>>
>> Instead of "rw" is the same thing as one should name variables with a
>> proper descriptive names instead of just "a" or "b".
>
> It's not the same. "a" and "b" do not have any meaning, they are just
> variable names. "r" stands for read and "w" stands for write. It's
> pretty obvious that they do, especially in the context of opening a file.
>
> I'd equate it to using i, j, k for index variables -- they are not
> descriptive, but in context, everyone knows what they mean.
>

I totally agree.

> And in response to the discussion about enum flags not being & or |
> together, I emphatically think enums should be used for bitfields.
> Remember, enum is not just an enumeration, it's a manifest constant.

enum Enumeration{
    field0,
    field1,
}

enum manifestConstant=0;

> I see no reason that we should not use the namespace-creation ability of
> enum to create such constants. I don't see the downside.

The downside is that eg. final switch incorrectly assumes that enum values are not composeable. It is imho a small inconsistency in the language's design.

On Thu, 08 Sep 2011 08:20:46 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 09/08/2011 01:13 PM, Steven Schveighoffer wrote:

>> And in response to the discussion about enum flags not being & or |
>> together, I emphatically think enums should be used for bitfields.
>> Remember, enum is not just an enumeration, it's a manifest constant.
>
> enum Enumeration{
>      field0,
>      field1,
> }
>
> enum manifestConstant=0;

There are other forms too:

enum MyConstants
{
   const1 = 5;
   const2 = 42;
}

enum flags {
   flag1 = 0x01,
   flag2 = 0x02,
   flag3 = 0x04,
}

Those are clearly manifest constants with a namespace.  The last one is a bitfield.

>
>> I see no reason that we should not use the namespace-creation ability of
>> enum to create such constants. I don't see the downside.
>
> The downside is that eg. final switch incorrectly assumes that enum values are not composeable. It is imho a small inconsistency in the language's design.

So don't use final switch?  Again, not all enums are enumerations, you have to judge whether final switch is applicable based on interpretation of that.

-Steve

On 2011-09-08 13:04, Steven Schveighoffer wrote:
> On Wed, 07 Sep 2011 03:27:43 -0400, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2011-09-06 19:39, Steven Schveighoffer wrote:
>>>
>>> I like enums in terms of writing code that processes them, but in terms
>>> of calling functions with them, I mean look at a sample fstream
>>> constructor in C++:
>>>
>>> fstream ifs("filename.txt", ios_base::in | ios_base::out);
>>>
>>> vs.
>>>
>>> File("filename.txt", "r+"); // or "rw"
>>>
>>> There's just no way you can think "rw" is less descriptive or
>>> understandable than ios_base::in | ios_base::out.
>>>
>>> -Steve
>>
>> But "r+" is. And that's what I assume will be used when I see a file
>> opening function taking a string "mode" parameter. But if you say that
>> "rw" can/will be used instead than that's better.
>>
>
> Yes, I'll try to add "rw" and maybe some other letter combinations that
> make sense in my next version.
>
> But I think we still have to support "r+", even though it's esoteric,
> because too much existing code already does this, and to not support it
> would leave silently compiling bugs.
>
> -Steve

Didn't you just say that you would check the string at compile time?

-- 
/Jacob Carlborg

On 2011-09-08 13:13, Steven Schveighoffer wrote:
> On Wed, 07 Sep 2011 03:30:17 -0400, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2011-09-06 19:39, Steven Schveighoffer wrote:
>>> I like enums in terms of writing code that processes them, but in terms
>>> of calling functions with them, I mean look at a sample fstream
>>> constructor in C++:
>>>
>>> fstream ifs("filename.txt", ios_base::in | ios_base::out);
>>>
>>> vs.
>>>
>>> File("filename.txt", "r+"); // or "rw"
>>>
>>> There's just no way you can think "rw" is less descriptive or
>>> understandable than ios_base::in | ios_base::out.
>>>
>>> -Steve
>>
>> BTW, I think that using:
>>
>> Mode.read | Mode.write
>>
>> Instead of "rw" is the same thing as one should name variables with a
>> proper descriptive names instead of just "a" or "b".
>
> It's not the same. "a" and "b" do not have any meaning, they are just
> variable names. "r" stands for read and "w" stands for write. It's
> pretty obvious that they do, especially in the context of opening a file.

I guess it's a little clearer in the context of opening a file. "a" can be short for "apple" and "b" can be short for "beer".

-- 
/Jacob Carlborg

On 2011-09-08 13:25, Steven Schveighoffer wrote:
> On Tue, 06 Sep 2011 17:59:44 -0400, Jonathan M Davis
>> A new std.xml is already in the works. It'll be range-based, unlike
>> the Tango
>> parser. But there's no reason why Phobos shouldn't be able to have a
>> similarly-fast XML parser. As I understand it, the primary reason that
>> the
>> current std.xml is slow is because it uses delegates quite a bit, but I
>> haven't used it myself, so I don't know all of the details.
>
> No, the issue is, and always will be, buffer access. C's FILE * just
> doesn't provide anything decent. It's the primary motivation for wanting
> to revamp it. With slicing and copy avoidance (i.e. only read into a
> buffer, never copy out), we can achieve the same with Phobos, but I
> think we have to replace C's buffering system (at least for this usage).
>
> Tango's I/O libraries use delegates and virtual functions galore. I
> think too big a stigma is attached to those. The difference between
> calling a virtual function/delegate and calling a normal function is
> very insignificant, the real savings for not using virtual functions is
> to allow inlining.
>
> However, in this case, I/O is so diverse that you *need* polymorphism.
>
> -Steve

The Tango XML parser doesn't read from a file, it takes the input as a string. The parser isn't affected by I/O at all.

-- 
/Jacob Carlborg

On Thu, 08 Sep 2011 09:05:35 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2011-09-08 13:04, Steven Schveighoffer wrote:
>> On Wed, 07 Sep 2011 03:27:43 -0400, Jacob Carlborg <doob@me.com> wrote:
>>
>>> On 2011-09-06 19:39, Steven Schveighoffer wrote:
>>>>
>>>> I like enums in terms of writing code that processes them, but in terms
>>>> of calling functions with them, I mean look at a sample fstream
>>>> constructor in C++:
>>>>
>>>> fstream ifs("filename.txt", ios_base::in | ios_base::out);
>>>>
>>>> vs.
>>>>
>>>> File("filename.txt", "r+"); // or "rw"
>>>>
>>>> There's just no way you can think "rw" is less descriptive or
>>>> understandable than ios_base::in | ios_base::out.
>>>>
>>>> -Steve
>>>
>>> But "r+" is. And that's what I assume will be used when I see a file
>>> opening function taking a string "mode" parameter. But if you say that
>>> "rw" can/will be used instead than that's better.
>>>
>>
>> Yes, I'll try to add "rw" and maybe some other letter combinations that
>> make sense in my next version.
>>
>> But I think we still have to support "r+", even though it's esoteric,
>> because too much existing code already does this, and to not support it
>> would leave silently compiling bugs.
>>
>> -Steve
>
> Didn't you just say that you would check the string at compile time?

You can if you make it a template parameter.  For example, my openFile function that I wrote does this (in fact, I needed a template mode string because the return type depends on it).  The downside is you cannot pass a runtime-generated string.  I cannot actually think of any use cases for that however.

In any case, the existing API does not use a template parameter, and we have to try and break as little code as possible.

I wonder if there's a way to give the option of using a template parameter or using a positional parameter without having two different symbol names.  hm...

openFile!(string modedefault = "r")(string filename, string mode = modedefault) if (isValidOpenMode(modedefault))
{
   if(!isValidOpenMode(mode))
      throw new Exception("invalid file open mode: " ~ mode);
   ...
}

Would that work?

-Steve

On 09/08/2011 03:05 PM, Jacob Carlborg wrote:
> On 2011-09-08 13:04, Steven Schveighoffer wrote:
>> On Wed, 07 Sep 2011 03:27:43 -0400, Jacob Carlborg <doob@me.com> wrote:
>>
>>> On 2011-09-06 19:39, Steven Schveighoffer wrote:
>>>>
>>>> I like enums in terms of writing code that processes them, but in terms
>>>> of calling functions with them, I mean look at a sample fstream
>>>> constructor in C++:
>>>>
>>>> fstream ifs("filename.txt", ios_base::in | ios_base::out);
>>>>
>>>> vs.
>>>>
>>>> File("filename.txt", "r+"); // or "rw"
>>>>
>>>> There's just no way you can think "rw" is less descriptive or
>>>> understandable than ios_base::in | ios_base::out.
>>>>
>>>> -Steve
>>>
>>> But "r+" is. And that's what I assume will be used when I see a file
>>> opening function taking a string "mode" parameter. But if you say that
>>> "rw" can/will be used instead than that's better.
>>>
>>
>> Yes, I'll try to add "rw" and maybe some other letter combinations that
>> make sense in my next version.
>>
>> But I think we still have to support "r+", even though it's esoteric,
>> because too much existing code already does this, and to not support it
>> would leave silently compiling bugs.
>>
>> -Steve
>
> Didn't you just say that you would check the string at compile time?
>

That is not compatible with the auto f = File(name, mode); interface.