[Ns-bugs] [Bug 162] Calling Object::AggregateObject twice with the same Object type silently succeeds
bugzilla-daemon@nsnam-www.ece.gatech.edu
bugzilla-daemon at nsnam-www.ece.gatech.edu
Thu Apr 10 07:20:55 PDT 2008
http://www.nsnam.org/bugzilla/show_bug.cgi?id=162
------- Comment #10 from mathieu.lacage at sophia.inria.fr 2008-04-10 10:20 -------
(In reply to comment #9)
> (In reply to comment #6)
> > It is vastly easier to document and
> > convey to users that each operation is allowed only once.
>
> I do not understand this point of view, in this specific case. First of all,
> Install() method is allowed to be invoked multiple times, if you consider other
> helpers.
Well, as I said in my first comment, if this is the case, then, it should be
fixed.
>
> Second, this is a helper API. It would help the user to not have to create or
> maintain this special container that is only used to call
> InternetStackHelper::Install (). Whether or not your suggestion to assert on
> finding a node with an internet stack already is adopted, users still need to
> understand that this Install () is different than the other (e.g., device)
> Install()s, semantically. Why not make the semantics the most useful to the
> user?
Because that would make these semantics hard to document in a consistent way
across multiple helpers. It is important to make the helper API easy to use
_but_ that does not mean make it highly optimized to a specific use-case. It
just means that it should not be too painful to use it and that a wide range of
use-cases are covered and that the overall structure is consistent.
What you suggest is not adding functionality because you can already use the
API to do what you want if you re-arange your code but it is adding extra
complex logic in the Helper API. Ideally, that code would contain zero complex
logic and be a trivial pass-thru because you want to make it easy to replace it
with adhoc code when it does not do what you need.
This is really another instance of the Socket debate we had recently: you
(users) just have to learn how the system is expected to work to use it
efficiently and painlessly. It is not ok to add random extra hacks everywhere
to attempt to save the user from having to learn how the system works because
that is exactly the kind of process which lead to the current ns2 tcl code and
you don't want to end up there.
>
> I still favor
> /**
> * \param c the set of nodes
> *
> * For each node in the input container, aggregate implementations
> - * of the ns3::Ipv4, ns3::Udp, and, ns3::Tcp classes.
> + * of the ns3::Ipv4, ns3::Udp, and, ns3::Tcp classes if they are
> + * not already present in the node.
> */
> void Install (NodeContainer c);
understood. Just don't do it :)
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the Ns-bugs
mailing list