Let's deprecate functions now in field.info.inc. We can remove them after July 1. Obvious ones are field_info_field_by_ids(), field_info_field_by_id ...
Question is if we can move even more functions or not.

See also discussion in IRC

<swentel> xjm: we're in the process in killing much procedural functions in Field API. There's one file in field.module (field.info.inc) which still contains a lot of procedural functions which we could move to the FieldInfo class. Thing is, can we mark them deprecated now and still remove them after july 1st ?
 <swentel> yched: ^ looping in
<xjm> swentel: IF the new API is already in place
 <xjm> swentel: it is even conceivable we could add methods that wrap the procedural functions, then flip it after code freeze, so long as the param/return/etc. are the same
 <swentel> xjm: it is, afaics, they just all become static methods on a class which is also available in the container. I can double check to make sure of course. 
 <andypost> they should all not sure static
 <swentel> well, maybe not all, a couple :)
 <xjm> swentel: as effulgentsia put it, we can deprecate anything that we're in the process of converting if the public API is the same, but what we can't do is say "deprecated in favor of a new API that doesn't exist yet; it will be nicer, trust us!"
 <andypost> swentel, suppose we should just move code before 1jul and mark deprecated
 <swentel> xjm: oh no, they are already really dumb wrappers right now. It's really just a matter of moving.
 <swentel> xjm: I'll recheck again with yched to see what we'll do in the end. Can I paste your answers in the issue ? 
 <xjm> andypost, swentel: think of it as: the API afterf July 1 needs to maintain BC with the API as of July 1, minus anything marked deprecated. And sure.
 <yched> yeah, I think they are pretty much all wrappers around either FieldInfo or plugin managers
 <xjm> swentel, yched: Ideally your @deprecateds will be accompanied by @see to the new methods
 <yched> swentel: there is field_info_collate_types() which is still about "old style / non plugin" field types, but that's being taken care of
 <yched> swentel: and, well, it's also about "old style / non plugin" storage backends :-/
 <yched>  Ideally your @deprecateds will be taken behind the barn and shot in the head. With humanity.

Comments

yched’s picture

The functions that relate to plugins (field_info_[widget|formatter]_types(), field_info_[widget|formatter]_settings()...) could move directly to the plugin managers. If needed, helper methods on those to return "just the settings" could be added.

Oh, and field_behaviors_widget() needs to die a slow and painful death. There should be no use for it anymore.

swentel’s picture

Just kill that function completely and move to annotations or something like that ?

yched’s picture

Yeah, it's just a leftover - at some point in D6 there were more stuff in there, but even in D7 it's an aberration.
Now it's just reading the "default value" of the widget plugin info...

amateescu’s picture

Note that field_info_[widget|formatter]_settings() is already added as getDefaultSettings() to each plugin manager in #2014821: Introduce form modes UI and their configuration entity, but I didn't deprecate anything to keep the patch size down.

yched’s picture

Heh. Code to steal from there then :-)

swentel’s picture

Status: Active » Needs review
StatusFileSize
new3.84 KB

This is what I have so far. Couple marked deprecated + added getBundleInstance() onto fieldInfo class().

Also wondering whether Drupal\field\Field should move to Drupal.php ? It seems a bit lonely now :)

Not sure yet about field_info_widget_types(), field_info_formatter_types() , just a getTypes($type) method on the plugin managers ?

I'd kill field_behaviors_widget() in a separate issue though.

yched’s picture

I think the Field:: should be fully namespaced in the docs.

Well, we're not system, so our services can't go in \Drupal, that's the current standard...
Views has a similar class too, not sure if there are other examples in core right now.

swentel’s picture

Hmm, I'm looking at module_enable() for instance, which does this:

Drupal::moduleHandler()->enable($module_list, $enable_dependencies = TRUE).

So kinda looks ok, I guess, unless I'm missing something, can happen after a whole week of freaky coding :)

yched’s picture

#8: I think you lost me :-)

andypost’s picture

+++ b/core/modules/field/lib/Drupal/field/FieldInfo.phpundefined
@@ -481,6 +481,31 @@ public function getBundleInstances($entity_type, $bundle) {
+   * @param $entity_type
+   *   The entity type for the instance.
+   * @param $field_name
+   *   The field name for the instance.
+   * @param $bundle_name
+   *   The bundle name for the instance.

maybe better to swap bundle and field?

yched’s picture

#10 : oh, *extremely* good call !
I've been slapping myself in the face for years because of the silly order in field_info_instance()

yched’s picture

Also, actually, shouldn't it be getInstance() instead of getBundleInstance() ?

swentel’s picture

Oh yeah, that makes sense.

I'm deep down in reviving component handlers, so andy, if you want, go nuts on this :)
Also wondering whether to mark all the functions that I'm trying to kill in #2018319: Remove field_read_field(s)() and field_read_instance(s) in favor of entity_load() and entity_load_multiple_by_properties() (which is green btw)

yched’s picture

"Also wondering whether to mark all the functions that I'm trying to kill in ..."
No need IMO

andypost’s picture

StatusFileSize
new3.83 KB
new1.88 KB

So fixed patch

EDIT I think it should be getBundleInstance() to mirror getBundleInstances() so $bundle argument have the same name

yched’s picture

I still vote for getInstance().
You use this function when you know exactly what instance you want. getBundleInstance() has no meaning, instances are not "bundle instances".

swentel’s picture

StatusFileSize
new3.3 KB
new5.78 KB

Added deprecates for field_read_x too from #2018319: Remove field_read_field(s)() and field_read_instance(s) in favor of entity_load() and entity_load_multiple_by_properties().

Went for getInstance(), I'm in favor for that as well, it maps to getField().

amateescu’s picture

Status: Needs review » Needs work
+++ b/core/modules/field/lib/Drupal/field/FieldInfo.php
@@ -481,6 +481,31 @@ public function getBundleInstances($entity_type, $bundle) {
+   * the bundle, allowing fast retrieval of field_info_field() or
+   * field_info_instance() later in the request.

We should reference the new methods for getting the info here, as the wrappers are deprecated by this patch :)

+++ b/core/modules/field/lib/Drupal/field/FieldInfo.php
@@ -481,6 +481,31 @@ public function getBundleInstances($entity_type, $bundle) {
+   * @param $entity_type
+   *   The entity type for the instance.
+   * @param $bundle
+   *   The bundle name for the instance.
+   * @param $field_name
+   *   The field name for the instance.
+   *
+   * @return

Missing types :P

Other than that, looks good to me.

swentel’s picture

Status: Needs work » Needs review
StatusFileSize
new940 bytes
new5.6 KB

I just removed that comment, that was just completely wrong :)

Fixed the types.

amateescu’s picture

@return array .. :-s

Status: Needs review » Needs work

The last submitted patch, 2019147-19.patch, failed testing.

swentel’s picture

Status: Needs work » Needs review
StatusFileSize
new583 bytes
new5.61 KB

Aaaaargh

amateescu’s picture

Status: Needs review » Reviewed & tested by the community

Great, thanks!

dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 8.x. Thanks.

Automatically closed -- issue fixed for 2 weeks with no activity.