> I'm all in favor for noise reduction in my code, but couldn't really see any solution to the conflicting name conventions I faced
Please, read messages above. > Why *specific* implementation has *non-specific* and generic name? Yet another point for removing suffix: it forces to think about implementation name more. > ... > Also, you wouldn't be allowed to have poor naming like Foo implements FooInterface. It looks like naming impotence: you have implementation, why you can't describe what makes this implementation specific: MySqlFoo? MemcachedFoo? ZendFoo? In short: if your implementation name is simple "Bar" and interface is "Bar", you're doing it wrong. So you failed to describe the intention/specificity/point of your implementation. On Thursday, August 18, 2016 at 4:10:25 PM UTC+3, Erik Landvall wrote: > > I had this discussion with some people from room 11. The general opinion > to me seem to be *not* to use the interface suffix, so I started looking at > why. I'm all in favor for noise reduction in my code, but couldn't really > see any solution to the conflicting name conventions I faced. Someone > pointed out to me that you would place implementations in a different > namespace or sub space. But this generated some strange names such as: > > ``` > use Foo\Bar; > use Foo\Bar\Bar as BarBar; > ``` > > IMO, this is worse then the suffixed interface. > Lets put that into context: > > > ``` > use Foo\Cache; > use Foo\Cache\Cache as FooCache; > ``` > > And if you like to make it even worse, what if the namespace is > `Psr\Cache`: > > ``` > use Psr\Cache\Cache; > use Psr\Cache\Cache\Cache as PsrCache; > ``` > > ...this makes no sense to me, what is what here? and why require an alias? > I understand if you don't develop modular and that then the > implementations can go in a sub space, such as: > > ``` > use Psr\Cache; > use Psr\Cache\Cache as PsrCache; > ``` > > But sense we like components and modules that needs to be distributed as > such, then better semantics IMO would be: > > ``` > use Cache\Cache; > use Cache\RedisCache; > use Cache\MemoryCache; > use Cache\FileCache; > ``` > > ...implementations should define how they are implemented. When I later > declare a dependency, I'm declaring that my class is dependent on a Cache > instance, the interface suffix is redundant. > > On a different note, if we are discussing to remove the `Interface` > suffix, then included in the discussion should also be `Trait` suffixes and > `Abstract` prefixes as mentioned before. Maybe it can be considered best > discussed in different threads? In that case, please correct me, but I > would say that it's the same category and the same arguments. > > TL;DR > > - Suffixes like `Interface` adds redundant noise to the code. > - Using the suffix makes it more comfortable to create an implementation > that is not using a naming convention that declares it's implementation > from a semantic perspective (eg. implementing a CacheInterface into a class > named Cache) > > > My impression is that the majority of member projects use the Interface > suffix. > > The argument that "this is the way we always have done it" is not a good > argument IMO, evolving implies change. It's an interesting phenomenon > though: https://www.youtube.com/watch?v=C9ySOuJ83Ww > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8bd1130a-19b1-4561-8f14-cf302df29b30%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
