On 2012-10-26 22:20, Walter Bright wrote:
> n 10/23/2012 1:47 PM, Mike van Dongen wrote:
>  > My code can be found here, at the bottom of the already existing file
> uri.d:
>  > https://github.com/MikevanDongen/phobos/blob/uri-parser/std/uri.d
>
> Needs to have a range interface, not a string interface.

For what, encoding/decoding?

-- 
/Jacob Carlborg

Walter Bright wrote:
> On 10/26/2012 2:13 AM, Jonathan M Davis wrote:> There's definitely some truth to that, but Walter in particular seems to be
> > against breaking anything period.
> 
> We have a number of fed up developers and abandoned, dead projects because of breaking changes.
> 
> It MUST STOP.

Can you point me to the data that you base you conclusions on? I wonder
whether each breaking change can be considered equal.
And what's the plan to improve Phobos then? Just have two modules?

Jens

On Sunday, October 28, 2012 11:32:14 Jens Mueller wrote:
> Walter Bright wrote:
> > On 10/26/2012 2:13 AM, Jonathan M Davis wrote:> There's definitely some truth to that, but Walter in particular seems to be
> > 
> > > against breaking anything period.
> > 
> > We have a number of fed up developers and abandoned, dead projects because of breaking changes.
> > 
> > It MUST STOP.
> 
> Can you point me to the data that you base you conclusions on?

I don't know everything that he's basing it on, but we've definitely had complaints in this newsgroup in the past over breaking changes (and it wouldn't surprise me if the folks in this newsgroup are more willing to put up with breaking changes than most D users). Even changes which are very popular can generate complaints about the code breakage that they cause. When the library is younger, it's not such a big deal, but as it matures, it becomes a very big deal. And at this point, we seem to be mature enough that we're moving away from the stage where it's okay to break stuff without a very good reason. Certainly, if we don't reach there soon, then it's going to be much harder for D to catch on. We'd like to get to the point that we don't  break anything ever (or at least don't break anything without a major version change of some kind).

> I wonder whether each breaking change can be considered equal.

I think that you can talk Walter into breaking changes if doing so is very beneficial (e.g. we're looking at removing opEquals, opCmp, toHash, and toString from Object because doing so would have huge benefits with regards to const-correctness among other things), but something as simple as renaming a function or module definitely isn't going to sit well with him, pretty much regardless of how much code uses it or how simple a change it is.

> And what's the plan to improve Phobos then? Just have two modules?

In this case, if moving std.curl to std.net.curl isn't deemed worth the breakage that it would cause (and I'd be very suprised if Walter thought that it was), then we'd probably just keep std.curl and not move it at all. And while reorganizing some modules might be desirable, it really doesn't buy us much. I'd strongly argue that if it's not worth putting a module through the deprecation process in order to rename it, then it shouldn't be renamed at all. Having both std.curl and std.net.curl around permanently (even if one is basically an alias of the other), just seems like a bad idea to me. It creates clutter in the library. Best case, we could rename std.curl to std.net.curl, leaving std.curl empty save for the fact that it publicly imports std.net.curl, undocument std.curl completely, and then leave it around as undocumented, but that still creates clutter. It's just less visible.

Aside from there being two modules as part of deprecating one and getting code to use the new one (which we really do want to stop doing), then I would only expect us to end up with two modules if we completely revamped a module but didn't want to break code using the old version (e.g. std.xml - > std.xml2).

- Jonathan m Davis

On 2012-10-28 12:39, Jonathan M Davis wrote:

> I don't know everything that he's basing it on, but we've definitely had
> complaints in this newsgroup in the past over breaking changes (and it
> wouldn't surprise me if the folks in this newsgroup are more willing to put up
> with breaking changes than most D users). Even changes which are very popular
> can generate complaints about the code breakage that they cause. When the
> library is younger, it's not such a big deal, but as it matures, it becomes a
> very big deal. And at this point, we seem to be mature enough that we're
> moving away from the stage where it's okay to break stuff without a very good
> reason. Certainly, if we don't reach there soon, then it's going to be much
> harder for D to catch on. We'd like to get to the point that we don't  break
> anything ever (or at least don't break anything without a major version change
> of some kind).

I think we should be able to break code when there's a good reason for it. The RailsConf 2012 had a great talk called "Progress". I think it's really worth seeing:

http://www.youtube.com/watch?v=VOFTop3AMZ8

> In this case, if moving std.curl to std.net.curl isn't deemed worth the
> breakage that it would cause (and I'd be very suprised if Walter thought that
> it was), then we'd probably just keep std.curl and not move it at all. And
> while reorganizing some modules might be desirable, it really doesn't buy us
> much. I'd strongly argue that if it's not worth putting a module through the
> deprecation process in order to rename it, then it shouldn't be renamed at
> all. Having both std.curl and std.net.curl around permanently (even if one is
> basically an alias of the other), just seems like a bad idea to me. It creates
> clutter in the library. Best case, we could rename std.curl to std.net.curl,
> leaving std.curl empty save for the fact that it publicly imports
> std.net.curl, undocument std.curl completely, and then leave it around as
> undocumented, but that still creates clutter. It's just less visible.

