Less obtrusive hugs

[michellesanver]

It feels somehow better to go $this->hug($object) over $object->hug($this), could be because I see $this as the object wanting to hug, even though both are of course possible it seems nicer in the example and less obtrusive "give me a hug" vs "I give you a hug" <3

[Crell]

Hm, interesting, point! But then it's an interface on self, not on a 3rd party object. Does that still fulfill an interface? What would $this->hug() do other than call $object->hug($this)?

[michellesanver]

The question that comes to my mind is... Is every hugger huggable? If not my solution would not work.

[jacobsantos]

Just because a hugger is huggable doesn't really mean the huggable wants the hugger to hug. It would be better if there was another interface for permissible hugging. That way you can test for the interface method and either allow or deny the hug.

Not sure about the direction of hugging. Part of me thinks that hugging should be initiated by an external event. Meaning the $object->hug($this) would be preferred over $this->hug($object) as it would be up to the existing object to determine whether it requires a hug. Without some external force, no object may require a hug and therefore no hugs would be given. A sad course indeed as every huggable object should at the very least be hugged every once in a while.

I do think that it is still possible that you can have $object->hug($this) or even $parent->hug($child) where parent and child are two independent entities that meet up after being separated for some time.

[Crell]

An object certainly should be able to declare if it wishes to be hugged or not. Hugging an object that does not want one is an API violation. However, the expectation is that an object indicates it wishes to be hugged by implementing Huggable. That is, an object implementing Huggable is saying that it is OK with being hugged.

Which brings us to @michellesanver's question, which is more about the assumption in the spec now that hugs are always reciprocal. The spec currently states:

An object whose hug() method is invoked MUST hug() the calling object back at least once.

That is, all hugs MUST be reciprocal. If that's the case, then it doesn't matter which side initiates the hug as both will still be hugged at least once.

Is that a safe assumption to make? Cases where it may not be:

1. An object wishes to hug another, but does not want the hug reciprocated. This seems odd to me from my experience as a hugger, but I could see cases where the receiving object is in no condition to return the hug; it may be restrained, or in an emotional state such that receiving a hug would be appreciated but it is unable to return the favor.
2. The objects involved in the hug are not the initiators. Perhaps they are shy, and another broker module is responsible for introducing them. We could call this broker object a "Fix-up" object, in which case it would not pass $this to the hug() method but instead call $hugee1->hug($huggee2); and let them continue on their own from there.

The second case implies that we should allow objects other than $this to be passed; any Huggable would suffice. The first case doesn't affect what is passed, but does imply that the MUST should be softened to a MAY; that is, hugging another object implies that you're OK with being hugged back, but the receiver is under no obligation to do so.

Make sense?

[KorvinSzanto]

I think that instead of a permission flow or required reciprocation, we should simply add a success/deny flag return to Huggable::hug making the signature public hug(Huggable $huggable) : bool This gives the hugger and the huggable both an opportunity to veto the hug. The only question is what happens in GroupHuggable::groupHug...

[Crell]

Hm, curious. How would that veto process work?

[KorvinSzanto]

If I am a god trying to make two huggables hug eachother, the only way to do so would be to call hug on BOTH objects:

function hug(\PSR\Huggable $hugger, \PSR\Huggable $receiver) {
    // Perform a two way hug
    if (!($hugger->hug($receiver) && $receiver->hug($hugger))) {
        throw new \RuntimeException('Someone didn\'t want to hug :(');
    }
}

On the other hand, if a huggable itself is attempting to hug another huggable, this veto process is a little more obvious:

public function doWorkWithObject(FooType $object)
{
    $this->doTheWork($object);

    if ($object instanceof \PSR\Huggable) {
        // Let's thank this object with a good ol hug 
        if ($object->hug($this)) {
            // The hug was approved, lets complete this hug by hugging back
            $this->hug($object);
        } else {
            // The hug was vetod, what a jerk
            $this->log->debug('Hug denied!', array($this, $object));
        }
    }
}

