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
Comment #1
yched commentedThe 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.
Comment #2
swentel commentedJust kill that function completely and move to annotations or something like that ?
Comment #3
yched commentedYeah, 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...
Comment #4
amateescu commentedNote that
field_info_[widget|formatter]_settings()is already added asgetDefaultSettings()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.Comment #5
yched commentedHeh. Code to steal from there then :-)
Comment #6
swentel commentedThis 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.
Comment #7
yched commentedI 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.
Comment #8
swentel commentedHmm, I'm looking at module_enable() for instance, which does this:
So kinda looks ok, I guess, unless I'm missing something, can happen after a whole week of freaky coding :)
Comment #9
yched commented#8: I think you lost me :-)
Comment #10
andypostmaybe better to swap bundle and field?
Comment #11
yched commented#10 : oh, *extremely* good call !
I've been slapping myself in the face for years because of the silly order in field_info_instance()
Comment #12
yched commentedAlso, actually, shouldn't it be getInstance() instead of getBundleInstance() ?
Comment #13
swentel commentedOh 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)
Comment #14
yched commented"Also wondering whether to mark all the functions that I'm trying to kill in ..."
No need IMO
Comment #15
andypostSo fixed patch
EDIT I think it should be
getBundleInstance()to mirrorgetBundleInstances()so $bundle argument have the same nameComment #16
yched commentedI 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".
Comment #17
swentel commentedAdded 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().
Comment #18
amateescu commentedWe should reference the new methods for getting the info here, as the wrappers are deprecated by this patch :)
Missing types :P
Other than that, looks good to me.
Comment #19
swentel commentedI just removed that comment, that was just completely wrong :)
Fixed the types.
Comment #20
amateescu commented@return array .. :-s
Comment #22
swentel commentedAaaaargh
Comment #23
amateescu commentedGreat, thanks!
Comment #24
dries commentedCommitted to 8.x. Thanks.