In StylePluginBase Rename Views properties to core standards

+1 to adding a DeprecatedPropertyTrait similar to the service one, if we are going to do this everywhere in Views.

Maybe $deprecatedProperties can include the change record ID? Something like:

  protected $deprecatedProperties = [
    'rendered_fields' => ['renderedFields', 3344579],
    'render_tokens' => ['renderTokens', 3344579],
  ];

1. +++ b/core/modules/views/src/Plugin/views/DeprecatedPropertyTrait.php
   @@ -0,0 +1,40 @@
   +namespace Drupal\views\Plugin\views;
   

   Feel useful outside Views to maybe? Currently not doing anything that would make this Views only, so maybe move it somewhere more generic?

2. +++ b/core/modules/views/src/Plugin/views/DeprecatedPropertyTrait.php
   @@ -0,0 +1,40 @@
   +/**
   + * Provides a standard way to announce deprecated properties.
   + */
   

   Maybe expand on this that the 'deprecatedProperties' property must be set on all classes that implement this trait?

3. +++ b/core/modules/views/src/Plugin/views/DeprecatedPropertyTrait.php
   @@ -0,0 +1,40 @@
   +   * Allows to get deprecated/removed properties.
   ...
   +   * Allows to set deprecated/removed properties.
   

   'Allows throwing an exception when a property is accessed that has been marked as deprecated.'

4. +++ b/core/modules/views/src/Plugin/views/DeprecatedPropertyTrait.php
   @@ -0,0 +1,40 @@
   +    if (!isset($this->deprecatedProperties)) {
   +      throw new \LogicException('The deprecatedProperties property must be defined to use this trait.');
   +    }
   

   This bit is only in __get not __set, shouldn't it be in both?

5. +++ b/core/modules/views/src/Plugin/views/DeprecatedPropertyTrait.php
   @@ -0,0 +1,40 @@
   +      @trigger_error("The property $name is deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use $property instead. See https://www.drupal.org/node/$link", E_USER_DEPRECATED);
   

   Hardcoding the Drupal version means we can't use this in 10.2 without existing deprecation messages also changing, so I think that needs to be dynamic as well

I only found this issue because I was checking if there were any issues filed on Drupal 8. I am changing the version to 10.

So, this issue is scoped by file but we now make coding standard fixes by sniff and with a different scope. That would make this issue a won't fix. For reference, the issue for the relevant sniff is #2937514: Fix Drupal.NamingConventions.ValidVariableName.LowerCamelName in tests.

But this issue is also proposing a way to deprecate properties. I think that should be discussed in it's own issue and work on the above issue is postponed on that. What do you think?

Neat!

1. +++ b/core/modules/views/src/Plugin/views/DeprecatedPropertyTrait.php
   @@ -0,0 +1,40 @@
   +    if (!isset($this->deprecatedProperties)) {
   

   any reason not to put deprecatedProperties on the trait and make it empty?

   I assume to prevent using the trait by accident?

2. +++ b/core/modules/views/src/Plugin/views/DeprecatedPropertyTrait.php
   @@ -0,0 +1,40 @@
   +      @trigger_error("The property $name is deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use $property instead. See https://www.drupal.org/node/$link", E_USER_DEPRECATED);
   

   What if it is deprecated in 10.2.0? Do we need more than $property and $link? Should we have a simple value object?

3. +++ b/core/modules/views/src/Plugin/views/style/StylePluginBase.php
   @@ -109,6 +111,23 @@ abstract class StylePluginBase extends PluginBase {
   +   * Keyed array pf replacements where key is deprecated property name.
   

   of

Addressed #10.3