Bug 218 - wifi PHY base class must be virtualized and subclass renamed
wifi PHY base class must be virtualized and subclass renamed
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: devices
pre-release
All All
: P1 normal
Assigned To: Mathieu Lacage
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-11 14:01 EDT by Mathieu Lacage
Modified: 2008-11-26 04:26 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Lacage 2008-06-11 14:01:26 EDT
The plan has always been to support multiple PHY models in the wifi device. Right now, however, we have only one WifiPhy class which is not split in a base/derived class pair. Since we plan to eventually do this, when we do it, we will have to keep the name WifiPhy for the current subclass which corresponds to the current implementation to avoid breaking user's scripts which use the WifiHelper. That is clearly sub-optimal because:
1) WifiPhy should be the name of the abstract base class
2) the current model should have a name closer to YansWifiPhy

Based on the above, I would like to propose to:
1) split the WifiPhy class in a base class + derived class
2) name the base class WifiPhy and the derived class YansWifiPhy.

The public API of the WifiPhy base class is likely to change later as we add more subclasses but this change should make it unecessary to break the API used by scripts which do not re-implement the WifiPhy base class (which, I think, is a pretty rare occurence so, I am not worried about it). 

So, with this change in place, we should be ready to add more subclasses without breaking too many scripts.
Comment 1 Craig Dowell 2008-06-11 14:21:33 EDT
There is a reasonable argument to add this change to the 3.1 release in order to minimize API problems in the future.  Although we could deal with this through name changes, it seems to me that WifiPhy is the appropriate name for the beast.

This is a loclized change, with well-understood implications and, IMO, minimal risk -- only slightly more involved than a name change.  I tend to support including this change in 3.1 because it is small in complexity and scope.

Any disagreements?
Comment 2 Mathieu Lacage 2008-06-11 14:53:29 EDT
see: http://code.nsnam.org/mathieu/ns-3-wifi/rev/a15618dcd0eb

That change was done on top of the work I am doing to do more testing and regression for wifi PHY models. I can split this patch from this tree if needed later.
Comment 3 Craig Dowell 2008-06-11 18:40:01 EDT
Decision made to wait until post-3.1 for this one.
Comment 4 Mathieu Lacage 2008-11-26 04:26:10 EST
fixed now that the ns-3-wifi tree has been merged back into mainline.