Jonathan M Davis wrote:
> On Thursday, October 25, 2012 23:05:14 Jens Mueller wrote:
> > Jonathan M Davis wrote:
> > > On Thursday, October 25, 2012 15:59:39 Jens Mueller wrote:
> > > > * Should URIs be only movable? Then you should add
> > > > @disable this(this);
> > > 
> > > I'd be shocked if that were appropriate. Disabling the init property like that should be done extremely rarely and only if you need to. It's problematic that that feature exists at all.
> > 
> > That does not disable the init property. It does disable copying.
> 
> Ah true. I read it too quickly. Regardless, disabling much of _anything_ is something that you shouldn't be doing normally (though disabling init is definitely the worst). It's far, far better to implement the postblit when a shallow copy doesn't do what you want.

Yeah. And probably here you want to implement it.

Jens

On 2012-10-25 23:06, Jens Mueller wrote:

> I'd prefer the second option. Maybe write first some unittests for
> std.uri, if there are none. Then move it.

Agree, but we want to minimize the code breakage.

-- 
/Jacob Carlborg

Jacob Carlborg wrote:
> On 2012-10-25 23:06, Jens Mueller wrote:
> 
> >I'd prefer the second option. Maybe write first some unittests for std.uri, if there are none. Then move it.
> 
> Agree, but we want to minimize the code breakage.

That's what the unittests are for.
Code breakage that results in compiler errors (i.e. using deprecate) are
tolerable, I think. Silently code breakage is problematic.

Jens

On Friday, October 26, 2012 10:11:04 Jens Mueller wrote:
> Jacob Carlborg wrote:
> > On 2012-10-25 23:06, Jens Mueller wrote:
> > >I'd prefer the second option. Maybe write first some unittests for std.uri, if there are none. Then move it.
> > 
> > Agree, but we want to minimize the code breakage.
> 
> That's what the unittests are for.
> Code breakage that results in compiler errors (i.e. using deprecate) are
> tolerable, I think. Silently code breakage is problematic.

No. The issue is code breakage in the code of people using Phobos, and if you change where the module is, you'll break code. Even if we provide a deprecation path from std.uri to std.net.uri, that still means that people will have to change their code eventually, meaning that you still have code breakage (it's just better controlled). Making the change has to be worth breaking people's code, and making breaking changes to Phobos is becoming less and less acceptable. I don't know whether it is or isn't acceptable in this case.

- Jonathan M Davis

Jonathan M Davis wrote:
> On Friday, October 26, 2012 10:11:04 Jens Mueller wrote:
> > Jacob Carlborg wrote:
> > > On 2012-10-25 23:06, Jens Mueller wrote:
> > > >I'd prefer the second option. Maybe write first some unittests for std.uri, if there are none. Then move it.
> > > 
> > > Agree, but we want to minimize the code breakage.
> > 
> > That's what the unittests are for.
> > Code breakage that results in compiler errors (i.e. using deprecate) are
> > tolerable, I think. Silently code breakage is problematic.
> 
> No. The issue is code breakage in the code of people using Phobos, and if you change where the module is, you'll break code. Even if we provide a deprecation path from std.uri to std.net.uri, that still means that people will have to change their code eventually, meaning that you still have code breakage (it's just better controlled). Making the change has to be worth breaking people's code, and making breaking changes to Phobos is becoming less and less acceptable. I don't know whether it is or isn't acceptable in this case.

We should add the cost of fixing to the equation.
When code is easy to fix I argue it should always be done.
In case of std.uri any import of it needs to be fixed, i.e. the fixing
cost is very low.
I wish we had some estimate how much code is affected. Can't we release
the web page stats or something similar? This way we may estimate how
much a module is used. Crawling github is also an option.
I don't want to be in a situation where we cannot change things because
we have to assume that infinite code is broken.
Or we provide an community approved way to have different incompatible
versions of a module. Andrei suggested the std.mymodule2 approach at
some point. It'll be nice if DConf discusses these organizational
problems. They are of strategic importance I firmly believe.

Jens

On Friday, October 26, 2012 10:59:17 Jens Mueller wrote:
> > No. The issue is code breakage in the code of people using Phobos, and if you change where the module is, you'll break code. Even if we provide a deprecation path from std.uri to std.net.uri, that still means that people will have to change their code eventually, meaning that you still have code breakage (it's just better controlled). Making the change has to be worth breaking people's code, and making breaking changes to Phobos is becoming less and less acceptable. I don't know whether it is or isn't acceptable in this case.
> 
> We should add the cost of fixing to the equation.

There's definitely some truth to that, but Walter in particular seems to be against breaking anything period. If it were entirely up to him, pretty much none of the breaking changes that have happened to Phobos' API over the last few years would have happened. And Andrei is beginning to oppose most breaking changes. So, the bar is getting pretty high for making breaking changes. Simply renaming stuff generally isn't going to cut it. This is arguably slightly more than simply renaming std.uri, because it's an issue of module organization rather than simply what its name is, but it's also arguably so trivial that the benefit is near zero.

