-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Serializer] Rename CacheableSupportsMethodInterface to VaryingSupportInterface #27210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Serializer] Rename CacheableSupportsMethodInterface to VaryingSupportInterface #27210
Conversation
/cc @dunglas
|
Travis CI build errored due to network issues... |
@@ -150,9 +150,9 @@ public function setIgnoredAttributes(array $ignoredAttributes) | |||
/** | |||
* {@inheritdoc} | |||
*/ | |||
public function hasCacheableSupportsMethod(): bool | |||
public function isSupportsVaryByData(): bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not english-native, but I feel like this should be either "doesSupportsVaryByDataInterface" or "isSupportsVaryingByDataInterface". The context should also be taken into account, so that this could be "doesSupportsVaryByDataOrContextInterface".
All in all, I'm not sure the new name is better. But I'll let others decide since I'm biased, by being the author of the original proposal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
supportsMethodVaries
, hasVaryingSupportsMethod
? But I'm not really convinced either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll improve it. 😄
72de9df
to
2fb8ce9
Compare
Search for "varying support" on some English corpus (actually the plural is corpora): https://corpus.byu.edu/coca/ They don't support direct links. |
2fb8ce9
to
da5038b
Compare
@@ -12,15 +12,16 @@ | |||
namespace Symfony\Component\Serializer\Normalizer; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed any mention about caching, because that is an implementation detail of what the serializer does with classes implementing this interface. I think it's better to have a pure abstraction here.
If necessary, we could document it in the Serializer
class. WDYT @nicolas-grekas @dunglas?
I like this one ( |
Current proposed method name: Interpretation: Alternative proposed method name: Interpretation: Yes, "varied by" fares very well in the above mentioned corpus (corpora). But I'm concerned that it might be misinterpreted as: Which might cause some confusion... |
@@ -150,9 +150,9 @@ public function setIgnoredAttributes(array $ignoredAttributes) | |||
/** | |||
* {@inheritdoc} | |||
*/ | |||
public function hasCacheableSupportsMethod(): bool | |||
public function isVaryingSupportByData(): bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I propose: isVaryingSupport
(it can also vary depending of the context).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer that we make it explicit in the method name.
Okay, it seems like "varied on" is the right phrase. Source: the above mentioned corpus / corpora. |
da5038b
to
5a1f084
Compare
None of us are native-english speakers, so I think we should ask someone who is. EDIT: actually, |
I actually prefer the old name :). But, if we're going to change it, from an English perspective: A) B) Sorry to muck things up further :) |
👍 |
Keeping the old name for me ( |
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. |
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:
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 of what it varies-by. Here it's a boolean. The what is thus abstract. |
I'll do one last attempt.
|
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 <[email protected]>
*
* For the full copyright and license information, please view the LICENSE
* file that was distributed with this source code.
*/
namespace Symfony\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 <[email protected]>
*/
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.
*/
public function supports(string $type, ?string $format = null): ?bool;
} |
Follow up from #27105.