rfcs
rfcs copied to clipboard
Add IP address classes to net package
and return them from NetAddress instead of their raw representation.
Fun fact: Making the IPv6Address class Hashable was the actual motivation for #157
During sync, I asked @mfelsche to update this with an example of what is currently problematic about using the current interface.
I am gonna update this RFC to not break the current 'NetAddress' methods.
I updated this PR and deliberately decided for introducing a breaking change in NetAddress. It just didn't seem reasonable to still return the raw representation from NetAddress.ipv4_addr() and not the new classes. Instead I rooted for introducing new methods: fun ipv4_addr_raw(): U32 and fun ipv6_addr_raw(): (U23, U32, U32, U32).
I would like to see
"How we teach this" and "How we test this" expanded on. They feel very handwavey at this moment. What specifically should be tested? What specifically should be documented? Should we be updating any package level docs with documentation? Should we add something to any of the programs in examples? Perhaps add some examples?
I don't really know what I am signing up for with the detailed design. You appear to have a solid idea. I couldn't implement this based on the detailed design. Do you have a more solid idea of what you would do? Can you add more Pony code to demonstrate?
From the RFC, I don't understand the point below. Why is this an alias? You seem to be talking about something that sounds like an interface to me. Can you provide some example code of what you mean and how it would be used?
A type alias IPAddress will be created:
type IPAddress is (IPv4Address | IPv6Address)
this way it is possible to handle a generic IPAddress using the methods common to both IPv4Address. and IPv6Address. It might be a valid alternative to use an interface IPAddress instead.