I want my Wire objects to be in connection with Port objects. That is Port has a list of connected wires and method Port.add(wire). Similarly, Wire has list of ports it is connected to and Wire.add(port).

class Port
  Set[Wire] connections
  method add(wire)joined)

class Wire
  Set[Port] ports
  method add(port)

Suppose now I use one of those methods, add a port to a wire. That method should call port.add(this wire) in response, to maintain coherence. But, calling port.add(wire) should do the same thing, it should call wire.add(this port) to maintain coherence. It is going to be a vicious circle. How do you break it? Do you

  1. check that the object already connected and do nothing in this case or
  2. make a primary connection method, forcing all users to use, say wire.add(port), which will call dumb port.wires.add(wire) and without any further calls
  3. or anything else?
  • How can a port be connected to multiple wires ? – Spotted Oct 20 '16 at 9:49
  • @Spotted Probably. But, what if not? – Little Alien Oct 20 '16 at 14:17

When you add a port to a wire, the wire "reacts" by calling the port. This is a different call from an external port.add(), from a logical point of view.

You could have a protected method inherited from a superclass, called something like notifyAdd:

someone calls wire.add(port)
the wire initializes its own internals
the wire calls port.notifyAdd(wire)
the port initializes its own internals, but *does not* call wire.notifyAdd(port)

The two functions add() and notifyAdd() would be almost identical, and actually it's likely that add() would do something like calling notifyAdd() on itself and on the called object:

    ! A wire was added to this port.
    wireCount := wireCount + 1
    ! other things
    return self

! Called externally
add(wire): public
    ! We do not trust this to make sense.
    ! We might throw WireAlreadyConnectedRecoverableException,
    ! or InvalidWireCriticalException, or ...
    sanityAssertions(self, wire)

    ! Now yes, if we're here, it made sense and we act upon it
    return self
  • Is there a relationship with syncronosus vs async call and messages that need and do not need a callback? For instance, in Learn Some Erlang : FSMs, we read that negotiate({make_offer, Item} needs to repeat the added item to the counterpart machine, whereas coutnerpart message negotiate({do_offer, Item}, which comes from there to us, does not send any additional messages. – Little Alien Jan 15 '17 at 18:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.