View mode: basic / threaded / horizontal-split · Log in · Help
March 09, 2012
Re: Breaking backwards compatiblity
On 03/10/2012 12:09 AM, Nick Sabalausky wrote:
> "Nick Sabalausky"<a@a.a>  wrote in message
> news:jje2cg$27tg$1@digitalmars.com...
>> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
>> news:jje0er$24mb$1@digitalmars.com...
>>> This statement is from Linus Torvalds about breaking binary
>>> compatibility:
>>>
>>> https://lkml.org/lkml/2012/3/8/495
>>>
>>> While I don't think we need to worry so much at the moment about breaking
>>> binary compatibility with new D releases, we do have a big problem with
>>> breaking source code compatibility.
>>>
>>> This is why we need to have a VERY high bar for breaking changes.
>>
>> Freezing things against breaking changes is all fine and good, but NOT
>> before they're reached a point where they're good enough to be frozen.
>> Premature freezing is how you create cruft and other such shit. Let's not
>> go jumping any guns here.
>>

+1.

>
> Keep in mind, too, that Linux has decades of legacy and millions of users.
> That's a *very* different situation from Phobos. Apples and oranges.
>
>

+1.
March 09, 2012
Re: Breaking backwards compatiblity
On Friday, March 09, 2012 15:14:39 H. S. Teoh wrote:
> On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote:
> > On 09-03-2012 23:32, Walter Bright wrote:
> > >This statement is from Linus Torvalds about breaking binary
> > >compatibility:
> > >
> > >https://lkml.org/lkml/2012/3/8/495
> > >
> > >While I don't think we need to worry so much at the moment about
> > >breaking binary compatibility with new D releases, we do have a big
> > >problem with breaking source code compatibility.
> > >
> > >This is why we need to have a VERY high bar for breaking changes.
> > 
> > If we want to start being able to avoid breaking changes, we
> > *really* need to finally deprecate the stuff that's been slated for
> > deprecation for ages...
> 
> [...]
> 
> Does that include std.stdio and std.stream? When are we expecting std.io
> to be ready?
> 
> IMHO, this is one major change that needs to happen sooner rather than
> later. The current lack of interoperability between std.stdio and
> std.stream is a big detraction from Phobos' overall quality.

Note that he didn't say that we should _never_ make breaking changes but 
rather that we need to have a very high bar for making such changes. In 
particular, it's stuff like renaming functions without changing functionality 
that he's against.

If a module really needs a rewrite, then it'll get a rewrite, but we also need 
to do our best to avoid the need. And in the long run, it will hopefully be 
incredibly rare that we'll consider replacing modules. But there _are_ a few 
modules which are going to be replaced or rewritten. It's just that those are 
the modules that really need it and therefore meet the high bar required to 
make such changes.

- Jonathan M Davis
March 09, 2012
Re: Breaking backwards compatiblity
On Fri, 09 Mar 2012 18:14:39 -0500, H. S. Teoh <hsteoh@quickfur.ath.cx>  
wrote:

> On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote:
>> On 09-03-2012 23:32, Walter Bright wrote:
>> >This statement is from Linus Torvalds about breaking binary  
>> compatibility:
>> >
>> >https://lkml.org/lkml/2012/3/8/495
>> >
>> >While I don't think we need to worry so much at the moment about
>> >breaking binary compatibility with new D releases, we do have a big
>> >problem with breaking source code compatibility.
>> >
>> >This is why we need to have a VERY high bar for breaking changes.
>>
>> If we want to start being able to avoid breaking changes, we
>> *really* need to finally deprecate the stuff that's been slated for
>> deprecation for ages...
> [...]
>
> Does that include std.stdio and std.stream? When are we expecting std.io
> to be ready?

Sadly, I have no guarantees for when it will be ready.  The rewrite is  
mostly in place, what I'm struggling with is how to make it backwards  
compatible with std.stdio.  Specifically, I think I need to rewrite  
std.typecons.RefCounted to be more flexible.

> IMHO, this is one major change that needs to happen sooner rather than
> later. The current lack of interoperability between std.stdio and
> std.stream is a big detraction from Phobos' overall quality.

I agree, as I watch other modules which would benefit from the rewrite get  
more attention, I cringe hoping that it doesn't introduce something that  
would necessitate a complete rewrite with the new system (thereby making  
my case for rewriting std.stdio weaker).