I doubt that std.uri is a particularly heavily used module, but I have no idea how acceptable Walter or Andrei would find it to move it to std.net. In principle, it would be good, but in practice, I don't know. Whether it can happen or not probably comes down primarily to whether you can convince Andrei or not.

- Jonathan M Davis

Jonathan M Davis wrote:
> On Friday, October 26, 2012 10:59:17 Jens Mueller wrote:
> > > No. The issue is code breakage in the code of people using Phobos, and if you change where the module is, you'll break code. Even if we provide a deprecation path from std.uri to std.net.uri, that still means that people will have to change their code eventually, meaning that you still have code breakage (it's just better controlled). Making the change has to be worth breaking people's code, and making breaking changes to Phobos is becoming less and less acceptable. I don't know whether it is or isn't acceptable in this case.
> > 
> > We should add the cost of fixing to the equation.
> 
> There's definitely some truth to that, but Walter in particular seems to be against breaking anything period. If it were entirely up to him, pretty much none of the breaking changes that have happened to Phobos' API over the last few years would have happened. And Andrei is beginning to oppose most breaking changes. So, the bar is getting pretty high for making breaking changes. Simply renaming stuff generally isn't going to cut it. This is arguably slightly more than simply renaming std.uri, because it's an issue of module organization rather than simply what its name is, but it's also arguably so trivial that the benefit is near zero.
> 
> I doubt that std.uri is a particularly heavily used module, but I have no idea how acceptable Walter or Andrei would find it to move it to std.net. In principle, it would be good, but in practice, I don't know. Whether it can happen or not probably comes down primarily to whether you can convince Andrei or not.

Is it okay to have both modules and only state in std.uri's documentation that you shouldn't use it anymore (similar to std.xml)? This would break no code.

Jens

On Friday, October 26, 2012 11:27:40 Jens Mueller wrote:
> Is it okay to have both modules and only state in std.uri's documentation that you shouldn't use it anymore (similar to std.xml)? This would break no code.

If we were to move it, we'd temporarily leave a near-empty std.uri which publicly imported std.net.uri. At some later date, we'd then deprecate it, and then later actually remove it. There's a definite cost to leaving such a module around long term, because then you code floating around using both std.uri and std.net.uri. We might try something like removing it from the documentation instead of deprecating it (or at least delay that deprecation for a while), but then you'd have code silently using it without its developers knowing that they needed to change anything.

It can certainly be done, and there are things that can be done to mitigate how quickly code is broken, but if you move it, code _will_ be broken at some point, and if you leave what basically amounts to an alias around to it long term, there's a definite cost to that as well.

Personally, I wouldn't be against putting std.uri through the deprecation path and move it to std.net.uri, but I'm also almost certainly the person who has broken the most of Phobos' API in an effort to make it consistent (something which Walter has never been happy with). So, I'm not really in a position to approve such a change. At this point, I think that something like that pretty much has to go through Andrei.

- Jonathan M Davis

Jonathan M Davis wrote:
> On Friday, October 26, 2012 11:27:40 Jens Mueller wrote:
> > Is it okay to have both modules and only state in std.uri's documentation that you shouldn't use it anymore (similar to std.xml)? This would break no code.
> 
> If we were to move it, we'd temporarily leave a near-empty std.uri which publicly imported std.net.uri. At some later date, we'd then deprecate it, and then later actually remove it. There's a definite cost to leaving such a module around long term, because then you code floating around using both std.uri and std.net.uri. We might try something like removing it from the documentation instead of deprecating it (or at least delay that deprecation for a while), but then you'd have code silently using it without its developers knowing that they needed to change anything.
> 
> It can certainly be done, and there are things that can be done to mitigate how quickly code is broken, but if you move it, code _will_ be broken at some point, and if you leave what basically amounts to an alias around to it long term, there's a definite cost to that as well.
> 
> Personally, I wouldn't be against putting std.uri through the deprecation path and move it to std.net.uri, but I'm also almost certainly the person who has broken the most of Phobos' API in an effort to make it consistent (something which Walter has never been happy with). So, I'm not really in a position to approve such a change. At this point, I think that something like that pretty much has to go through Andrei.

It's a difficult compromise that has to be found. That's why I also want
more data to make a decision. But I'm actually more towards breaking
code if it makes sense.
Ideally we should be able to measure the impact that a breaking change
will have. deprecate allows something like this. I.e. deprecate it and
if you get lots of complaints rethink whether it is worth it. E.g.
setAssertHandler used to be deprecated. Now it is undeprecated.

Unfortunately there are no portable solutions. The only thing I found is
symbol versioning. But this is only supported by GNU ld.
These strategic issues need to be solved.

Jens

On 2012-10-26 11:53, Jens Mueller wrote:

> Unfortunately there are no portable solutions. The only thing I found is
> symbol versioning. But this is only supported by GNU ld.
> These strategic issues need to be solved.

There are many other solutions that can be used to easy this problem. The release process can be improved significantly, this has been discussed before. For example, provide a road map. Then people will know that's coming. Better release scheme. Releases of DMD, D and Phobos shouldn't necessarily be in the same release. We use a semantic version scheme:

http://semver.org/

This will make it easier for developers when they upgrade DMD. It basically let them know if something will break or not.

-- 
/Jacob Carlborg