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
Since Integer accepts all integers and String[1] all non empty strings the specialized Stdlib:Port will be without effect if it is a Pattern.
It does not make sense to have both Integer and Stdlib::Port since it is defined as Integer[0,65535] - should probably remove Integer from the variant unless it is possible to have a port that is > 65535.
The text was updated successfully, but these errors were encountered:
It does not make sense to have both Integer and Stdlib::Port since it is defined as Integer[0,65535] - should probably remove Integer from the variant unless it is possible to have a port that is > 65535.
Excellent example: it's impossible to have a port > 65535 because there simply aren't more bits in the TCP header. it's 16 bits and 2¹⁶ is 65536. If you start at 0 you end up with 65535 as the upper bound.
Similarly, we shouldn't accept strings for ports, unless the software allows specifying a range (like 10-20). Even then a Pattern would be better.
Removing Strings support for the $port parameter would be a breaking change. I am fine with that. Currently there are tests which cover this behaviour too.
Use Case
It seems like some datatypes could be more accurate
Describe the Solution You Would Like
correct datatypes if reasonable
Additional Context
example:
Variant[String[1], Stdlib::Port, Integer] $port = $postgresql::server::port,
Since Integer accepts all integers and String[1] all non empty strings the specialized Stdlib:Port will be without effect if it is a Pattern.
It does not make sense to have both Integer and Stdlib::Port since it is defined as Integer[0,65535] - should probably remove Integer from the variant unless it is possible to have a port that is > 65535.
The text was updated successfully, but these errors were encountered: