"#absolute?"

I wouldn't add extensive specs for relative? since it is just ! absolute?. One example to ensure it generally works is enough.
The other examples should be moved to spec absolute? to spec all variants in one place.

A URI is only considered absolute if it specifies a scheme and hierarchical part (authority and/or path). For example, http://#foo is a relative URI. The implementation needs to take that into account as well.

Just curious is http://#foo valid URL?

Also URI.parse("http://#foo").host # => "" empty string.

Is it OK?

def absolute?
  @scheme && !@host.try(&.empty?) ? true : false
end

Just curious is http://#foo valid URL?

The question should be, is it a valid URI. And yes, it is. Obviously, it doesn't make much sense, but serves to illustrate the issue.

@scheme && !@host.try(&.empty?) seems to work with URI.parse. But it looks like this depends on an implementation detail of the parser (host is nil if path is non-empty, but "" if path is empty).

Example:

URI.parse("file://").absolute? # => false
URI.new("file").absolute? # => true

This should work:

@scheme && (((host = @host) && !host.empty?) || ((path = @path) && !path.empty?))

But remove ? true : false. It doesn't do anything.

It does:

true && nil
# => nil

"https://example.com" is valid absolute URL, and path is empty.

There are too many cases to check if URL is absolute. I wouldn't like to overload the logic.

In most cases, the first variant is enought.

Let's copy what everyone else is doing:

• Ruby
• Go

Just checking whether scheme is set or not seems to be enough (like in the original PR).

@asterite In most cases it is enough because URIs with scheme typically also include an authority or path. But that doesn't make it correct.

@straight-shoota Let me quote the RFC in question:

"Relative URI references are distinguished from absolute URI in that
they do not begin with a scheme name."

Going by that checking the scheme is both correct and sufficient.

But there are some additional details, see section 5.2 of https://www.ietf.org/rfc/rfc2396.txt

Seems to be okay than. Sorry for the confusion. There are different definitions of the same terms... but following RFC 2396 is probably the best 👍

@mamantoha Would you change it back, please?

I still think this is not enough. See #6311 (comment)

Done.

eq(true) -> be_true
eq(false) -> be_false

Nobody cares

Well, it's not that nobody cares, it's just that the review adds very little value. In my mind I become the author and think "Ugh, do I really have to open the computer, sit down, change that, do a commit, push, etc., just to have some code that behaves exactly the same and is in no way superior to the old code?". That's what usually drives me from continuing working on a PR (as an author).

I know be_true is more idiomatic, but it's equivalent to eq(true) and it can be changed later, if someone really wants to do that.

Exactly what I meant in longer form, thanks for clearing that up @asterite (and I apologise for my harsh tone)