Jonathan Chan Kwan Yin

Can't think of any practical usage anymore except stupid priority overriding.

> I'm referring to people using public plugins that use this event. Backwards compatibility is important. People currently using PlayerCommandPreprocessEvent are mostly misusing it. That's exactly why we are removing...

Using your logic, the `Array.reduce(initialValue, reduceFn)` function should be changed into `Array.reduce(Reducer)`, e.g. they should have `[1, 2, 3].reduce(new MultiplyReducer())` rather than `[1, 2, 3].reduce(1, (a,b)=>a*b)`. This apparently doesn't make...

The usability of this method would actually be enhanced if we convert the callback parameter to some sort of Promise instead.

Perhaps we keep the form interface and have it process the data then? ```php /** * @phpstan-template R processed client data */ interface Form { public function getData(); /** *...

Is it true that this issue does not cater for client response validation? In that case, it might be meaningful to keep the interface after all.

This seems to be an issue with the all-in-one image in general, not specific to jaeger-operator.

I don't think macro resolution is currently possible in stable Rust. The second option of shell expansion is possible, but it breaks backwards compatibility. Perhaps we can consider a separate...

Any updates to this? It doesn't seem reasonable to put this on hold just because of a special case. What about adding a feature gate or an attribute to enable...

All the details are https://docs.rs/include-flate/0.1.3/include_flate/macro.flate.html here. Is it really necessary to copy them to readme?