[Ns-bugs] [Bug 162] Calling Object::AggregateObject twice with the same Object type silently succeeds

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=162





------- Comment #12 from mathieu.lacage at sophia.inria.fr  2008-04-10 10:56 -------
(In reply to comment #11)
> > 
> > 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.
> 
> We already have inconsistent API semantics here, even with your suggestion:
> 
> CsmaHelper::Install ();  // can be called repeatedly on the same container
> InternetStackHelper::Install ();  // can not be called repeatedly on the same
> container

I already wrote two times that if this is the case, then it should be fixed so,
this is really a non-argument: I certainly never claimed that I had done a
serious review of the helper API myself.


> > 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 think that this frames the question the wrong way.  The question is not how
> users learn how the system works, but how do we want the system to work in the
> first place?  Remember, we are talking about helper API here.

Yes, I agree but, I already explained why the semantics you describe are not
desirable in the first place: there are _some_ helpers for which the behavior
you describe will be very complex to document. More specifically, there is
_one_ helper for which this is problematic: MobilityHelper::Layout uses the
state from the reference point stack and it is very unclear how to document
what happens when the reference point stack is non-empty and when Layout gets a
called twice on an object which has already a mobility model attached to it. I
have the gut feeling that doing what you suggest in this case would be a
programming error so, I would not want this to be silently ignored.

Maybe the problem here is that MobilityHelper is trying to do too much (it
certainly contains much more logic than I would want) so, maybe the solution
would be to try to simplify it. If that could be done without loss of
functionality, then I would ok with implementing what you suggest. 

> 
> If you really want consistent API, then you should not use Install() for
> InternetStackHelper, because it does not have the same semantics as any of the
> device Install()s.  Then, you can pick another name for
> InternetStackHelper::Install() (or DeviceHelper::Install()).  Once you have
> another name, you can define whatever semantics are most helpful for its usage.

Craig insisted a lot for the consistent name so, I would be very wary to go
back to that decision and undo it. If we are serious about this consistency,
then we also probably should review the existing code to see if we can reuse
Install in OlsrHelper and MobilityHelper.


-- 
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.