Function url.parse() separates a given URL into individual components, such as the scheme, host, port, and path.
As of now the port part is being returned as string. I would like to propose that port return type is changed to number, technically an integer.
This will make the function more consistent with other libraries, which frequently expect a port parameter in the form of the full-fledged table or a number, but not a string.
The switch will also reduce obscure ambiguities that already exist in the code base. As an example, several scripts contain a code like this:
localfunctiongetHostPort(parsed)
local host, port = parsed.host, parsed.port-- if no port was found, try to deduce it from the schemeif ( not(port) ) then
port = (parsed.scheme=='https') and443
port = port or ((parsed.scheme=='http') and80)
endreturn host, port
end
Such a function will sometimes return the port as a number and other times as a string.
A corresponding patch already exists here. It covers both the change itself and a corresponding clean-up of the consuming code.
The change looks pretty non-controversial but I am cognizant of the fact that it changes behavior of a standard library.
Please let me know if you have any questions or concerns. Otherwise I will commit the change in a few weeks.
The text was updated successfully, but these errors were encountered:
Function url.parse() separates a given URL into individual components, such as the scheme, host, port, and path.
As of now the port part is being returned as
string
. I would like to propose that port return type is changed tonumber
, technically an integer.This will make the function more consistent with other libraries, which frequently expect a port parameter in the form of the full-fledged table or a number, but not a string.
The switch will also reduce obscure ambiguities that already exist in the code base. As an example, several scripts contain a code like this:
Such a function will sometimes return the port as a number and other times as a string.
A corresponding patch already exists here. It covers both the change itself and a corresponding clean-up of the consuming code.
The change looks pretty non-controversial but I am cognizant of the fact that it changes behavior of a standard library.
Please let me know if you have any questions or concerns. Otherwise I will commit the change in a few weeks.
The text was updated successfully, but these errors were encountered: