[Ns-developers] Learning Bridge has been merged

[Gustavo Carneiro]

2008/7/21 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>:

>
> On Mon, 2008-07-21 at 16:32 +0100, Gustavo Carneiro wrote:
>
>
> > I was told that Craig was taking care of review in this area.  I am
> > sorry but I can't follow different reviewers with different opinions.
> > If I did that I would never get anything done.
>
> Ah. I missed that email: sorry to you and craig. I don't really
> understand what kind of netdevice would have no meaningful concept of
> promiscuous mode: it seems to me much simpler to avoid adding
> conditional features to netdevices when we can.
>
> >         2) I would really appreciate that you make all new methods in
> >         NetDevice
> >         pure virtual rather than just virtual. We have been
> >         consistently moving
> >         towards this in the NetDevice class over the past couple of
> >         changes made
> >         to it so, I would like to try to stick to this. For Wifi, you
> >         can just
> >         stub the methods and I will implement them myself.
> >
> > Can you tell me _one_ reason why this would be a good idea?  Because I
> > can give at least two reasons why this way is better:
> >
> > 1. Clearly not all NetDevices have to support promiscuous mode, and
> > for this that do not support it, it is pointless to implement those
> > methods;
>
> Again, I have spent some time thinking about this and I have not been
> able to come up with a single case where a "promiscuous" callback would
> be meaningless or actively harmful, hence my suggestion.
>
> > 2. Pure virtual breaks the NetDevice API, and for no apparent reason.
> > This when I usually say something about gratuitous API breaks...   You
> > should be happy that the Node protocol handlers API has already been
> > broken, for the sake of API cleanliness; isn't it enough?
>
> I would say no but if that is really the rationale for making them
> non-pure, it would be nice to document this such that we know that this
> is the preferred way to go forward. Otherwise, it would be nice to stick
> to the API design policy which has been going on for a couple of months
> now, that is, to use pure methods instead of non-pure methods.


I know one reason why pure virtual methods may have some benefit, and I am
surprised you didn't mention it even when I asked.  *sigh* I guess I have to
play devil's advocate here, it seems :P

The issue is when a virtual method changes signature.  For instance:

      void SupportsPromiscuous ();

to:

      void SupportsPromiscuous () const;

At that point, any subclasses not adapting to the new virtual method
signature will suddenly adopt the default virtual method implementation,
from the base class.

So you see, I _do_ understand the issues.  But I think the benefits of some
degree of API stability vastly outweigh the disadvantages such as this one.
At least, that is my opinion.

Unless, of course, lack of API stability is a deliberate design goal, to
encourage outside contributors to submit their works for merging into the
main NS-3, like the Linux kernel does with respect to closed source
drivers.  If that is the case, I just think the project should just have a
clear statement about the issue, so that contributors know what to expect
and conveniently prepare for it (e.g. by submitting more code to ns-3).

Thanks,

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