Add IP address classes to net package

[mfelsche]

and return them from NetAddress instead of their raw representation.

Rendered

Fun fact: Making the IPv6Address class Hashable was the actual motivation for #157

[SeanTAllen]

During sync, I asked @mfelsche to update this with an example of what is currently problematic about using the current interface.

[mfelsche]

I am gonna update this RFC to not break the current 'NetAddress' methods.

[mfelsche]

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).

[SeanTAllen]

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?

[SeanTAllen]

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?

[SeanTAllen]

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.

[SeanTAllen]

How likely are such object allocations? I think we need to do more than note that they will happen. Do we expect that this code end up being used in hot code path? IE, will this happen a lot? If yes, this is a huge drawback. If no, then its probably minor.

[SeanTAllen]

I think the RFC should document what changes folks will have to do to make the change. This will better help us understand the extent of the drawback.

[SeanTAllen]

I don't find non-OO to be an issue. The number 1 Pony Philosophy point is "performance", not "OO". I also don't see how the API would be "non-intuitive". Can you expand on what would be "non-intutitive" about it? Examples would favorable.

Given the option of "no allocations", I will want no allocations unless you can show me why the drawbacks outweigh the removal of said allocations.

[SeanTAllen]

How is this unresolved? The detailed design says type union not interface. Seems like this is more of an alternative than an unresolved question.