[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 #21 from mathieu.lacage at sophia.inria.fr  2008-04-10 14:04 -------
> I am saying that the first case seems more "helpful" without being semantically

It is certainly more "helpful" and no one contested that (although I would
identify it as only very trivially and marginaly helpful), but, you seem to be
ignoring what I repeat in pretty much every post, that is, [...]

> vague.

[...] it _is_ semantically vague and hard to describe for _some_ helpers. So,
if you cannot make it crystal-clear for all helpers, you should not do it at
all to ensure a consistent behavior across all helpers. Yes, this is akin to
throwing the baby with the bath's water, but I don't know of any other good
solution to ensure what we promissed to craig, that is, consistent behaviors
across all helpers.

> hmm, still not convinced.  We made a decision to delegate responsibility for
> correct programming to the client of the low-level API; that I agree with. 
> However, the helper API (a client of the low-level API) is supposed to simplify 
> the user code, and IMO should be permitted to do some sanity checking of user 
> input so that users don't have to do it themselves.
> 
> I guess I just don't see the danger of this instance, where I see the
> cumbersome artifacts of having to track these container members in the 
> complicated topologies.

It would be easier to convince us that this is important if you could show
scripts for which the alternative will be painful. I have a hard time seeing
how you could construct an example which cannot be trivially updated to work
with the proposed semantics.

> 
> If we agree that Install should have the same semantics "Add exactly one more,
> no matter what", then I guess I am suggesting that we should invent a different
> method name for InternetStackHelper::Install() and have its semantics be "Add
> one if none exists."

I really don't see which use-case such an extra function would cater for beyond
just lazyness. Are there scripts which cannot be written without much pain with
the proposed restrictive semantics ? Please, prove me wrong.


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