View mode: basic / threaded / horizontal-split · Log in · Help
December 03, 2012
Re: Deprecated Library Functions / Methods
On Sunday, 2 December 2012 at 19:06:22 UTC, Jonathan M Davis 
wrote:
> On Sunday, December 02, 2012 14:19:18 deed wrote:
>> Why not let all breaking improvements go to a clear cut std2 
>> and
>> let std be improved only with extensions and bug fixes? When 
>> std2
>> is ready enough, let the same happen and breaking code goes to
>> std3.
>> 
>> Then you get std.xml and std2.xml, which are different and a
>> probable source of confusion. On the other hand, the modules in
>> the standard library do not exist independently, they are part 
>> of
>> a unified design and layout. So it may be more valuable to know
>> that std3.algorithm, std3.range, std3.container, etc. work
>> together out of the box, rather than to know whether
>> std.algorithm2 and std.range3 are compatible.

>
> Duplicating the entire standard library is overkill. Ideally, 
> we wouldn't need
> to keep making breaking changes to it. You get it right, and 
> then you leave it
> as-is. The main problem is that Phobos has been being written 
> as the language
> has been evolving..

It may introduce more administrative work, but should solve most 
problems in both camps.
December 03, 2012
Re: Deprecated Library Functions / Methods
On 12/3/12 3:37 AM, Walter Bright wrote:
> On 12/3/2012 6:44 PM, Jacob Carlborg wrote:
>> On 2012-12-02 22:28, Walter Bright wrote:
>>
>>> For this case (and others like it) I strongly suggest putting the revamp
>>> in something called std.xml2, and keep std.xml, but let std.xml wither
>>> and die away of its own accord rather than killing it.
>>
>> Then we'll be stuck with a stupid name like xml2, just because the
>> correct name was already taken by something broken.
>
> So call it xmlex like Microsoft does. The exact name isn't that precious.

I'm thinking it would be nice to just define a package xtd that contains 
"new style" std libraries.

Andrei
December 03, 2012
Re: Deprecated Library Functions / Methods
Andrei Alexandrescu:

> I'm thinking it would be nice to just define a package xtd that 
> contains "new style" std libraries.

Where do you put the libs if there's one more update? Calling it
std.xml2, std.xml3, etc is easy to understand and to find, it's
short and future proof, and there's no need to remember new names
like "xmlex" (I sometimes don't remember what's the name of the
updated regex lib. If they are named std.re1, std.re2, std.re3,
etc there isn't that risk).

Bye,
bearophile
December 03, 2012
Re: Deprecated Library Functions / Methods
On Monday, 3 December 2012 at 15:56:53 UTC, bearophile wrote:
> Calling it
> std.xml2, std.xml3, etc is easy to understand and to find, it's
> short and future proof

Yes. And if we also do std.xml1 then going to 2 won't seem weird.

We've had version discussions before, both here and on project 
downloads like that one DIP. The easiest solution for libraries, 
old projects, and end users is to just stick a number in the name.

Easy, obvious, functional.
December 03, 2012
Re: Deprecated Library Functions / Methods
On 12/3/12 10:56 AM, bearophile wrote:
> Andrei Alexandrescu:
>
>> I'm thinking it would be nice to just define a package xtd that
>> contains "new style" std libraries.
>
> Where do you put the libs if there's one more update? Calling it
> std.xml2, std.xml3, etc is easy to understand and to find, it's
> short and future proof, and there's no need to remember new names
> like "xmlex" (I sometimes don't remember what's the name of the
> updated regex lib. If they are named std.re1, std.re2, std.re3,
> etc there isn't that risk).
>
> Bye,
> bearophile

Yup, there's a certain advantages to using numbers :o).

Andrei
December 03, 2012
Re: Deprecated Library Functions / Methods
Am Mon, 03 Dec 2012 08:37:15 +1100
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 12/2/2012 10:26 PM, Johannes Pfau wrote:
> > Avoiding breaking code is always a good goal, but I think it's too
> > early for phobos. Code like std.xml, std.outbuffer should have never
> > been a part of phobos. I think one last big break would be best for
> > everyone.
> 
> No, no, no!
> 

OK, I see I won't convince you so we probably won't have a big
break ;-) But I still believe it's too early for phobos to be stable.

In the end we have to choose between stabilizing phobos now or having a
consistent interface (ranges, naming conventions) in all modules.

> > Right now we have can't promise not to break code because
> > we can't keep and support code like std.xml forever
> 
> Yes, we can (or at least for a very long time).

But having broken, unsupported code like that in phobos isn't exactly
good advertising for phobos. And even if we mark it as deprecated and
"don't use this" people will keep using it as long as there is no
alternative and they will still complain if it's removed later on.
> 
> > but we also can't
> > simply remove std.xml because we try to avoid breaking code. So we
> > deprecate small parts of modules in every release which is a pita
> > for everyone. Dropping all sub-par code and fixing naming
> > conventions in one release would get us a clean restart without all
> > that cruft.
> 
> No, it won't, because names are a bikeshedding thing and every group
> of name changes spawns more name change proposals. Every big break
> (and we've done them before) spawns more big break proposals. We have
> to stop doing this, or D will never ever advance.

Did we really have big breaks before? If those didn't work out well
then another one is probably not a good idea.

Regarding names: Choosing the actual name often is bikeshedding but
naming conventions (casing, no underscores, etc) are well defined and
we still have modules in phobos which don't conform to them.
> 
> The existence of std.xml that is ignored and left out of the 
> documentation is not going to discourage people from using D, but 
> constantly telling people they have to rewrite their existing,
> working, and stable code will, as the start of this thread shows.
> 

But people may question the standard libraries quality if modules like
std.xml are part of it.
December 03, 2012
Re: Deprecated Library Functions / Methods
On 12/4/2012 3:23 AM, Andrei Alexandrescu wrote:
> Yup, there's a certain advantages to using numbers :o).

It's almost like there's an implied ordering to them!
Next ›   Last »
2 3 4 5 6
Top | Discussion index | About this forum | D home