That's way we need to stop this madness of putting all modules in the "std" package. BTW, this should have happened five years ago.

> Aside from there being two modules as part of deprecating one and getting code
> to use the new one (which we really do want to stop doing), then I would only
> expect us to end up with two modules if we completely revamped a module but
> didn't want to break code using the old version (e.g. std.xml - > std.xml2).
>
> - Jonathan m Davis
>


-- 
/Jacob Carlborg

Been thinking about this for a while now, but I can't decide which one I should choose.

Currently there is a class URI which has an static method (parser) which returns an instance of URI on success. On failure it will return null.

I agree with Jens Mueller on the fact that URI should be a struct instead of a class. But then I won't be able to return null anymore so I should throw an exception when an invalid URI has been passed to the constructor.

I'm not sure if this is how problems are being handled in phobos.


Something entirely else is the CTFE compatibility of URI. At first I though that because a new instance of URI can be created as a const, it would be evaluated on compile time.
This is part of how I test CTFE at the moment:

const URI uri36 = URI.parse("http://dlang.org/");
assert(uri36.scheme == "http");

I tried changing 'const' to 'static' but that resulted in an error.
(_adSort cannot be interpreted at compile time, because it has no available source code)

Now I'm not sure anymore how to test if my code meets the CTFE requirements.


I hope someone can shed some light on my problems and help me make a decision.

> Something entirely else is the CTFE compatibility of URI. At first I though that because a new instance of URI can be created as a const, it would be evaluated on compile time.
> This is part of how I test CTFE at the moment:
>
> const URI uri36 = URI.parse("http://dlang.org/");
> assert(uri36.scheme == "http");
>
> I tried changing 'const' to 'static' but that resulted in an error.
> (_adSort cannot be interpreted at compile time, because it has no available source code)
>
> Now I'm not sure anymore how to test if my code meets the CTFE requirements.

To force something to be evaluated at compile time, you can assign it to an enum, like this:

enum uri = URI.parse("http://dlang.org/");

On Thursday, 8 November 2012 at 15:32:59 UTC, jerro wrote:
>> Something entirely else is the CTFE compatibility of URI. At first I though that because a new instance of URI can be created as a const, it would be evaluated on compile time.
>> This is part of how I test CTFE at the moment:
>>
>> const URI uri36 = URI.parse("http://dlang.org/");
>> assert(uri36.scheme == "http");
>>
>> I tried changing 'const' to 'static' but that resulted in an error.
>> (_adSort cannot be interpreted at compile time, because it has no available source code)
>>
>> Now I'm not sure anymore how to test if my code meets the CTFE requirements.
>
> To force something to be evaluated at compile time, you can assign it to an enum, like this:
>
> enum uri = URI.parse("http://dlang.org/");

Thnx. Got myself some new errors ;)
It seems that std.string.indexOf() does not work at compile time. Is there a solution or alternative method for this?

> Thnx. Got myself some new errors ;)
> It seems that std.string.indexOf() does not work at compile time. Is there a solution or alternative method for this?

I guess the proper solution would be to make std.string.indexOf work at compile time. It looks like changing the first

if (std.ascii.isASCII(c))

line in std.string.indexOf to

if (!__ctfe && std.ascii.isASCII(c))


Makes it work at compile time.

On Thursday, 8 November 2012 at 17:02:25 UTC, jerro wrote:
>> Thnx. Got myself some new errors ;)
>> It seems that std.string.indexOf() does not work at compile time. Is there a solution or alternative method for this?
>
> I guess the proper solution would be to make std.string.indexOf work at compile time. It looks like changing the first
>
> if (std.ascii.isASCII(c))
>
> line in std.string.indexOf to
>
> if (!__ctfe && std.ascii.isASCII(c))
>
>
> Makes it work at compile time.

After trying your solution I found out I was calling indexOf(string, char) which apparently is different than indexOf(string, string) as I now no longer have that error.
Instead, when I call parse on compile time I get the following at the method parse:
Error: URI class literals cannot be returned from CTFE

The method returns an instance of class URI and works perfectly when called at runtime.
As far as I can see it has nothing to do with my previous problem. I do thank you for your answer.

> After trying your solution I found out I was calling indexOf(string, char) which apparently is different than indexOf(string, string) as I now no longer have that error.
> Instead, when I call parse on compile time I get the following at the method parse:
> Error: URI class literals cannot be returned from CTFE

It looks like you can't have class enums. This fails too:

class A{}
enum a = new A;

I don't think you can get around this, but you can still test if your URI class works at compile time by doing something like this:

auto foo()
{
   // Write code that uses the URI class here

   // return something that can be assigned to an enum
   return something;
}

enum bar = foo();