View mode: basic / threaded / horizontal-split · Log in · Help
October 25, 2012
Re: Uri class and parser
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
October 26, 2012
Re: Uri class and parser
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
October 26, 2012
Re: Uri class and parser
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
October 26, 2012
Re: Uri class and parser
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
October 26, 2012
Re: Uri class and parser
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
October 26, 2012
Re: Uri class and parser
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
October 26, 2012
Re: Uri class and parser
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
October 26, 2012
Re: Uri class and parser
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
October 26, 2012
Re: Uri class and parser
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
October 26, 2012
Re: Uri class and parser
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
1 2 3 4 5 6
Top | Discussion index | About this forum | D home