/cc@dunglas

Bug label was a mistake.

Travis CI build errored due to network issues...

Search for "varying support" on some English corpus (actually the plural is corpora):

https://corpus.byu.edu/coca/
https://corpus.byu.edu/glowbe/

They don't support direct links.

I like this one (VaryingSupportInterface) 👍

Current proposed method name:
isVaryingSupportByData

Interpretation:
Is this normalizer and/or denormalizervarying itssupport by the data provided?

Alternative proposed method name:
isSupportVariedByData

Interpretation:
Is this normalizer and/or denormalizer'ssupportvaried by the data provided?

Yes, "varied by" fares very well in the above mentioned corpus (corpora). But I'm concerned that it might be misinterpreted as:
Does this normalizer and/or denormalizersupport (some kind of?) varied (thing?) by data???

Which might cause some confusion...

Okay, it seems like "varied on" is the right phrase.

Source: the above mentioned corpus / corpora.

/ping@dunglas@nicolas-grekas@ogizanagi

None of us are native-english speakers, so I think we should ask someone who is.
At least "varied by" sounds really weird to me, "varied on" probably is better (so 👍 ).

EDIT: actually,isSupportVaryingOn* looks more correct to me.

I actually prefer the old name :).

But, if we're going to change it, from an English perspective:

A)VaryingSupportsInterface with an "s". I saw the reason for removing the "s" earlier. But, we're talking about whether or not thesupports() method can be cached/varies. I think NOT having the "s" complicates things

B)doesSupportsVary() ordoesSupportsVaryOnDataOrContext (but the second is long). I know that we like usingis as a prefix, but it just doesn't sound right here.

Sorry to muck things up further :)

👍doesSupportsVary for me. Thanks@weaverryan

Keeping the old name for me (doesSupportsVary is my second choice)

Naming is really hard :) I'm not a big fan of the current name (and don't have any great idea for better names), but I think that the current naming is still better than the alternatives.

@weaverryan

But, we're talking about whether or not the supports() method can be cached/varies.

I should explain the rationale in depth. What I'm doing here is to use "support" as a noun, i.e. the concept of whether the normalizer supports normalizing / denormalizing a certain something. The previous interface name was bad for 2 major reasons:

1. It clearly says "cacheable" when in fact, that might or might not be the case.
2. It directly refers to the "supports method" which makes it a confusing abstraction.

By changing it to an interface which says how this support may vary, we borrow the same concept from the HTTP Vary header.

HTTP vary is a list ofwhat it varies-by. Here it's a boolean. Thewhat is thus abstract.
I think we should close now: I'm pretty sure we're growing frustration on your side because you might feel we don't get your point. I do, I promise, and I'm confident enough others get your point also, and still expressed a preference for the status quo, which is a good enough sign to move forward and not spend more time here IMHO.

I'll do one last attempt.

• variesSupportOnDataAndContext
• canVarySupportByDataAndContext (I think this is the least confusing)
• doesSupportVaryByDataAndContext

I've thought of a different way that involves more than a naming change. I need to try and see if it'll actually work, but if it does I'm confident that it'll be accepted. Stay tuned!

Never mind. I tried to implement my idea, but it doesn't work:

<?php/* * This file is part of the Symfony package. * * (c) Fabien Potencier <fabien@symfony.com> * * For the full copyright and license information, please view the LICENSE * file that was distributed with this source code. */namespaceSymfony\Component\Serializer\Normalizer;/** * Defines the interface for checking normalization / denormalization support, * where the result of the check may be safely cached. * * @author Kévin Dunglas <dunglas@gmail.com> */interface CacheableSupportInterface{/**     * Checks whether the specified type and format is supported for     * normalization and denormalization.     *     * If the return value is null, it means that support could not be     * determined based on these criteria alone. Support will have to be     * checked using the {@see NormalizableInterface::supportsNormalization} /     * {@see DenormalizableInterface::supportsDenormalization} methods.     */publicfunctionsupports(string$type, ?string$format =null): ?bool;}