Use URI.parser method, and remove 1.8.x code

[kennyj]

No description provided.

[josevalim]

It is safe to assume that URL::Parser.new will never rely on internal state? Storing it in a class instance variable makes me feel a bit uneasy. /cc @tenderlove

[kennyj]

@josevalim I'm seeing 1.9.3p0 code now. According to uri/common.rb,
URI.parse calls DEFAULT_PARSER.parse only, and Parser.new is assigned to DEFAULT_PARSER.

And it seems that URI::Parser#parse will never change internal state.

...

But, I think that there were URI.parser (AS's core_ext) method for 1.8.x and 1.9.x compatibility now.
Thus, should we deprecate URI.parser method and use URI.parse ?
(or, on the contrary, could you merge this PR ?)

# URI.parser.parse(uri_string)
URI.parse(uri_string)

[josevalim]

If the API in 1.9 is URI.parse, I would go with it and get rid of as/core_ext/uri

[kennyj]

According to https://github.com/rubyspec/rubyspec/tree/master/library/uri,
It seems URI.parse is the API in 1.9.

[tenderlove]

I am confused by this patch. Shouldn't we just be calling URI.parse?

[josevalim]

It seems URI.parse was not there before 1.9. If it is the official 1.9 API,
I believe we should just go with URI.parse.

[tenderlove]

We could also simply use URI(). Anyway, URI.parse has been there since at least 1.8.7.

>> RUBY_VERSION
=> "1.8.7"
>> require 'uri'
=> true
>> URI.parse 'http://google.com/'
=> #<URI::HTTP:0x10a7d5db0 URL:http://google.com/>
>>

[tenderlove]

Shouldn't this stay as URI.parse?

[josevalim]

Ok, closing this then. @kennyj could you please send a pull request that removes the core_ext and change Rails to rely only on URI.parse?

[kennyj]

Ok! I'll send PR.