On Sun, 04 Sep 2011 07:07:05 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2011-09-03 21:54, Andrei Alexandrescu wrote:
>> Hello,
>>
>>
>> There are a number of issues related to D's current handling of streams,
>> including the existence of the imperfect etc.stream and the
>> over-specialization of std.stdio.
>>
>> Steve has worked on an extensive overhaul of std.stdio which would
>> obviate the need for etc.stream and would improve both the generality
>> and efficiency of std.stdio.
>>
>> Please chime in with feedback; he's away from the Usenet but allowed me
>> to post this on his behalf. I uploaded the docs to
>>
>> http://erdani.com/d/new-stdio/phobos-prerelease/std_stdio.html
>>
>>
>> Thanks,
>>
>> Andrei
>>
>
> I think that openFile, File.open and CStream.open should shouldn't take a string as the mode, it should be an enum or similar. Andrei is making a big deal out of using enums instead of bools. A bool value can contain "true" or "false", a string can contain an infinite number of different values.

openFile takes it as a template argument, and it will fail at compile time if the parameter is not correct (if not now, it will when the library is ready for inclusion).

I agree that enum is cleaner and easier to deal with from the library's point of view, but we have 2 things going for us by using strings:

1. The string formats are backwards compatible, and well defined.  In fact, CStream.open just passes the mode string without modification to fopen.
2. The brevity of and ability to comprehend a string literal vs. multiple enums.

You can think of it like printf (or writef).  The format string has infinitely wrong possible format strings, which must be rejected at run time.  But I'll take that any day over C++'s format modifiers which are type checked at compile-time.

Remember, typically, string formats are most frequently literals, and easy to read/write.  While there is great potential for invalid parameters, the reality is this rarely happens, and if it does, the errors are seen immediately.

-Steve

On 2011-09-05 21:51:16 +0000, Walter Bright <newshound2@digitalmars.com> said:

> I'll again note that I know of know successful operating system or programming language that goes around breaking existing code unless it is really, really urgent.

Apple has been deprecating things a lot in Mac OS X. Deprecated APIs generally continue to work fine for a long time and only trigger warnings when you compile something that uses them, effectively making them inconvenient. Some deprecation messages that can't be compilation warnings are logged to the console when used instead (deprecated flags for instance), only once per process though.

Sometime APIs are truly disabled, but they are not removed. For instance, the old API for accessing the screen's pixels has become non-functional in Mac OS X 10.7 Lion. Only the new API introduced 10.6 works now, the old one was still there but you just get a null pointer.

Sometime APIs disappear when passing to a new architecture. For instance, Mac OS X still supports the old Carbon APIs, but only in 32-bit mode, those were never made available to 64-bit applications.

But what works well for an operating system is not necessarily what works well for a runtime and a standard library. What Apple does is meant to keep binary compatibility. Users are not expected to have the source code of their application at hand, nor the expertise to fix them. They deprecate things so the OS can move forward and introduce new features, and using deprecated APIs generally mean that your app will have trouble using new features or move to new architectures in the future.

The situation for the D standard library is a little different. If you compile D code, you do have the source code at hand. My take is that we should not remove deprecated APIs and thus break old programs unless keeping those APIs really cost too much or impede future improvements. Showing a deprecation message and marking them as deprecated in the documentation is important to incite people to use the non-deprecated APIs, but for simple things like name changes perhaps the deprecation message during compilation could be left out, as the improvement to annoyance ratio would be quite low.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2011-09-06 12:50, Steven Schveighoffer wrote:
> On Sun, 04 Sep 2011 07:07:05 -0400, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2011-09-03 21:54, Andrei Alexandrescu wrote:
>>> Hello,
>>>
>>>
>>> There are a number of issues related to D's current handling of streams,
>>> including the existence of the imperfect etc.stream and the
>>> over-specialization of std.stdio.
>>>
>>> Steve has worked on an extensive overhaul of std.stdio which would
>>> obviate the need for etc.stream and would improve both the generality
>>> and efficiency of std.stdio.
>>>
>>> Please chime in with feedback; he's away from the Usenet but allowed me
>>> to post this on his behalf. I uploaded the docs to
>>>
>>> http://erdani.com/d/new-stdio/phobos-prerelease/std_stdio.html
>>>
>>>
>>> Thanks,
>>>
>>> Andrei
>>>
>>
>> I think that openFile, File.open and CStream.open should shouldn't
>> take a string as the mode, it should be an enum or similar. Andrei is
>> making a big deal out of using enums instead of bools. A bool value
>> can contain "true" or "false", a string can contain an infinite number
>> of different values.
>
> openFile takes it as a template argument, and it will fail at compile
> time if the parameter is not correct (if not now, it will when the
> library is ready for inclusion).

If it validates the string at compile time than that's great.

> I agree that enum is cleaner and easier to deal with from the library's
> point of view, but we have 2 things going for us by using strings:
>
> 1. The string formats are backwards compatible, and well defined. In
> fact, CStream.open just passes the mode string without modification to
> fopen.
> 2. The brevity of and ability to comprehend a string literal vs.
> multiple enums.
>
> You can think of it like printf (or writef). The format string has
> infinitely wrong possible format strings, which must be rejected at run
> time. But I'll take that any day over C++'s format modifiers which are
> type checked at compile-time.

It's not very often I use the print format functions. Most of the time I use Tango and with Tango's format strings at least you don't have to specify the type.

> Remember, typically, string formats are most frequently literals, and
> easy to read/write. While there is great potential for invalid
> parameters, the reality is this rarely happens, and if it does, the
> errors are seen immediately.
>
> -Steve

I would not say that they are easy to read, or at least understand/remember what a given mode means. I always have to double check the documentation when using these kind of modes. I always have to check if a given mode creates a new file or not.

-- 
/Jacob Carlborg

On Tue, 06 Sep 2011 08:49:22 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2011-09-06 12:50, Steven Schveighoffer wrote:
>> On Sun, 04 Sep 2011 07:07:05 -0400, Jacob Carlborg <doob@me.com> wrote:
>>
>>> On 2011-09-03 21:54, Andrei Alexandrescu wrote:
>>>> Hello,
>>>>
>>>>
>>>> There are a number of issues related to D's current handling of streams,
>>>> including the existence of the imperfect etc.stream and the
>>>> over-specialization of std.stdio.
>>>>
>>>> Steve has worked on an extensive overhaul of std.stdio which would
>>>> obviate the need for etc.stream and would improve both the generality
>>>> and efficiency of std.stdio.
>>>>
>>>> Please chime in with feedback; he's away from the Usenet but allowed me
>>>> to post this on his behalf. I uploaded the docs to
>>>>
>>>> http://erdani.com/d/new-stdio/phobos-prerelease/std_stdio.html
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Andrei
>>>>
>>>
>>> I think that openFile, File.open and CStream.open should shouldn't
>>> take a string as the mode, it should be an enum or similar. Andrei is
>>> making a big deal out of using enums instead of bools. A bool value
>>> can contain "true" or "false", a string can contain an infinite number
>>> of different values.
>>
>> openFile takes it as a template argument, and it will fail at compile
>> time if the parameter is not correct (if not now, it will when the
>> library is ready for inclusion).
>
> If it validates the string at compile time than that's great.
>
>> I agree that enum is cleaner and easier to deal with from the library's
>> point of view, but we have 2 things going for us by using strings:
>>
>> 1. The string formats are backwards compatible, and well defined. In
>> fact, CStream.open just passes the mode string without modification to
>> fopen.
>> 2. The brevity of and ability to comprehend a string literal vs.
>> multiple enums.
>>
>> You can think of it like printf (or writef). The format string has
>> infinitely wrong possible format strings, which must be rejected at run
>> time. But I'll take that any day over C++'s format modifiers which are
>> type checked at compile-time.
>
> It's not very often I use the print format functions. Most of the time I use Tango and with Tango's format strings at least you don't have to specify the type.

writef is the same, %s is equivalent to calling toString().

But the format specifiers for Tango are also strings, and not compile-time verified.

My point was simply, using a string to indicate flags or formatting instructions is pretty efficient, easy to write, and easy to read.

>> Remember, typically, string formats are most frequently literals, and
>> easy to read/write. While there is great potential for invalid
>> parameters, the reality is this rarely happens, and if it does, the
>> errors are seen immediately.
>>
>> -Steve
>
> I would not say that they are easy to read, or at least understand/remember what a given mode means. I always have to double check the documentation when using these kind of modes. I always have to check if a given mode creates a new file or not.

Yeah, creating a new file is implied by a combination of modes.

The one that's confusing I think is that "a" is for append, but "+" kind of tacks on appending to any other mode.  It's not the most well-designed spec for file opening.  Add to that you have the "b" which is a noop on most OSes.

There is the possibility that we could accept an alternative open mode string, which we could design better.  But we have to keep fopen's spec, it's already used everywhere.

-Steve

On 9/6/11, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> There is the possibility that we could accept an alternative open mode string, which we could design better.  But we have to keep fopen's spec, it's already used everywhere.
>
> -Steve
>

Or an alternative enum instead of a string. I'm another one of those people who forgets what the various read/write modes are.

Walter Bright wrote:
> I don't think that is the reason PHP is such a bear to work with.

It is one of the problems with PHP, but I'm not sure it applies to D the same way.

Almost *every time* I write PHP, I either mess up a name or the
argument order. (Sometimes, PHP functions go src, dest, and sometimes
it's dest, src. Ugh! The worst part is it doesn't even catch this.
A name mismatch throws an error when it's run. Reversed arguments just
silently do the wrong thing.)

The random argument order is a huge huge pain.


Contrast with D, where I've almost never forgotten a name. Granted, it might be due to my auto-complete function so I type once and only once, but it just hasn't been a big deal.

Thanks to the UFCS with arrays, the argument order is almost always the same to work with that, so the much bigger problem never occurs.

