September 06, 2011
Andrei Alexandrescu wrote:
> What should we use? xml2?

That might be a good idea. If D modules were to get in the habit
of writing their major version numbers as part of the name, it'd solve
this as well the dget automatic library downloading thingy in one go.

Going with new and old won't work if there should ever be a version 3 written.
September 06, 2011
On 2011-09-06 15:02, Steven Schveighoffer wrote:
> 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

Ok, I would prefer to use enums if they have sensible names. Something like this:

File.open(Mode.read | Mode.write); // for both read and write

-- 
/Jacob Carlborg
September 06, 2011
On 9/6/11 9:17 AM, Adam Ruppe wrote:
> 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.

Basic economics indicate that the difference is large.

Andrei
September 06, 2011
On 2011-09-06 16:17, Adam Ruppe wrote:
> 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.

You can always keep your own local copy of a module.

-- 
/Jacob Carlborg
September 06, 2011
On 9/6/11 10:05 AM, Jacob Carlborg wrote:
> On 2011-09-06 15:02, Steven Schveighoffer wrote:
>> 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
>
> Ok, I would prefer to use enums if they have sensible names. Something
> like this:
>
> File.open(Mode.read | Mode.write); // for both read and write

Honest, C's openmode strings have been around for so long, they hardly confuse anyone anymore. I'd rather use "rw" and call it a day.

Andrei

September 06, 2011
On 2011-09-06 16:51, Andrei Alexandrescu wrote:
> 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

I prefer to use "old_". Depending on what XML functionality we want we maybe want to have an xml package.

-- 
/Jacob Carlborg
September 06, 2011
Jacob Carlborg wrote:
> I prefer to use "old_".

There's two big problems with that though:

1) It still breaks the old code. It's an even easier fix, so this isn't too bad, but it is still broken.

2) What if a third version of a module comes along?
September 06, 2011
On Tue, 06 Sep 2011 11:11:27 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 9/6/11 10:05 AM, Jacob Carlborg wrote:
>> On 2011-09-06 15:02, Steven Schveighoffer wrote:
>>> 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
>>
>> Ok, I would prefer to use enums if they have sensible names. Something
>> like this:
>>
>> File.open(Mode.read | Mode.write); // for both read and write
>
> Honest, C's openmode strings have been around for so long, they hardly confuse anyone anymore. I'd rather use "rw" and call it a day.

That's not a valid fopen string ;)

The plus "+" is odd, especially with "a" meaning "append".

And there's that really useless "b" :)

But I think this does *not* invalidate the usage of strings to denote open mode, it just needs more design.  The good thing about it is, we can augment the string flags and be binary and perfectly backwards compatible.

-Steve
September 06, 2011
On 9/6/11, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 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?

I would say that's the right way to go. It's much easier to change an import than change code. Perhaps another alternative is to use version statements. DFL uses it for deprecated features that are still in the codebase and usable.

We don't want to punish people for using newer modules, we should encourage it. If they're forced to import "std.xml_new", they'll eventually have to change those imports to "std.xml" down the road when the older std.xml gets replaced by the new one. I assume people will just pick the first thing that they see, "std.xml" looks standard so they would pick that over "std.xml2".
September 06, 2011
On Tue, 06 Sep 2011 11:53:09 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 9/6/11, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> 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?
>
> I would say that's the right way to go. It's much easier to change an
> import than change code. Perhaps another alternative is to use version
> statements. DFL uses it for deprecated features that are still in the
> codebase and usable.

I agree.  I'd hate for the current std.xml to squat that name forever...

In a related story, why did digitalmars.com change D to mean D2 instead of just using new_D? :)

Also new coke.

-Steve
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19