Home > Back-end >  Why are traits sometimes grouped as "concerns" in PHP packages?
Why are traits sometimes grouped as "concerns" in PHP packages?

Time:05-10

When looking through package source files, I often see a folder titled "concerns" that seems to exclusively house trait files. A few examples:

While other packages just have a folder named "traits" for traits. Ex:

Is it just personal preference, or is there a meaning behind naming the folder "Concerns"?

CodePudding user response:

I think it's just a "good enough" name picked by community. Indeed, traits are not "objects" or "factories" or "repositories" - they don't do anything by themselves, but they are adding properties and qualities to classes where they are used. And the word "concern" doesn't only mean "something that worries me", but also "being about something", which generally matches the purpose of traits.

Personally I don't think the word "concern" is better or more informative than "trait". Especially for those familiar with the concept and PHP terminology and if that folder indeed contains just traits. But sometimes it's good to pick a more generic name to avoid being bound by language-specific naming.

Just to clarify this - you can call a folder/namespace in you project "databases", but if later you decide you store your data only in memcache, it would look unexpected and weird to have "memcache database". But if you picked a generic name "storage" - then any database, memcache or even interface for a remote service is appropriate to be put into it.

UPD: I've got too curious and done a bit more reaserch. Turns out the word "concern" in this context came from Ruby-on-rails world, where it basically means the same as trait in PHP (another pretty common word for this is "mixin"):

https://medium.com/@carlescliment/about-rails-concerns-a6b2f1776d7d

How to use concerns in Rails 4

  • Related