Rename Field.php to EntityField.php

+ a ton for dropping Field as a name for that class.
For people looking into Field API classes, it's way confusing to have that class pop up in PhpSorm's "Navigate to class" / "Navigate to file" and be the most obvious contender.

EntityField is not much better, though :-/
It does clarify things internally for views (views's "fields" enclose more than entity fields, and this class here is about fields from the entity system)

Would EntityFieldHandler be acceptable ? Seeing Handler clearly points that its about integrating with some system - which system system exactly (Views) is carried by the namespace, which is perfectly fine IMO.

It's also more compliant to our coding standards: "Classes and interfaces should have names that stand alone to tell what they do without having to refer to the namespace". This is not a "field", this is a "field handler". Again, which "kind of handler ?" is carried by the namespace, fine.

our coding standard is just bullshit, many people disagreed with it in a long long time

Aw. Well count me with those for which it makes a ton of sense, and would fight hard for keeping it ;-)

- If you rename NumberFormatter to Date, the class name is just a plain lie. An object that formats a Number is not a Number.
Namespaces carry domain/ownership, they should not carry role/identity.
- Then you have deeply confusing code, since once you've "use"d the fully qualified class at the top of the file, your code only works with the unqualified class name, which calls an apple an orange.
- Also very painful in IDE tabs that only show a file name (or PhpStorm CTRL-E which lists recent files)

Taking from a couple core plugin types :
All field widget classes have "Widget" in them
All field formatter classes have "Formatter"
All field item classes have "Item"
All (well, most non-test) block classes have "Block"
All filter classes have "Filter"
All image effect classes have "Effect"
All rest resource classes have "Resource"
...

But well - the fact that Views plugins (with a few other ones like Constraint, Condition, probably some others) chose not to comply is outside the scope of this rename here...

So, EntityField.php, then :-)

Could you please roll another patch using git diff -M, so the rename is marked as a change, rather than a deletion+new file?

I had to reroll it manually cause the code have changed a lot since the last patch.
Here is what I get.
(I can't install Drupal anymore with the master today, so I can't launch tests, lets see what the testbot says)

Thanks! That patch only contains the removal of the old patch, unfortunately.

This one should be better, but tests are broken

Big +1 as well, FWIW ;-)

Re-roll.

I re-rolled it using git diff -M

Can I work on this issue?

@joyceg : I guess anybody can join and help on any subject, as soon as you have red some minimum info (Just in case https://www.drupal.org/novice)

I stared from 0, and tried to find some more occurrences to replace.
Tests are still borken.

This one seems to be better

This seems quite disruptive with no evaluation of why the disruption is necessary? This issue is a task so we need to outline how it fits within the allowable Drupal 8 beta criteria. Can someone add Drupal 8 beta phase evaluation template to the issue summary.

re: disruption, this mostly impacts classes that extend Field / EntityField. We seem to have actually very few in core (taxo TermName, comment Depth) - and it seems those could be formatters instead ?

@dawehner: do you think there's a chance of many existing uses in contrib ?

#31 rerolled

#41 rerolled

reroll extended =)

This would be a BC break at this point, correct? Or at least require an upgrade path + tests?

I was thinking that the `@ViewsField("field")` annotation would change, too, to match the classname. If that says the same, then an upgrade path wouldn't be needed.

Started fresh w/ a refactor by rename in PhpStorm, and a manual search of strings.

How about this for BC? Do we need to test that, at least minimally?

OK, that approach made the patch big again. It does the rename, but then changes the Field class to be

<?php

/**
 * @file
 * Contains \Drupal\views\Plugin\views\field\Field.
 */

namespace Drupal\views\Plugin\views\field;

use Drupal\views\Plugin\views\field\EntityField;

/**
 * A stub class to provide backward compatibility for EntityField.
 *
 * @deprecated in Drupal 8.0.x and will be removed before 9.0.0
 *  Use \Drupal\views\Plugin\views\field\EntityField instead.
 */
final class Field extends EntityField {

}

Easier to read in place.

Talked w/ @dawehner briefly about this in IRC and will post a more better version tonight.

Removed the `final`. We could also mark this as @internal, but I think the @deprecated is better since it wasn't @internal to begin with.

Discussed with all the committers and we agreed this should be done in a minor version with BC.

The patch does not apply to drupal 8.3.

reroll #62

Applied #71 patch on 8.3.x . It worked cleanly.

Feedback from #70.

We should eventually trigger E_USER_DEPRECATED when the class is included, but don't have a coding standard for that for entire classes yet, so can defer that until #2575081: [policy, no patch] Use E_USER_DEPRECATED in Drupal 8 minor releases is further along.

I can't think of a better name, it's a bit confusing that the plugin is 'ViewsField' while the class is 'EntityField', but that would be another issue.

Committed/pushed to 8.3.x, thanks!