Silverstripe-framework: RFC: PSR-2, config, and static properties

[sminnee]

We've made the decision to adopt PSR-2/PSR-1 in SilverStripe 4.

UPDATE: I didn't read the fine print. It turns out that snake case static properties are okay; only method names need to be corrected.

My new recommendation is therefore that we leave static config properties as-is. 8-)

---

Was:

To do this completely, the naming convention of our statics will need to be changed from snake case to lower camel case.

Right now, our config files have a 1-to-1 mapping between the static name and the yaml config entry.

This raises a few questions:

• Should we use lower camel case statics as for new config statics that we create?
• Should the yaml files match these lower camel case statics, or perform some kind of remapping?
• What backwards-compatibilty provisioning should we allow for?

My recommendation is that we:

• use lowerCamelCase in both the PHP statics and the yaml files
• we use this new standard for any config variables introduced from today in either SS3 or SS4
• we endeavour to migrate all existing statics in core before the 4.0-beta1
• we endeavour to provide a tool for migrating config values from the old names to the new. More ambitiously, we do the same for PHP files.

The last 2 are non-trivial pieces of work, which is why I have said "endeavour". I'd really like to see that work get done but, push comes to shove, I'm not sure if it would block a release.

[micmania1]

Should we use lower camel case statics as for new config statics that we create?

I think so.

Should the yaml files match these lower camel case statics, or perform some kind of remapping?

No remapping from me. Config is already way too complex and slow. Also, developers don't really have any control over this so its not like people can opt-out.

What backwards-compatibilty provisioning should we allow for?

This ones tough :(. I think some kind of migration script would be necessary.

[sminnee]

I've started work on a migration tool here: https://github.com/sminnee/silverstripe-upgrader

[robbieaverill]

Should we use lower camel case statics as for new config statics that we create?

Yes.

Should the yaml files match these lower camel case statics, or perform some kind of remapping?

While I like camel cased variable names, I prefer underscore casing in YAML. That being said, I think we should support both - it wouldn't be too hard to look for a camel cased version of an underscored YAML property - rough example

What backwards-compatibilty provisioning should we allow for?

None - it's a major version update and as such backwards-compatibility is only necessary within the same major version number (4).

---

Can I add - I _really_ appreciate the move to PSR-2, but can you also please try and implement namespacing soon? It is actually a requirement of PSR-2, which I assume you'll be skipping for now?

[sminnee]

Yeah, namespacing is coming, into master section by section, and as a goal for alpha2. See #5419 #5420 #5421

[kinglozzer]

Unless I’m mistaken, neither PSR-1 nor PSR-2 actually specifies how properties have to be declared. PSR-1 states that it intentionally avoids making a recommendation, PSR-2 doesn’t make any mention of it that I can find.

Personally, I’d keep the current pattern. We could make all other (non-config) properties lowerCamelCase if we really want to, then the lowercase_underscore format could make properties “stand out” a bit more as being used for config.

[sminnee]

Oh, maybe I was getting confused with function names! In that case, retaining snake case would be a good idea as it avoids an unnecessary and invasive change.

[sminnee]

Since this has become, "remain as-is", I don't think this issue is helpful. Closing.