[net-dns-users] List of API changes in versions after 0.68?

[Dick Franks]

On 19 December 2012 07:40, Calle Dybedahl <calle at init.se> wrote:

> Is there a list somewhere of all the API changes in post-0.68 versions of Net::DNS? I've noticed two of them (what Net::DNS::RR::SOA->rname returns changed,

rname is supposed to be a mailbox address, and RFC1035 defines the
transformation to/from a domain name.
I took the view that the interface to the user should be RFC822 syntax
on the basis that Net::DNS should encompass everything that RFC1035
requires, and not leave arbitrary bits of it for the user to sort out
himself.

> and Net::DNS::RR->new($string) throws an exception instead of returning undef on failure), since they made our unit tests fail.

Failure to create an RR at all (as distinct from one with no valid
RDATA) is usually an irrecoverable error.
The exception based model relieves the user of testing the returned
object reference after every new() call, and provides the information
needed to discover what went wrong.  The old model left the user with
no information at all.


 I see here on the list that John Kristoff happened onto another
(header count values aren't settable any longer). Which raises the
suspicion that there are more of them.

The present code base was tested against the same set of test script
as 0.68 and passed with only minor discrepancies which mostly arose
from problems with the tests themselves.
This was done on the assumption that the key elements of the API would
be tested, and therefore if it passed, the API would be the same or
acceptably close to the original.
Perhaps that was too optimistic a view.


> Is there a list somewhere of all API changes? There is a Changes file, but as far as I can see none of the three changes above are mentioned in it. The diff between releases 0.68 and 0.71 is almost 35000 lines, so reading that is not really viable.

The bulk of that lies in the RR subtype implementations and either do
the same as they did before, or what the relevant RFCs say that they
should have done before. The handling of mailbox attributes is the
only significant departure.


> Note that I'm not arguing against any of the changes, I just want to know what they are, so I can adjust our code if necessary.

Willem has already posted an explanation of the reasoning behind some
of the changes.


One area of the API which "looks the same" but behaves differently, is
the use of new() with named arguments.
The attribute names are treated as object method names and called with
the specified argument.
The user no longer has direct access to the hash which gets blessed as
an RR object.
Also, in many cases the internal data structure is radically
different, which will break code which accesses the internal data.
But you never do that, do you?


Dick
--