Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[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

Conversation

teohhanhui
Copy link
Contributor

@teohhanhui teohhanhui commented May 9, 2018

Q A
Branch? 4.1
Bug fix? no
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets N/A
License MIT
Doc PR N/A

Follow up from #27105.

@teohhanhui
Copy link
Contributor Author

/cc @dunglas

Bug label was a mistake.

@dunglas dunglas removed the Bug label May 9, 2018
@dunglas dunglas requested a review from nicolas-grekas May 9, 2018 12:53
@teohhanhui
Copy link
Contributor Author

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
Copy link
Member

@nicolas-grekas nicolas-grekas May 9, 2018

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.

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll improve it. 😄

@nicolas-grekas nicolas-grekas added this to the 4.1 milestone May 9, 2018
@teohhanhui teohhanhui force-pushed the rename/serializer-supports-cacheable branch from 72de9df to 2fb8ce9 Compare May 11, 2018 10:02
@teohhanhui
Copy link
Contributor Author

teohhanhui commented May 11, 2018

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.

@teohhanhui teohhanhui changed the title [Serializer] Rename CacheableSupportsMethodInterface to SupportsVaryInterface [Serializer] Rename CacheableSupportsMethodInterface to VaryingSupportInterface May 11, 2018
@teohhanhui teohhanhui force-pushed the rename/serializer-supports-cacheable branch from 2fb8ce9 to da5038b Compare May 11, 2018 12:48
@@ -12,15 +12,16 @@
namespace Symfony\Component\Serializer\Normalizer;
Copy link
Contributor Author

@teohhanhui teohhanhui May 11, 2018

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?

@dunglas
Copy link
Member

dunglas commented May 11, 2018

I like this one (VaryingSupportInterface) 👍

@teohhanhui
Copy link
Contributor Author

Current proposed method name:
isVaryingSupportByData

Interpretation:
Is this normalizer and/or denormalizer varying its support by the data provided?

Alternative proposed method name:
isSupportVariedByData

Interpretation:
Is this normalizer and/or denormalizer's support varied 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 denormalizer support (some kind of?) varied (thing?) by data???

Which might cause some confusion...

@@ -150,9 +150,9 @@ public function setIgnoredAttributes(array $ignoredAttributes)
/**
* {@inheritdoc}
*/
public function hasCacheableSupportsMethod(): bool
public function isVaryingSupportByData(): bool
Copy link
Member

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).

Copy link
Contributor Author

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.

@teohhanhui
Copy link
Contributor Author

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

Source: the above mentioned corpus / corpora.

@teohhanhui teohhanhui force-pushed the rename/serializer-supports-cacheable branch from da5038b to 5a1f084 Compare May 11, 2018 13:22
@teohhanhui
Copy link
Contributor Author

/ping @dunglas @nicolas-grekas @ogizanagi

@ogizanagi
Copy link
Contributor

ogizanagi commented May 14, 2018

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.

@weaverryan
Copy link
Member

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 the supports() method can be cached/varies. I think NOT having the "s" complicates things

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

Sorry to muck things up further :)

@ogizanagi
Copy link
Contributor

👍 doesSupportsVary for me. Thanks @weaverryan

@dunglas
Copy link
Member

dunglas commented May 14, 2018

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

@fabpot
Copy link
Member

fabpot commented May 14, 2018

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.

@teohhanhui
Copy link
Contributor Author

@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.

@nicolas-grekas
Copy link
Member

HTTP vary is a list of what it varies-by. Here it's a boolean. The what 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.

@teohhanhui
Copy link
Contributor Author

I'll do one last attempt.

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

@teohhanhui
Copy link
Contributor Author

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!

@teohhanhui teohhanhui closed this May 14, 2018
@teohhanhui
Copy link
Contributor Author

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;
}

@teohhanhui teohhanhui deleted the rename/serializer-supports-cacheable branch May 16, 2018 14:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants