[Ns-developers] How to Deal With Interface Revisions (RE: Learning Bridge has been merged)

[craigdo@ee.washington.edu]

> I think that the above pretty well summarizes our 
> disagreement

I'm going wax philosophical a bit [I know, I know, screams are heard in
background] and take a different tack on this discussion ...

We're engineers.  There are an almost unlimited number of ways we can solve
almost any problem with which we are faced.  We all come to the table with
different backgrounds that may guide us in different directions in our
individual design processes; and we will have different priorities.  Both of
you now are making completely reasonable points based on your clear
philosophical differences and points of view.

In a project where multiple organizations and people are involved, at some
point you have got to try to get past detailed mucking around in other
people's code and just look to whether or not a module meets its
requirements (whenever possible).  On the other hand we're new talking about
changes to NetDevice, which is really at an architectural level.  So there
is, of course, room for discussion about ns-3 architecture, existing models,
precedent and direction.

Although there is a comment at the top of net-device.h that implies
something else
(If you want to write a new MAC layer, you need to subclass this base class
and implement your own version of the NetDevice::SendTo method), class
NetDevice is clearly intended to be an ADT based on the fact that all of the
methods are pure virtual.  We really have been leaning toward an ADT
approach even if it hasn't been explicitly said.

I understand Gustavo's reasoning, but the result in net-device.h is that we
have twenty-something pure virtual methods, and we just tacked on something
that works entirely differently.  It's different.  I don't like gratuitously
different for reasons I have repeated ad nauseam, but Gustavo did it this
way for a valid reason -- to avoid breaking everyone's models.

So I think there's actually a much bigger issue hovering under this
exchange:  How do we deal with API change impact in general?  We have
recently adopted Gustavo's suggestion for trying to go with "deprecated"
attributes if we want to delete or change API.  We have not addressed at all
how we want to go about adding API.

Now, if it is a good idea to avoid deleting API out from under users by
leaving old code but marking it as deprecated; wouldn't it be an equally
good idea to avoid *adding* API "out from under users" as well?  I think
this makes sense.  The problem we want to avoid is having users' models
unexpectedly break when they aren't ready for it.  However, we also want to
keep some kind of interface coherence and sanity.  I think we should form
some kind of policy to let our users know what to expect of us.

It seems to me that an equivalent way to approach adding API would be to do
it the way Gustavo did, but mark the *new* virtual functions deprecated and
remove them in a future release in favor of pure virtual methods the way
Mathieu wants.

I think both Mathieu and Gustavo are right looking at it from different
perspectives, so this makes a lot of sense to me.  Thoughts?

-- Craig