[michaelcullum]

Do you need to be huggable to hug an object? I think so as whilst one object initiates the hug, it then becomes a mutual action where both objects are... being hugged by the other.

[KorvinSzanto]

@michaelcullum The signature for Hug currently requires you pass in the object that is receiving the hug:

public function hug(Huggable $receiver);

So you don't need to be huggable to initiate a hug, but you DO need to be huggable to participate in one.

[jacobsantos]

Obviously, the solution is to have a system more of an observer or event pattern than a strict object with interface implementation.

With the observer pattern you can register that you are capable of receiving a hug and provided the PSR\Hugger wishes to hug someone, can do so with those that have registered as PSR\Huggable. The object can also revoke their PSR\Huggable status at any time. Further extending, an object that has the PSR\Huggable capability would only register as accepting hugs from known persons.

You could further extend the system with a later specification providing a PSR\GroupHuggable interface or class system that provides for arbitrary hugging random objects. In case you had friendly objects that didn't care about whom they were hugging or being hugged by, just that they were comforted by someone with a hug.

---

For me, the biggest problem is that you only have the Hug action defined. What about cuddling? What about spooning? What about the old High Five, down low, too slow action? Sure you could make these all traits, but as objects have no physical presence, none of these actions have any meaning and therefore are merely semantics.

What if an object registers for a cuddling and receives a hug instead? That sort of rejection could destroy objects in another language.

[KorvinSzanto]

@jacobsantos I'd like to see an example of a working interface for that, keep in mind that the FIG only voted to allow in a "Huggable" PSR and not to allow a "Cuddleable" PSR.

[jacobsantos]

@KorvinSzanto I think it is sad that the action wasn't left more open, but as the PSR is only a joke and in no way would this ever be accepted, I was attempting to further the joke. As with most of my jokes the punchline failed to deliver. I probably shouldn't quit my day job... as a programmer.

I think this joke is further extended by people taking it a bit too seriously as programmers and pedantics are want to do.

---

Technically, I think Cuddleable and Spooningable could be implemented with proximity and duration properties or methods. Saying that the Huggable has additional methods to set or accept the proximity and duration and have an event that allows for the receiver to back out when they are feeling uncomfortable with the either.

I'm saying that the entire system could use some events as part of the standard. It isn't something that FIG does or adds, but it would solve a lot of problems.

[KorvinSzanto]

You ruin the joke by explaining it ;) Pro-tip: We're all in on it

[michaelcullum]

Hugs are no joke. Can we please get back to serious discussion on this
please?

Michael C

On 28 December 2015 at 23:43, Korvin Szanto notifications@github.com
wrote:

You ruin the joke by explaining it ;) Pro-tip: We're all in on it

—
Reply to this email directly or view it on GitHub
#486 (comment)
.

[Crell]

I can certainly see the value of having a Cuddleable or Spoonable interface in general, but I feel it's inappropriate for a public standards group. Hugging is a standard feature of many projects and can be and has been implemented at many conferences. Spooning, while it probably has been implemented by some members of our community, seems more appropriate as a private API.

@KorvinSzanto Your suggestion is quite interesting. It subtly changes the purpose of hug() from "I hug you, you can hug back if you want" to "Please hug me? Oh, hug you back!" That does seem safer, especially in this era of Code of Conduct rules engines. (Which somewhat gets back to @michellesanver's original point.)

Technically, though, either approach is still spec legal. And there are likely cases where two objects have previously negotiated that a pre-emptive hug is allowed. (Ie, most people that know @michellesanver for instance.) So I suppose then there's two possible ways to interpret a boolean false return from hug(): "You're welcome to hug me again" and "that hug was welcome". Hm.

While there are cases where another object may want to encourage two objects to hug it out, I definitely feel we should support ad hoc hugging of any interested Huggable objects at any time.