On Tue, 06 Sep 2011 14:07:01 -0400, Martin Nowak <dawg@dawgfoto.de> wrote:

> On Tue, 06 Sep 2011 19:54:28 +0200, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 9/6/2011 7:51 AM, Andrei Alexandrescu wrote:
>>> 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.
>>
>> std.xml2
>>
>> will do fine.
>
> Speaking of xml2 I clearly like to see an attempt of buffered lookahead reading for a stream/stdio overhaul.
> Writing range adapters with even only fixed lookahead on top of the current stream API is painful.

This is exactly the reason for the overhaul.  I'm working on it, and I think my next version will be much more backwards compatible.

See in the proposed documentation readUntil, and look at the byChunk implementation to see how it's used.

The intention was to use the buffer as an expandable scratch space to do things like parsing xml files without copying.

-Steve

On Tue, 06 Sep 2011 14:13:45 -0400, Marco Leise <Marco.Leise@gmx.de> wrote:

> Am 06.09.2011, 16:51 Uhr, schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
>
>> 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
>
> What about:
>
>             std.xml1
> std.xml -> std.xml2
>
> So std.xml is a symbolic link to std.xml2 in the next release or std.xml2 public imports std.xml ?
> This is what /bin/python is on my computer.

That only works/is worth it if std.xml2 is backwards compatible with std.xml1.

-Steve

On Tue, Sep 6, 2011 at 8:51 AM, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> 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
>

Along these same lines I'm wondering why not simply call this new module std.io rather than use the existing name std.stdio?  It'd avoid the code breaking issue and help reflect that this new module isn't based around C's stdio FILE (at least that's what I gather).  Also, the code is written from scratch so that's another reason for why I don't think it should have the same name.  The only reason I can think of is if it provided significant improvements over the existing std.stdio without causing massive breakage.

Regards,
Brad Anderson

On Tue, 06 Sep 2011 14:21:52 -0400, Brad Anderson <eco@gnuk.net> wrote:

> On Tue, Sep 6, 2011 at 8:51 AM, Andrei Alexandrescu <
> SeeWebsiteForEmail@erdani.org> wrote:
>
>>
>> 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;
>
> Along these same lines I'm wondering why not simply call this new module
> std.io rather than use the existing name std.stdio?  It'd avoid the code
> breaking issue and help reflect that this new module isn't based around C's
> stdio FILE (at least that's what I gather).  Also, the code is written from
> scratch so that's another reason for why I don't think it should have the
> same name.  The only reason I can think of is if it provided significant
> improvements over the existing std.stdio without causing massive breakage.

I think for something like std.xml which is somewhat of a standalone module, this is fine.

However, i/o is used *everywhere*.  It's the same situation with std.datetime.  We can't duplicate all functions which deal with i/o in order to cater to both the stdio and the std.io folks, I think it's a waste of time, and it also looks bad.

But I think I have come up with a plan (obviously not the one posted here) which keeps stdio's API compatible, yet can use the new stuff I've written if desired. i.e. provides improvements over the current std.stdio without causing massive breakage.

Coincidentally, std.io is the name I chose for the new module ;)

I'll post again when it's something that can be shared.  I want to get all my ducks in a row first (obviously more than I did this time...)

-Steve

On 9/6/11 12:54 PM, Walter Bright wrote:
> On 9/6/2011 7:51 AM, Andrei Alexandrescu wrote:
>> 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.
>
> std.xml2
>
> will do fine.

Since the BDFL and the majority of his constituents are in favor of this, it looks like the winner.

Andrei

On 9/6/2011 12:03 PM, Andrei Alexandrescu wrote:
> Since the BDFL

Brain-Damaged Feckless Leader?

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

On 06.09.2011 19:54, Walter Bright wrote:
> On 9/6/2011 7:51 AM, Andrei Alexandrescu wrote:
>> 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.
>
> std.xml2
>
> will do fine.

> Along these same lines I'm wondering why not simply call this new module
> std.io <http://std.io> rather than use the existing name std.stdio?
>   It'd avoid the code breaking issue and help reflect that this new
> module isn't based around C's stdio FILE (at least that's what I
> gather).  Also, the code is written from scratch so that's another
> reason for why I don't think it should have the same name.  The only
> reason I can think of is if it provided significant improvements over
> the existing std.stdio without causing massive breakage.
>
> Regards,
> Brad Anderson

I think this is a good idea. I think std.io sounds and feels much better.

Mafi

On Tuesday, September 06, 2011 21:42:09 Dmitry Olshansky wrote:
> On 06.09.2011 21:05, Daniel Murphy wrote:
> > "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>  wrote in message news:j45isu$2t3h$1@digitalmars.com...
> > 
> >> Yah, I also think the documentation makes it easy to clarify which module is the preferred one.
> >> 
> >> I think there's a lot of merit to simply appending a '2' to the module name. There only place where the '2' occurs is in the name of the module, and there aren't many modules we need to replace like that.
> > 
> > I still can never remember if I'm supposed to be using std.regex or std.regexp.
> 
> Looking at the docs: std.regexp is scheduled for deprecation (in August ? hm... that was a bit harsh).

std.regexp has been scheduled for deprecation for ages. It just hasn't had a date attached to it. It'll be deprecated in 2.055.

- Jonathan M Davis

On 09/06/2011 09:09 PM, Walter Bright wrote:
> On 9/6/2011 12:03 PM, Andrei Alexandrescu wrote:
>> Since the BDFL
>
> Brain-Damaged Feckless Leader?

Benevolent Dictator For Life ;)