You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
localhost, port=parsed.host, parsed.port-- if no port was found, try to deduce it from the schemeif ( not(port) ) thenport= (parsed.scheme=='https') and443port=portor ((parsed.scheme=='http') and80)
endreturnhost, portend
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: