Of course I strive to build agreement on Interfaces, that's why I moved all of my Interfaces out of the Molajo repo and placed them into an unbranded repo
and listed them as packages on Packagist. I want to encourage sharing at that level for interoperability -- without having to "give credit." I use all of those Interfaces - there are about 150 of them - as dependencies in Composer for Molajo.
However, it is not true that I advocate Interfaces _over_ concrete implementations. I advocate Interfaces _with_ implementations. In this package alone, I am using six interfaces. In one case, it allows developers to slide in their database package for a foreign key fieldhandler without creating a dependency on the one I am using. (Joomla's).
Even in my own application, I inject interfaces for my own packages, I never name concretes in my classes, only Interfaces. This is so that a dev could use the Molajito rendering package, for example, and whatever escaping option they want. Or, they can use my Event package with their plugin environment, etc. I've worked very hard to build in those flexibilities.
(Where I do use concrete references is in the factory model classes for the IoCC, but that's the plumbing -- and that's exactly where it would be changed if another concrete was preferred. The other place you'll see me naming concretes is in the fieldhandler where the proxy class creates the adapter class. For those "internal to a package" places -- it's okay because it won't be swapped out.)
Here is my frustration. You and I are talking about replacing InputFilter and OutputFilter
with something that is easier to extend and updated in terms of PHP 5.3 filtering, etc. I'm offering my code. I'm doing a little analysis in the spreadsheet to map what I have to what must be replaced in the Joomla framework and trying to think about how we can cleverly avoid BC issues and test to ensure it continues to work as expected.
No, I do not believe most developers are not going to pick a framework or package that only has Interfaces unless they are building a framework. They aren't even likely, IMO, to pick a framework that makes good use of Interfaces. What they are more likely to do is select a package that helps them validate and/or filter and/or escape their data without a lot of fuss and do so correctly.
So, to hear you say let's just offer interfaces and everyone can code it their way -- well, Andrew, that may sound fabulous to you and me -- but most developers just want the code. And no, I don't want to do it my way and have you do it your way. The Joomla framework just needs one solid package that can go the distance the next few years.
I do not care how we do it.
I don't even care if you want to do it yourself. I know what it's like to have a vision and have no choice but to lay the code.
But, I see no reason to have less than or more than one of these in the Joomla framework and I am willing to help but this is you guys architecture and you need to make some choices. I can help provide data or analysis for review, but it's not my framework. It's yours -- and I hope you guys have a vision of where you want this to go.
Here are the Interfaces I am using -- yes, I have filter, validate and escape separated. I also added a response object given the discussion here.
I don't need flexibility in licensing. I know what Joomla requires. I have signed the agreement. I'm not asking for anything different. I'm not trying to be a library -- you can have raw code -- whatever you want or need.
If any of my code is useful it can be brought into the Joomla framework under the LGPL and changed. It will be treated like any other Joomla code -- OSM's copyright -- your coding standards, your code. You can delete it - restructure it - keep it as it is. I'm still family. Like it, or not. ;-)