I don't know if it would be possible to change that while maintaining backwards-compatibility, though.

We can!

    /**
     * @param  int|string|array  $key Name of context item, or key-value array of context items
     * @param  mixed  $value Value of the context item. Alternatively, pass a key-value array in $key to set multiple items at once.
     * @return self
     */
    public function context($key, $value = null): self
    {
        if (func_num_args() == 1 && is_array($key)) {
            // An array of context values was passed instead
            foreach ($key as $contextItem => $contextValue) {
                $this->context->set($contextItem, $contextValue);
            }
        } else {
            $this->context->set($key, $value);
        }
        
        return $this;
    }

Now I'm thinking it may be better to add this to the PHP library directly. 🤔

@shalvah I like it :)

I don't know if it would be possible to change that while maintaining backwards-compatibility, though.

I was thinking about that also, and opted to do it as a separate method so i didn't have to edit the already existing method.
I guess this could be seen as a breaking change if anyone is extending the Honeybadger class, they are probably not expecting an array as input. Up to you if that is a valid concern or something we can safely ignore.

I can update the PR to refactor the current method instead of creating a new method if you wish?

I don't know if it would be possible to change that while maintaining backwards-compatibility, though.

I was thinking about that also, and opted to do it as a separate method so i didn't have to edit the already existing method.
I guess this could be seen as a breaking change if anyone is extending the Honeybadger class, they are probably not expecting an array as input. Up to you if that is a valid concern or something we can safely ignore.

I can update the PR to refactor the current method instead of creating a new method if you wish?

We might be changing the type signature, but I don't think it's a breaking change: if they aren't expecting an array, then they aren't passing an array, and nothing will happen.

Before this, it was impossible to pass an array as the first argument anyway. This adds functionality, not removed it.

I have updated the PR, sorry for the multiple commits, didn't have access to 7.3 locally at the moment.

Had to put the interface as return typehint for it to work in 7.3, imo this is better than to omit the return typehint completely.

I just realised that we cannot add a typehint at all, if we would add the return typehint we will for sure break the backwards-compatibility. Any class extending Honeybadger would be incompatible with the new signature.

By omitting the typehint any extending classes will still work even if they have void return type, they will not pass along the return value ofcourse, but their implementations will not expect a return value anyway.

I kept the proper return typehint in the docblock.

Thank you 👍