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

catch’s picture

Status: Postponed » Active

I 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.

tim.plunkett’s picture

It's after feature freeze!

alexpott’s picture

Are we sure that this is actually an issue? I don't think it is.

alexpott’s picture

#states is part of the Form API - it is not an API in itself. And state() is an implementation of the KeyValue API.

dawehner’s picture

I 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.

xjm’s picture

Actually, 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.

nod_’s picture

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).

tim.plunkett’s picture

One 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...

dawehner’s picture

We could just name it "#dependency" and kind of move even more of ctools into core!

catch’s picture

Priority: Major » Normal

Downgrading. I would be fine with #dependency though at first glance.

catch’s picture

Hmm 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.

webchick’s picture

Yeah, 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?

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.