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

[Gustavo Carneiro]

2008/7/21 <craigdo at 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?


I am OK with your proposal, assuming deprecated APIs are not removed for
about one year.  I think achieving one year of relative stability (where it
doesn't compromise API cleanliness) is a good compromise between API
stability and maintainability.  Maintainers, do not despair, one year passes
very quickly...

Now I am going to preempt Mathieu's likely reply and say that the big
problem, in this case, is that I do not know how to make GCC emit a
deprecation warning for a subclass of NetDevice that doesn't override the
virtual methods that will become pure in the future.  So this is the only
problem I can see to that approach.  Unfortunate problem, I must add... :-(

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert