Miek Gieben <[email protected]> wrote: > [ Quoting <[email protected]> in "[DNSOP] Re: subtyping for fun and p..." ] >>> Does the language you use have a sum type that has a hard time expressing >>> unknown data? >> >> The Haskell type system is notieably richer than that of Rust, the main >> area where Rust is ahead is "linear" types, which in Haskell are new, >> still evolving, and mostly marginal at present. >> >> "Sum" types are not a good model for types that are extensible, because >> the intoduction of new constructors is an API change: previosly >> "complete" matches, become incomplete when a new variant is added.
> For RRs we fixed this by allowing unknown RRs, which have a presentation
format and a
> wireformat, so all is good. But we never did that for unknown rdata
> fields.
Viktor's point, which I think applies to Haskell and Rust, is that if the
library is updated with a new ENUM, because the new type has been added, then
applications which do not have that in their case will fail to compile.
Now, this is solveable with a match _ (in Rust. I don't know Haskell well)
in the application. However, if the application was handling type "4"
(AMTRELAY) via the bag-of-bytes for the old library [via match "sum", maybe],
then when support is added, it can also break. Is this all solveable with more
work? Yes.
What this amounts to, however, is that the application now has to make sure
it's bullet-proof for these types, rather than depending upon a well tested
library.
I remember the sub-typing debate of yore.
While I think that new RR types have gotten SIGNIFICANTLY easier to deploy
compared to 2003 (when I worked on IPSECKEY), it's still non-trivial. The
biggest hurdle is no longer the recursive resolvers, but the web-based
interfaces to authoritative servers.
Does it need to become even easier at the IETF level? Maybe not.
Could we do something more at the presentation level? Maybe.
Will we continue to have random TXT RRs and a push for extending SVCB+et-al
to do things it ought not? Yes. I would look forward to reading a
sub-type vs new-type FAQ. (Not sure we need an RFC)
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