It's my number 1 priority for D.  The problem is that D is not my number 1  
priority right now :(

If you want to take a look so far (I haven't compiled in a long time since  
starting the migration to backwards compatibility):

https://github.com/schveiguy/phobos/blob/new-io2/std/io.d

I also have a trello card for it...

-Steve
March 10, 2012
Re: Breaking backwards compatiblity
Linus would probably hate D just as much as he hates C++. :p
March 10, 2012
Re: Breaking backwards compatiblity
On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
> This is why we need to have a VERY high bar for breaking 
> changes.

Please remember this if someone proposes enforcing
@property by default.

The -property switch is a big mistake that breaks a
lot of code.
March 10, 2012
Re: Breaking backwards compatiblity
On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
> This is why we need to have a VERY high bar for breaking 
> changes.

Oh, and how do you intend to accomplish that with things like bug 
314 still being open (and code relying on the buggy behavior), 
and not even the language being finalized (think: shared)?

David
March 10, 2012
Re: Breaking backwards compatiblity
On Sat, Mar 10, 2012 at 01:02:35AM +0100, Andrej Mitrovic wrote:
> Linus would probably hate D just as much as he hates C++. :p

Yeah... I can just imagine his eye scanning the description of D and
stopping right at the word "GC", and immediately writing a flaming
vitriolic post to LKML about how a GC is the absolutely worst thing one
could possibly conceive of putting inside a kernel, and that any kernel
developer caught flirting with the idea of using D ought to have all
kernel patches ignored from that point on.

:-)


T

-- 
Amateurs built the Ark; professionals built the Titanic.
March 10, 2012
Re: Breaking backwards compatiblity
On Saturday, March 10, 2012 01:12:34 Adam D. Ruppe wrote:
> On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
> > This is why we need to have a VERY high bar for breaking
> > changes.
> 
> Please remember this if someone proposes enforcing
> @property by default.
> 
> The -property switch is a big mistake that breaks a
> lot of code.

As I understand it, it's like override, it's being phased in, and it _will_ 
become the normal behavior.

There are also a number of things in the language that are supposed to be 
deprecated but have been sitting around for ages without actually being 
deprecated (e.g. delete).

Walter's sentiments may be good, but there are a number of things which are 
still in a transitional phase and _will_ end up breaking code. Of course, I'd
argue that stuff like deprecating/removing delete and fully enabling override
and @property _do_ pass the very high bar.

I think that his biggest complaint is minor changes (such as changing function
names) rather than the large changes that are still being made.

- Jonathan M Davis
March 10, 2012
Re: Breaking backwards compatiblity
On Friday, March 09, 2012 16:15:13 H. S. Teoh wrote:
> On Sat, Mar 10, 2012 at 01:02:35AM +0100, Andrej Mitrovic wrote:
> > Linus would probably hate D just as much as he hates C++. :p
> 
> Yeah... I can just imagine his eye scanning the description of D and
> stopping right at the word "GC", and immediately writing a flaming
> vitriolic post to LKML about how a GC is the absolutely worst thing one
> could possibly conceive of putting inside a kernel, and that any kernel
> developer caught flirting with the idea of using D ought to have all
> kernel patches ignored from that point on.

He hates function overloading! I question that he'd ever be happy with 
anything other than C. And he's so specialized in what he works on that I 
think that a number of his opinions are completely inapplicable to the 
majority of programmers. Some of what he says is very valuable, but he's a 
very opinionated person whose opinions often don't line up with the rest of 
the programming world. If you'll notice, Walter sometimes has similar issues 
simply due to the kind of stuff he works on (e.g. thinking that the fact that 
you could run your program in a debugger to see a segfault was enough (rather 
than getting some sort of stacktrace with a segfault), which works great for 
compilers, but works horribly for programs that run for weeks at a time). We 
all have our biases based on what we've worked on. Linus just so happens to be 
very famous and _very_ specialized in the type of stuff that he works on.

- Jonathan M Davis
March 10, 2012
Re: Breaking backwards compatiblity
On Fri, 09 Mar 2012 19:12:34 -0500, Adam D. Ruppe  
<destructionator@gmail.com> wrote:

> On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
>> This is why we need to have a VERY high bar for breaking changes.
>
> Please remember this if someone proposes enforcing
> @property by default.

Clears the bar with room to spare IMO.

Not to mention it's not just a proposal, but in print in TDPL .

(dons flame war proof suit)

-STeve
1 2 3 4 5 6
Top | Discussion index | About this forum | D home