Should singular config objects be instances of a class that extends Entity?

1. TBH, when I worked on the initial design of Configurables, I stayed rather silent about this, but actually played with the idea and thought through it.
2. Translation is one possible benefit, Forms are another.
3. Unlike what I guess is being proposed here, my thoughts have always been based on the idea of a single Settings config entity, which would be used for all config objects representing settings.
4. A range of implications and consequences that Configurables have do not match up with settings though. There's no ID, there's no UUID, there's no label, they can only exist once, and only once, and only once with their name (not ID), and they must not vanish. In short, they are a completely different can of worms.
5. They can be considered as entities, but definitely not as "config entities" a.k.a. Configurables, because they have zero things in common.

The 4th and 5th point in #2 are why I think this should be won't fix.

#4 is one of the keys to why this is bad, because settings files absolutely can not be deleted unless their module is uninstalled. The results of this happening are pretty catastrophic. I agree there aren't really any commonalities and this is won't fix.

#2 only compares the two architectural concepts.

It does not imply that there couldn't be Settings next to Configurables.

@sun, we've continued to use "Configurables" as an issue tag, but it does not actually refer to anything in core, and I'm confused.

Settings next to Configurables

What are you suggesting? Another class, similar to ConfigEntityBase, also extending from Entity? Or reusing ConfigStorageController somehow?

The differences outlined in #2 would clearly require a dedicated entity base class and a dedicated storage controller. Nothing inherited from the current Config\Entity* classes.

Settings would still be entities though, and they could re-use all the entity/property system facilities. They would present a sorta new term of "universally unique entities."

To clarify further: The comparison in #2 left out what Settings and Configurables actually have in common:

6. They have a langcode, because at minimum, default configuration ships in English.
7. They have an owning module, because all settings are owned by some extension.
8. They very potentially even have an api version, because available settings and their possible values can (and do) change over time.
9. They are translatable.
10. They can be managed through the UI via forms.

If you'd task me to do this today, then I'd probably investigate the following first:

1. Introduce a new entity class Config\Entity\Settings extends EntityNG with accompanying storage controller (see #2).
2. Introduce a new Config\Entity\SettingsFormController that handles a settings form.
3. Seek a way to describe the properties being contained in the config object; super-potentially using the exact same way for describing properties of all other entities being used elsewhere. (consistency)
4. Aim for making the Settings entity empty by design first. Pollute its properties via entity properties only. Push as much as possible "upstream."
5. Only if that fails, consider introducing individual, inherited/derived, custom Settings entities à la UserAccountSettings extends Config\Settings and go the hard way.

Also related: #1818574: Support config entities in typed data EntityAdapter:

A range of implications and consequences that Configurables have do not match up with settings though. There's no ID, there's no UUID, there's no label, they can only exist once, and only once, and only once with their name (not ID), and they must not vanish. In short, they are a completely different can of worms.

Exactly. In particulary that they exist only once and must not vanish is what does not make them very entity like.

ad #8: Sounds reasonable, but how to approach the mentioned problem?

I was thinking about something like that:
- Making "settings a single entity type with the settings name "module.settings.bla" being the entity id.
- If you load the entity it gets the default settings file, or a settings files containing the change if existing.
- When saving the entity, it writes a new non-default settings file.
- When deleting the entity, it deletes the changes file only - so load continues to work with the defaults. (revert)

That's my brainstorming on that, not sure that would play with CMI and whether we it's something we really should pursue... It would have some nice advantages for us though.

Hi, I was wondering whether there is any progress with this one, I mean one way or another a decission needs to be made, and maybe in the last month people have made up their minds about this. Or if not, should we toss a coin? ;-)

Also I am concerned about the implications this has for ConfigEntityBase and translatable properties in general:

  /**
   * Overrides Entity::get().
   *
   * EntityInterface::get() implements support for fieldable entities, but
   * configuration entities are not fieldable.
   */
  public function get($property_name, $langcode = NULL) {
    // @todo: Add support for translatable properties being not fields.
    return isset($this->{$property_name}) ? $this->{$property_name} : NULL;
  }

And btw, wondering whether we've got an issue created for that @todo.

This is also a major concern now the 'config/metadata/translation' approach for the locale system has somehow 'derailed'. So I'm wondering whether you guys have an alternate plan about this...

a good number of our singular config objects have values that are accessed in performance-critical parts of the code. Wrapping those up in any further abstraction could be too costly.

My immediate and very simple answer to that would be to not use config entities when they are not strictly required.

In other words: Config entities are a high-level instrument to manage and operate on a particular config entity/object.

However, that does not inherently imply that anyone has to bootstrap a config entity to read a config object.

The contextual override logic upon read is handled in a different (low-level) layer of the config system anyway and is not tied to config entities anyway.

In short, read != write.

Perhaps a path to investigate.

It seems at this point that we aren't going to do this, which I agree with, so closing. Feel free to reopen if someone wants to get back into this topic at some point.