Walter Bright wrote:
> I agree that the XML and JSON libraries need to be scrapped and rewritten.

Ugh, I actually use the std.json.

> Furthermore, in order to work successfully, gofix [...]

The easiest way to do that is run the compiler. If an error occurs, go to the given line of the problem and maybe automatically replace with the spell checker's suggestion. Then in case that's wrong, ask the user to confirm it.

... which is pretty much what my editor (vim) already does!


Changing names is annoying, but it's not a difficult task, with what we have now. The compiler already does 90% of the work, and even fairly simple editors will bring it to about 98%.

I'll bitch about it, but it isn't a big enough deal to bother with a gofix. Trivial fixes are already trivial fixes. I'd prefer to avoid them, but let's not forget that the compiler already does most the work.


The more annoying changes are where stuff changes wholesale, so the code needs to be rethought, data needs to be changed, and so on. These are just huge sinks of pain.

And, no, a long deprecation time doesn't change anything.
Whether I spend thousands of dollars today changing it or thousands
of dollars in six months changing it, the fact is I'm still out
thousands of dollars.

On 9/6/11 1:00 AM, Walter Bright wrote:
> On 9/5/2011 7:48 PM, Andrei Alexandrescu wrote:
>> I agree with all of the above. However, as is often the case, there's
>> more than
>> one side to the story.
>>
>> Bad APIs have their costs too. We can't afford to have an XML library
>> that
>> offers few and badly packaged features and comes at the tail of all
>> benchmarks.
>> We also can't afford a JSON library that is poorly designed and badly
>> written.
>> Ironically, the costs mostly manifest the same way: people will decide
>> not to
>> use D because it "lacks good libraries" and "is quirky to use". In
>> many ways a
>> language's standard library is a showcase of the language, and to a
>> newcomer an
>> inconsistent and awkward standard library affects the perception of the
>> language's quality.
>
> I agree that the XML and JSON libraries need to be scrapped and
> rewritten. But simply changing the names of otherwise successful APIs is
> not worth while.

I agree we should be increasingly hawkish about such changes.

>> c) possibly create programs a la gofix that help migration.
>
> gofix cannot fix books, articles, blogs, and presentations.
>
> Furthermore, in order to work successfully, gofix needs to be a complete
> D front end, capable of handling both the old and the new stuff. Doing a
> perl script would be a disaster. It's a substantial project, has a high
> risk of inadequacy, and I suspect our resources are better spent elsewhere.

I'm not so sure. We're experiencing an unprecedented surge in participation to all aspects of the D programming language, and I believe you and I should start thinking differently. A certain change of phase happened to me a couple of months ago, when I commented about some fix that removed an undue limitation: "sounds good, but Walter has many other things on his plate more important than this". Within hours, the fix was available as a pull request.

In this case, if one or more persons is/are determined enough to create dfix, it will happen regardless of whether you or I believe it's the optimal resource allocation.

> Considering also the problems people have running dmd and getting it to
> find their imports and libraries, add in having to run 'gofix' over
> their source code first, then patch up what gofix goofed up, seems a
> stretch.

I do agree dfix must work at least as well as Apple hardware :o).


Andrei

On 9/6/11 2:35 AM, Walter Bright wrote:
> On 9/5/2011 11:39 PM, Jacob Carlborg wrote:
>> We don't want to have a standard library like the one in PHP where
>> there seems
>> to be no naming conventions at all.
>
> I don't think that is the reason PHP is such a bear to work with.

Probably. At any rate, what I now think as a promising path is with new module names. Let's leave the likes of std.xml and std.json in peace, then pick a naming convention for the new ones and create whole new modules replacing them. Then people who are ready for the migration change

import std.xml;

with

import std.some_naming_convention_involving_xml;

and fix whatever code breakages that entails. If they're pleased with std.xml, nobody's holding a gun to their head.

Months and years go by, and nobody uses std.xml because the new module and the migration path are copiously advertised in the documentation. At that point we can discuss excising std.xml altogether and replacing it with the new one. And so the new becomes old, just like in dialectics.

There's a successful precedent in C++ - stringstream vs. strstream. The only missing thing is that C++ did not choose a naming convention because they limited themselves to only one header.

So what should we use? xml2? new_xml? FWIW we use the prefix "new_" at Facebook to good effect. Or should we, au contraire, use "old_" for the old module and advise people who want to stick with the old modules to change their imports?


Andrei

On 9/6/11 4:29 AM, Josh Simmons wrote:
> Other languages like C# and Java have large enterprise outfits backing
> their massive standard libraries too.
>
> I just think the effort is better spent creating a solid language and
> encouraging third party libraries through better tools.

As always finding the right balance is key. Community-grown languages such as PHP, Python, or Ruby also enjoy large libraries, so I don't think corporate support is a prerequisite. It would probably be a mistake to stop work on Phobos now.

For all I can tell I'm more annoyed by the energy spent on what I'd call "isometric churn" like changing names (even those used internally, sigh) and changing comments from /** */ to /++ +/. All that energy could go into adding value.


Andrei