Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This is deliberately postponed until after feature freeze, because we do not under any circumstances need to be distracting ourselves by having this conversation now.
However, we should have it sometime after that, because these two are very similarly-named yet very completely different APIs. I can see that causing all kinds of confusion.
Comments
Comment #1
catchI don't understand why this was postponed, there's now approximately two days to rename this if at all unless we make an exception and break BC for what would only be a rename.
Comment #2
tim.plunkettIt's after feature freeze!
Comment #3
alexpottAre we sure that this is actually an issue? I don't think it is.
Comment #4
alexpott#states is part of the Form API - it is not an API in itself. And
state()is an implementation of the KeyValue API.Comment #5
dawehnerI would really assume that people writing code are not stupid. As written by alex the amount of overlap of these two systems is basically zero.
Comment #6
xjmActually, it does cause confusion. I personally am (at least briefly) confused when people ask me about work I did previously on "states", and the only reason I figure it out with a little more context is that I kinda spent a lot of time working on D8.
I don't necessarily think this issue is major, and I don't necessarily think it merits an API change at this point in the cycle. But it's not entirely a non-issue, either.
Comment #7
nod_Talk about an edge case :þ
I'm pretty sure when we talk about changing the API we're talking about the JS one, if there is better name out there why not. I don't think #states is known very much out there (I sure would love stats on what developers actually use).
Comment #8
tim.plunkettOne is plural, the other is not. And the confusion can be resolved in a matter of seconds.
This isn't "context", which we have two of in core and a dozen of in contrib...
Comment #9
dawehnerWe could just name it "#dependency" and kind of move even more of ctools into core!
Comment #10
catchDowngrading. I would be fine with #dependency though at first glance.
Comment #11
catchHmm that comment was a bit short. I think the main confusion between these two is between which API is being talked about if it's mentioned, not between the actual APIs themselves, since they're so completely different. So there is some scope for confusion, but as tim.plunkett points out we have (and have had) considerably more confusing things in core. hook_form() vs. hook_forms(), hook_load() vs. drupal_load(), route controllers vs. entity controllers etc. etc.
Comment #12
webchickYeah, agree that the ambiguity is around people talking about the concept (either in real life or on the forums/issue queue), and also agree with this just being "normal" and that the the best approach is most likely renaming #states to something else, since #states makes absolutely no sense for the behaviour that the API does. I do think the confusion here is a bit worse than your stated examples, though; at least both hook_forms() and hook_form() are both talking about forms. :)
#dependency sounds much better to me, especially if there's a precedent for this in contrib. I think it could still be possible to merely deprecate #states and make this change?