View mode: basic / threaded / horizontal-split · Log in · Help
October 27, 2012
Re: Uri class and parser
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
October 28, 2012
Re: Uri class and parser
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
October 28, 2012
Re: Uri class and parser
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
October 28, 2012
Re: Uri class and parser
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
November 08, 2012
Re: Uri class and parser
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.
November 08, 2012
Re: Uri class and parser
> 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/");
November 08, 2012
Re: Uri class and parser
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?
November 08, 2012
Re: Uri class and parser
> 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.
November 08, 2012
Re: Uri class and parser
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.
November 08, 2012
Re: Uri class and parser
> 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();
1 2 3 4 5 6
Top | Discussion index | About this forum | D home