Proposal for a Common Namespace for Interfaces

[Amy Stephen]

I'd like to gauge interest in a simple PSR for a simple, two-level shared namespace for Interfaces. (This approach is supported by PSR-4 -- meaning it fits the rules and should work with a compatible autoloader).

My thinking is in offering a small amount of structure (two-levels) and a shared namespace (examples below), it could help encourage organic collaboration in the PHP community between willing projects where it does not require as much discussion and collaboration as a PSR.

Many projects have fantastic full sets of Interfaces which have untapped potential driving interoperability.  Over time, these independent efforts would likely to gain support and become a defacto standard that might (or might not) gain official sign-off as a PSR and then use the PSR namespace.

Over the years, in observing open source communities, it seems a little structure, a lot of freedom, and recognition for work well done, lead to innovation. I have found myself thinking about how FIG might build some energy and involvement around its important mission and introduce those opportunities for the broader PHP community to collaborate along common goals.

Towards that end, I offer this idea for your consideration.

Examples of two level namespace prefixes that could be added to and maintained on the Wiki:

• Api\Authorisation
• Api\Cache
• Api\Controller
• Api\Database
• Api\Email
• Api\Event
• Api\Filesystem
• Api\Http
• Api\IoCC
• Api\Language
• Api\Log
• Api\Model
• Api\Route
• Api\Render
• Api\User

[Michael C]

+1 however the list should remain in the PSR if it is to be a PSR. The problem with that being is that we do not change PSRs.

 

Thanks,

Michael Cullum

 

--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8dfa7ae2-3ec9-4a11-b71f-8fe7598026f9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Amy Stephen]

On Wednesday, November 6, 2013 6:19:04 PM UTC-6, Michael Cullum wrote:

+1 however the list should remain in the PSR if it is to be a PSR. The problem with that being is that we do not change PSRs.

Michael -

I was thinking something roughly along these lines (this is a 5-minute draft but it gives a little more body to the concept)

Interface Namespaces

This document defines common, shared namespaces for Interfaces.

The goal is to encourage interoperability between PHP projects using common Interfaces. Frameworks, CMSs, and Package developers MAY implement interfaces for their own purposes defining the qualified namespace within the shared namespace. Interface authors are encouraged to collaborate with others who have similar interfaces to refine definitions and construct standard approaches.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The word implementer in this document is to be interpreted as one implementing an Interface using a common Interface Namespace.

1. Specification

    A list of approved namespaces for interfaces SHALL be maintained by FIG {link to the workspace-maybe a github repo for PR's}.

    Each namespace MUST have an associated definition to aid implementers in selecting an appropriate Interface Namespace.

    FIG may add to or remove from the list of approved namespaces.

    Implementers MAY use the common namespace for their interfaces and within their frameworks, CMSes and software packages.

    A list of qualified interfaces for each namespace SHALL be maintained by FIG to encourage collaboration towards common API's.

    Implementers MAY propose their interface be added to the list of qualified interfaces by following the instructions posted {here} after ensuring those interfaces qualify.

1.2 Qualified Interfaces
        
    In order for an Interface to qualify for listing, the following conditions must be met:
   
    All implementers offering the same type of qualified interface MUST be willing to collaborate towards a single, shared Interface.
 
    The Interface MUST be licensed according to {FIG licensing}.

    The Interface MUST be publicly available, at no charge, and packaged without concrete class(es).

    The Interface MAY be packaged with other qualified Interfaces.

    The Interface MUST conform to PSR-2 and PSR-4.

    The Implementer MUST be willing that the Interface be available to FIG for consideration of becoming the source for a PSR and, if so selected, to be distributed by FIG.

 

[Michael C]

Amy,

 

I still think it should be in the Spec (and continue to avoid external links citing them as part of the PSR) and I don’t think we should be able to remove/edit them, just append extra ones (make it an exception PSR for amending it).

 

--

Thanks,

Michael Cullum

 

--

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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/d6bc99e1-f5f8-47c3-8005-1c3a9250fc37%40googlegroups.com.

[Phil Sturgeon]

There was some discussion around having "Active" specs which are entirely Informational, which can break BC all day because its advice.

https://groups.google.com/d/msg/php-fig/uMB4B7uZ7FY/VGsGEsTnBkwJ

Just throwing that in there, I have no idea if this spec has merit or not and am not commenting on that :)

[Jason Judge]

Amy,

This feels (or feels like it should be) more like a policy document than a PSR.

I wonder if it could be used to widen the interest of the group by forming the basis of a fact-finding mission to find what common interfaces people use, how willing people (i.e. projects) are to pull them together to a shared goal and ultimately maybe a PSR? I bet there is an awful lot of information, ideas, approaches and views that could be collated for these interfaces and others we have not considered yet.

I guess I don't have a good grasp at this stage of the concrete problems that such a PSR would be trying to solve.

-- Jason

[Amy Stephen]

On Friday, November 8, 2013 5:03:50 AM UTC-6, Jason Judge wrote:

I guess I don't have a good grasp at this stage of the concrete problems that such a PSR would be trying to solve.

More of an opportunity, perhaps, than a problem?

The goal of this group is, as I understand it, is to help drive interoperability of software. This has been accomplished, thus far, by the introduction of four PSRs. One addressed namespaces, the other two addressed coding standards, another to introduce a common Interface for logging.

Since then, although there have been many, many posts and proposals, most efforts have been set aside as not appropriate and proposals nearing adoption seem frequently to be met in the last minutes with new replacement proposals intended to accomplish the same goal, done differently.

In short, the reality is, since PSR-3, it's been a long dry spell. 

Interoperability is a good goal and the group is right to focus on the purpose. But, I'm wondering, should the group do all of the heavy lifting? Make all of the decisions? It seems, perhaps, to be creating a bottleneck to progress. Maybe the goal would be easier to drive towards, maybe the results that much better, if efforts were directed towards setting the stage for broader involvement of those so inclined, those motivated, by preparing the soil, planting seeds, and in doing so, engage and empower the broader community. Stepping back and enabling others to make good things happen.

Towards that end, establishing a set of namespaces might help sketch out the lay of the land, as it were, for the kind of shared software present in so many software projects. Software that has been created multiple times, software that continues to be created, to accomplish the same purpose. Note: I am not of the belief that many projects each writing the same code is necessarily bad but I do believe the collective results are made better with interoperability.

A set of namespaces set aside for Interfaces that any PHP developer can use will help create focus on common API's. It will reinforce a culture of interoperability, an expectation that this shared space requires collaboration. The hope would be a qualified name of Api/Http/ResponseInterface, for example, could result in use by several projects and prompt them to independently collaborate in a cooperative fashion towards a common API.

That type of organic involvement really is more geared towards how open source communities work. We tend to be most productive with minor structure, enough to light the way, but a great deal of freedom and independence,  and recognition for effort made.

Hope that helps explain some of the thinking behind this type of idea.

[Phil Sturgeon]

On Friday, 8 November 2013 08:43:01 UTC-5, Amy Stephen wrote:

In short, the reality is, since PSR-3, it's been a long dry spell. 

You're forgetting about the caching PSR, which is still trundling along.

 

Interoperability is a good goal and the group is right to focus on the purpose. But, I'm wondering, should the group do all of the heavy lifting? Make all of the decisions? It seems, perhaps, to be creating a bottleneck to progress. Maybe the goal would be easier to drive towards, maybe the results that much better, if efforts were directed towards setting the stage for broader involvement of those so inclined, those motivated, by preparing the soil, planting seeds, and in doing so, engage and empower the broader community. Stepping back and enabling others to make good things happen.

The group is responsible for these tasks (not just the voting members) so anyone interested in developing PSRs is welcome to do so. This means anyone in the entire PHP community who is interested can help. They just don't. This approach won't solve that.

Towards that end, establishing a set of namespaces might help sketch out the lay of the land, as it were, for the kind of shared software present in so many software projects. Software that has been created multiple times, software that continues to be created, to accomplish the same purpose. Note: I am not of the belief that many projects each writing the same code is necessarily bad but I do believe the collective results are made better with interoperability.

Having a set of namespaces does not help interoperability, just gives stuff a bunch of names. Interoperability of classes and packages is increased with shared resources, which are specific to the task at hand, which is exactly what the group is trying to do and has been for a long time. This approach does not solve that either.

 

A set of namespaces set aside for Interfaces that any PHP developer can use will help create focus on common API's. It will reinforce a culture of interoperability, an expectation that this shared space requires collaboration. The hope would be a qualified name of Api/Http/ResponseInterface, for example, could result in use by several projects and prompt them to independently collaborate in a cooperative fashion towards a common API. 

But we'd have to make that interface, and discuss which methods would be in there, and which arguments it would take. That would be the job of creating a HTTP Interface standard, which the group needs to get back on top of doing. Asking random developers to all agree on the interfaces and arguments outside of the group just because a suggested name has been listed does not seem like a viable solution.

 

That type of organic involvement really is more geared towards how open source communities work. We tend to be most productive with minor structure, enough to light the way, but a great deal of freedom and independence,  and recognition for effort made.

Hope that helps explain some of the thinking behind this type of idea.

Maybe I'm reading you wrong, but this just seems to read as "We've had a hard time creating specific interfaces for certain tasks, so lets define a list of all interfaces we'll ever need so the community can do it all for us."

I'd rather use the approach of "Lets get the community involved with specific PSRs such as HTTP Messages and get that on the path to completion, or even get something official in Draft with an interested working group, then see if we can rustle up some contenders for a new Pre-Draft PSR on Routing or something." :)

[Amy Stephen]

On Friday, November 8, 2013 9:44:47 AM UTC-6, Phil Sturgeon wrote:

On Friday, 8 November 2013 08:43:01 UTC-5, Amy Stephen wrote:

In short, the reality is, since PSR-3, it's been a long dry spell. 

You're forgetting about the caching PSR, which is still trundling along.

My facts are correct. There have been no PSR's passed since PSR-3.

Even though you don't see my proposal as a viable way to engage the broader community, I appreciate your feedback.

Cheers!

[Phil Sturgeon]

You didn't say anything about facts, you said it had been a quiet spell, and that sounds like no work being done. The Cache PSR is still being worked on, so its not a quiet spell. :)

The Cache PSR would have been finished a long time ago if LESS people were involved. It was random people diving in and throwing in alternatives that made this into the mess that it ended up being, and tacked at least a year onto the process. Getting even more people involved would probably mean it never gets finished.

Thanks for the suggestion, but the idea of trying to get a huge section of the PHP community to try to tackle all problems at once instead of using instead of interested and targeted working groups sounds like the opposite of productive. Too many cooks, etc.

[Drak]

Yeah. I am also not convinced at all by the proposal for much of what paul said.

I also take issue with comments that we have not passed a psr for a while. That is irrelevant. Plenty of discussions and activity have been ongoing. Frequency of psrs is not a good measure of anything. Progress matters and getting things right.. Even if it takes a long time.

Silence is also golden. It doesn't hurt to have pause and also let things ferment. We do not need to fill the silence for the sake of it.

It would be much better to let current PSRs come to a resolution first IMO than create more noise.

Drak

--

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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/dac57e36-3369-4f33-893d-e7f1aefa90d0%40googlegroups.com.

[Amy Stephen]

Just saw a Tweet today pointing to an interesting initiative announced in ZDNet - At last, an API Commons

The API Commons, announced by 3scale and API Evangelist,  provides a transparent mechanism for the copyright free sharing and collaborative design of API specifications, interfaces and data models.

 

Very much like the goals of my proposal for the PHP community. A way to encourage crowd sourced collaboration driving towards common APIs.

Cool.

[Phil Sturgeon]

Compiling a central resource for sharing best practices of approaches to building web APIs is rather different from telling people what names they should use for their packages and hoping that results in them collaborating on reusable shared packages. :-/

[Drak]

Amy,

I think this is confusing. API Commons is providing a licensing framework so it makes clear that APIs are not restricted by copyright - remember Oracle tried to sue Google because Android used the same interface names as some Java stuff they owned? And it also provides a way to machine read certain metadata about the API.

This is quite different to what you have proposed. I see Phil just posted something to that effect so I wont repeat that, but he pretty much "took the words out of my fingers" :)

Drak

--

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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/dafbd32a-27a4-4882-b3cd-3edd3efa6770%40googlegroups.com.

[Amy Stephen]

On Monday, November 11, 2013 11:24:17 AM UTC-6, Drak wrote:

Amy,

I think this is confusing. API Commons is providing a licensing framework so it makes clear that APIs are not restricted by copyright - remember Oracle tried to sue Google because Android used the same interface names as some Java stuff they owned? And it also provides a way to machine read certain metadata about the API.

Please take time to read the article. The second paragraph gets into the legal issues surrounding the Oracle vs Google ruling.
 

This is quite different to what you have proposed. I see Phil just posted something to that effect so I wont repeat that, but he pretty much "took the words out of my fingers" :)

Please (Phil and Drak) take time to review my second post where I describe a means of approving and listing Interfaces so that "matches" can be aligned for exactly the reasons of crowd source collaboration given in the article.
 

Drak

Thanks again to the two of you for your responses and feedback. =)
 

[David Négrier]

Just read today the whole thread, sorry for replying late.

Although Amy's proposal has received quite some criticism, I think she has a point: it is tremendously hard to have a PSR passed (more than 1 year of discussion for the PSR-Cache...)

It might be easier to start coding first, and try to reach consensus after a few projects have adopted a common interface.
This was also the point of Fabien Potencier and the reason why he left this group (https://groups.google.com/forum/#!msg/php-fig/b6UxDiug_jA/Gq9PiA_bQhwJ)

In that sense, we would only need to define a common namespace for shared APIs that have not yet a voted PSR status (anything from a test API to a draft PSR).

For instance:
Api\Mail\MailServiceInterface
Api\Cache\CacheServiceInterface
Api\DI\ContainerInterface
...

This way, a number of projects can start sharing common interfaces BEFORE a valid PSR is passed (they are not hindered by the FIG group)
And the fact that the interface is already used by many projects should be one of the obvious reasons to consider it for a PSR.

Finally, it is easy for projects to migrate to the PSR namespace when PSR validation is granted without breaking previous code.
You just have to extend the PSR interface.
Consider this sample:

// When the Api\DI\ContainerInterface becomes a PSR interface, you just need to replace the old interface file with this file.
// No breaks in compatibility!
interface Api\DI\ContainerInterface extends PSR\DI\ContainerInterface { }

Actually, I believe we don't have to define the second namespace level (actually, I even believe we should not do it to allow competing interfaces to live in different namespaces)

All we need is a common vendor name. "Api", as suggested by Amy, or "Interop" would be nice.

What do you think?

David

[Amy Stephen]

Thank you, David.

Regardless of what happens here, I'm going to move forward sharing my API's for Interfaces, also try to get common approaches to Exceptions, to see if there is any interest in crowd source collaboration. I also have data models I plan to share and an approach to data dictionaries and element definitions.

I obviously see the value in this but it doesn't have to be through FIG. I proposed it here after a Twitter discussion and recommendation from another member of FIG that it might fit this initiative.

I'm organizing my repo, when it's ready, I'll share it.

Thanks, again.

[Phil Sturgeon]

I think its fair to say that many of us in the FIG (including Fabien) believe:

1. Interoperability is best developed between existing projects. 
2. Trying to create a PSR purely from theory is damaging. See 1. 

I do not see how coming up with a list of names is the solution to getting the PHP community to work together on these issues, and Fabiens point was only tenuously connected to this.

I would suggest a list of API's could be made and blogged, or put on PHP The Right Way as suggestions for package names, then we just wait for the community to make stuff. After they have made stuff we then have lots of different implementations (which may or may not share some rough vendor names). At this point it would be an idea to shout at those devs to try and come up with a shared interface, then we have ourselves part of a working group for a new PSR.

When that happens they would still be making a PSR just as we are now, but for any of that to happen we need all of these factors to be true:

• Developers know about this list of names for their classes
• The implementations are not drastically different other than their name (<-- clanger)
• The developers care about interoperability
• The developers are willing (and able) to be part of a working group
• They can find a sponsor for it within the FIG

I mean, coming up with suggestions is not a bad idea, but it does not create any solutions that do not already exist and does not solve any of the issues that Fabien had, other than implementations have to exist before trying to make a PSR - which most people in this group agree with anyway.

So... what? :)

[Amy Stephen]

On Wednesday, November 20, 2013 11:02:08 AM UTC-6, David Négrier wrote:

This was also the point of Fabien Potencier and the reason why he left this group (https://groups.google.com/forum/#!msg/php-fig/b6UxDiug_jA/Gq9PiA_bQhwJ)

Re-read Fabien's post, agree with David that this type of initiative should help support and encourage inter-project collaboration at a more organic level. David - I like your example - that's just how I see solutions bubble up to the top. The Extends reference you provided is useful to encourage involvement, too.

 
All we need is a common vendor name. "Api", as suggested by Amy, or "Interop" would be nice.

Had to think about this, but I agree. I think it would (should) organically manifest at the second node.

I have started preparing my Interfaces for sharing in this manner. As I started doing so, I realized we also need a high-level for Exceptions since Interfaces define Exceptions. Soon, I'm going to go through all of my Exceptions and model them after SPL Exceptions, and then use those values in my Interfaces with the "vendor-name" node of Exception.

Although my work is not complete, these are the Interfaces I plan to share.

• Authorisation
• Cache
• Controller
• Database
• Email
• Event
• Fieldhandler
• Filesystem
• Http
• IoC
• Language
• Log - Covered by PSR
• Model
• Render
• Resources
• Route

 

Phil - I definitely plan to share these in a blog post. PHP - The Right Way is another good resource. Appreciate those recommendations.

Personally, I still see laying out a couple of shared "vendor name" nodes and a way to exchange Interfaces as helping to drive towards shared code. If FIG is interested, cool, if not, I'm still planning on sharing mine in this way and using "Api" and "Exception."  The way I look at it, it certainly would not hurt to encourage collaboration in this way to see if it helps light a spark.

Thanks!

[Beau Simensen]

On Wednesday, November 20, 2013 8:56:27 PM UTC-6, Amy Stephen wrote:

Although my work is not complete, these are the Interfaces I plan to share.

• Authorisation
• Cache
• Controller
• Database
• Email
• Event
• Fieldhandler
• Filesystem
• Http
• IoC
• Language
• Log - Covered by PSR
• Model
• Render
• Resources
• Route

I've kept quiet on this subject because I haven't been 100% certain I "get it." I've had ideas and thoughts on it (mostly reservations) but until I clicked through to this code I wasn't really sure I understood. I think I do now and I think my reservations stand.

Using something like a shared "Api" root namespace with common second level names removes vendors from the equation entirely. My first thought when I heard about this was, "won't this lead to massive conflicts?" So I assumed I was misunderstanding. Based on this code, I don't think that I was... Just one example: 

https://github.com/Molajo/Standard/blob/master/Vendor/Molajo/Cache/Api/CacheInterface.php

If we promote this idea, there is nothing to stop two separate vendors from creating Api\Cache\CacheInterface interfaces. If they are not identical, won't this be very bad? Won't we have separate packages distributing the same interface with different proposed implementations?

This means if I want Api\Cache\CacheInterface, and I know that stash/stash provides it, I can require Stash to get the interface I want. If some other dependency of mine uses acme/cache that also provides Api\Cache\CacheInterface, chaos will ensue as one of the packages is going to break since although they are both using the Api\Cache\CacheInterface name, they will most likely have incompatible definitions.

I might still be missing something, but seeing this in code sort of solidified my understanding of what is being discussed here and I really don't like it.

Have I missed something?

[Phil Sturgeon]

Yeah this turns what I thought originally was just a bad idea into a really bad idea. 

Amy: API is not a vendor name. 

[Amy Stephen]

On Thursday, November 21, 2013 9:53:47 AM UTC-6, Beau Simensen wrote:

Using something like a shared "Api" root namespace with common second level names removes vendors from the equation entirely. My first thought when I heard about this was, "won't this lead to massive conflicts?" So I assumed I was misunderstanding. Based on this code, I don't think that I was... Just one example: 

https://github.com/Molajo/Standard/blob/master/Vendor/Molajo/Cache/Api/CacheInterface.php

If we promote this idea, there is nothing to stop two separate vendors from creating Api\Cache\CacheInterface interfaces. If they are not identical, won't this be very bad? Won't we have separate packages distributing the same interface with different proposed implementations?

Yes, in fact, that would be the hope. The idea is to identify conflicts and encourage developers to work together towards common API's.

Using a shared namespace like "Api" for our Interfaces removes our "brand" and encourages collaboration.

Said differently, what enables us to share Interfaces now? (Except for the Log Interface where we have a PSR?) There really is no packaging for it, the Interface comes in a package with concrete classes. So, if I want to use common Interfaces, I have to manually pull them out of other packages and I likely have to manually pull the Exception classes, as well.

Doing that is forking the package and I have no way of knowing about change. The branding is coming from someone else which (like it or not) creates a disincentive for some.

In some cases, you want namespaces to separate work (which is what you are describing).

But, in this case, the idea would be to use namespaces to empower those developers who are interested in helping drive towards software commodization and common API's to have a way to do it. Today, that's just not easy to do.

[Jason Judge]

On Thursday, 21 November 2013 02:56:27 UTC, Amy Stephen wrote:

• Authorisation
• Cache
• Controller
• Database
• Email
• Event
• Fieldhandler
• Filesystem
• Http
• IoC
• Language
• Log - Covered by PSR
• Model
• Render
• Resources
• Route

...

Personally, I still see laying out a couple of shared "vendor name" nodes and a way to exchange Interfaces as helping to drive towards shared code. If FIG is interested, cool, if not, I'm still planning on sharing mine in this way and using "Api" and "Exception."  The way I look at it, it certainly would not hurt to encourage collaboration in this way to see if it helps light a spark.

Sure, share these and see what ideas come of them. I'm not sure what the best type of forum would be to do that, but I don't think a message list is the way - it is too linear. I think what you should be looking for is feedback, ideas, experiences, and then to see what happens as this approach is explored - the benefits, the pitfalls, and other ideas that are just not apparent to us now.

However, what I see posted here looks like an attempt to write twenty new PSRs all at once, starting with the interfaces. I just don't think that is what the FIG is aiming to do. Shared interfaces like this would need to be so broad, i.e. so open and essentially empty, so they cater for implementations that have not been explored, that they would not be much use as a recommendation.

Perhaps what could be done is to not try and define these shared interfaces, but to collect together what we know about interfaces under these categories in a variety of projects. That would provide some good data, and a forum for debate on what the pros and cons, differences and similarities are of each one. The interfaces as they are, lock things down to a single implementation, and calling them "shared" is not something that I think is useful. What you have shared is just one implementation of the interfaces, using a bunch of vendors that are not real vendors.

Yes, there is something of use in this proposal, but not leaping into trying to standardise common interfaces.

-- Jason

[Beau Simensen]

TL;DR:

I think that if there was a global registry somewhere for the Api namespace that might be interesting. But it would need to be controlled and managed. Maybe not exactly like FIG, but I think that there should be a source for the API namespace and there should be a gatekeeper and code with the same name should only be available via one package and not distributed by disparate vendors.

I feel like that is more what the API Commons was about (as it relates to Amy's idea), but maybe I'm reading it wrong. It isn't so much, "here, go do something int he name of API commons and collaboration will happen!" as it is, "here, come work on these common API's and collaborate with us!"

On Thursday, November 21, 2013 7:35:08 PM UTC-6, Amy Stephen wrote:

If we promote this idea, there is nothing to stop two separate vendors from creating Api\Cache\CacheInterface interfaces. If they are not identical, won't this be very bad? Won't we have separate packages distributing the same interface with different proposed implementations?

Yes, in fact, that would be the hope. The idea is to identify conflicts and encourage developers to work together towards common API's.

People in FIG have a vested interest in interoperability and it still takes months and years to shake out a common API. With no oversight whatsoever on who can publish code under the Api namespace I don't think we could safely assume that there would be eventual consensus between random people ever, much less quickly enough to avoid end-user headaches due to multiple packages providing and relying on the same interface with different proposed implementations.

 

Said differently, what enables us to share Interfaces now? (Except for the Log Interface where we have a PSR?) There really is no packaging for it, the Interface comes in a package with concrete classes. So, if I want to use common Interfaces, I have to manually pull them out of other packages and I likely have to manually pull the Exception classes, as well. 

There are other ways to do this than to just say, "put all your interfaces under the Api namespace." For example, Symfony and Silex are both considering creating an "API" package that consists primarily of interfaces (not sure about exceptions). This would allow someone to install just the interfaces without any implementations.

We've always been able to share interfaces but people just don't often do that. Maybe helping people understand why this is important and providing some tools or guidelines on what to share would be better than telling them under which namespace they should put their interfaces?

In some cases, you want namespaces to separate work (which is what you are describing).

But, in this case, the idea would be to use namespaces to empower those developers who are interested in helping drive towards software commodization and common API's to have a way to do it. Today, that's just not easy to do.

I think that the idea here is positive but I think that in practice it would not work very well. You'd have to have an organization built around this common API concept and someone (or some group of people) would have to ultimately decide which patches would be allowed against the set of common interfaces. This is already hard to do in FIG with just a limited set of proposed interfaces (cache, http, http messages) so I can't imagine how difficult this would be on a large scale.

As far as each individual developer (like you with Molajo) distributing the interfaces yourself without a vendor, you're asking for trouble. This is more or less the same thing as a top level non-namespaced User class. You can say it is about collaboration, but as soon as you try mixing two libraries that have two separate implementations against different interfaces with the same name everything falls apart. Hard. What then?

You can say that this will lead to collaboration because now you'll have to work together to make sure your interfaces are the same. That might be fine if it is your interface vs some 3rd party interface. But if you're neither (say you're using two libraries that each have different Api\Cache\CacheInterface proposed implementations) now you have to get involved with both vendors and say, "hey! can you guys play nicely and make your interfaces exactly the same so I can use both of your libraries?"

Assuming both play ball, awesome. But this might take some time. Depending on the size of their packages it might have far reaching impact on their codebase so neither may actually want to budge. "We were here first, match our API" or "We have too many users and you're brand new, match our API," will no doubt happen if the community is in charge of managing what gets put into the API namespace on a package by package basis.

I don't want to sound too negative here, because I like the heavy focus on the spirit of cooperation. I just can't shake the scared feeling I get when I consider people starting to intentionally release code under Api\[Something] namespace, without a vendor, with no oversight, and the idea actually taking off.

If it is just Amy putting stuff under Api, awesome. But as soon as someone else does it, trouble will soon follow. I'm not looking forward at all to the day that I end up using two dependencies that would otherwise work except they both decided to create Api\Container\ContainerInterface with different proposed implementations.

That they might someday have the same interface is a nice thing to hope for but it will be of little comfort to me when I'm trying to figure out why my code doesn't work.

However, what I see posted here looks like an attempt to write twenty new PSRs all at once, starting with the interfaces. I just don't think that is what the FIG is aiming to do. Shared interfaces like this would need to be so broad, i.e. so open and essentially empty, so they cater for implementations that have not been explored, that they would not be much use as a recommendation.

I get this feeling, too. These look like future potential PSRs. I don't agree that this isn't what FIG is aiming to do, though. :) Some of them are out of scope, but given enough time (many many years) I can see FIG eventually trying to tackle a chunk of these.

[Amy Stephen]

Thanks Beau and Jason.

The list that I linked is code I have written this past couple of years and it is part of Molajo. This is not "an attempt to write twenty new PSRs all at once." I've not even recommended they be used as PSR's.

I do want to share them if others find them useful. It's good to hear that Symfony plans to uncouple their Interfaces and distribute separately, too. That serves to reinforce David's observation of parallels between the ideas proposed here with Fabien's leaving of FIG and promotion of interproject collaboration.

I agree, Beau, that FIG will take "many many years" to "tackle a chunk of these" -- but that's a long time. If the community can be trusted to work out all of the issues and problems you are predicting (problems that will indeed manifest) - then what I see could happen is that a climate for collaboration, organic means of coming to agreement on common API's, would be supported by broad implementation, and those solutions that bubble to the top could then be refined by FIG and adopted into PSR form.

Sounds like already Symfony, Silex, and Molajo are positioning to offer interfaces. It's certainly not hard to imagine more projects will see the value and do the same. The question is can FIG leverage this community energy and product into a collaborative form in order to further the goal of interoperability? If the answer is "No - FIG must do it, themselves." that's fine. But my sense is (and my hope is) this organic collaboration will happen anyway.

To your point, Beau, will it be messy? Confusing? Absolutely. Disruptive innovation is like that.

[Larry Garfield]

I had similar reservations to Beau, and it sounds like those
reservations are still valid. :-) Perhaps a more concrete example would
be useful.

Scenario: Suppose Drupal has a nifty Queue system and interface we think
is really good. (Side note: We do.) We want to make it easier for Cake
PHP to leverage it, too.

Amy, I believe in the world you're describing we'd have:

\Api\Queue\QueueInterface
\Drupal\Queue\QueueImplementation implements \Api\Queue\QueueInterface

And then Cake could pull in just Drupal's \Api\Queue\QueueInterface
(which we'd do as some sort of subtree split to make it available?) and
write its own backend for it (or not).

Problem: Laravel also makes a queue service, calls it
\Api\Queue\QueueInterface but with different methods. Now Cake can't
use Solarium (which uses the Drupal queue interface) and Elastica (which
uses the Laravel queue interface) at the same time. Sad panda.

So that's effectively undoing namespaces. I don't see how that would
promote collaboration; we used to have that back in 5.2. We weren't
collaborating then, except for killing off PHP 4. :-)

What Beau says Symfony/Silex are talking about doing would, in this
scenario, be:

\Drupal\Api\Queue\QueueInterface
\Drupal\Queue\QueueInterface implements \Drupal\Api\Queue\QueueInterface

and then do the same subtree split stuff as before. Then Cake could use
Solarium, which depends on \Drupal\Api\Queue\QueueInterface, and get
JUST the interface and not the default implementation that uses Drupal's
DB library as a cheap queue alternative (because really, who wants that
POS?). But, it could also use Elastica which is using
\Laravel\Api\Queue\QueueInterface, and so there's now 2 different but
not-fataling interfaces floating around but no unused classes, from
either Drupal or Laravel.

It does seem like the second scenario is more useful for Cake.

(Note: I have no idea why Solarium or Elastica would be using a queue
server. I'm just making up a scenario with real names to make it easier
to discuss.)

Recommending that projects separate off "sharable interfaces" to an
easy-to-subtree-split namespace that contains just interfaces is an
interesting idea. It's probably not something that would turn into a
PSR, but still worth discussing. (Note: "Not a PSR" does *not* equal
"Not FIG's business". We can totally talk about things that are not
PSRs. PSRs are just one way to encourage interoperability.)

--Larry Garfield

> --
> 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+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/b47ce605-f900-4e20-94ae-a7947cc8e8b1%40googlegroups.com.

[Amy Stephen]

Understood. But, you guys are describing a system that prevents collusion, not one that promotes and enables collaboration.

Namespaces, through the implementation of the vendor prefix, ensures a lack of collusion -- and that mechanism is available for those who aren't looking to collaborate in this manner. I'm not suggesting that change. It enables sharing of software without namespace collusion.

What's missing is a common namespace that doesn't have a brand where Interfaces can be shared with those devs who want to collaborate and do so in a way that promotes interoperability of component-level software. If I want to use Project X's Interface today, I have to manually extract it from the concrete classes it's packaged. Manually check back and see if Project X made changes to the Interface. And, package their Interface with their namespace in my package. 

The point is -- there is no enabling mechanism, no "unbranded vendor prefix", no packaging approach, for those who want to work on common Interfaces and APIs.

I went ahead and extracted my Interfaces from Molajo, put them into a CommonApi repository and packaged them by subsystem. I'll add some documentation and basic unit testing and see if others are interested. We really are missing the ability to work together in this manner. Maybe there are other ideas for how to remove those barriers without having to trust developers to work things out?

Anyway, it's clear this isn't an idea that FIG supports. In time, maybe someone will have an idea for how to support this type of peer-to-peer collaboration.

Appreciate the feedback.

[Jason Judge]

On Wednesday, 27 November 2013 07:18:13 UTC, Amy Stephen wrote:

Understood. But, you guys are describing a system that prevents collusion, not one that promotes and enables collaboration.

Namespaces, through the implementation of the vendor prefix, ensures a lack of collusion -- and that mechanism is available for those who aren't looking to collaborate in this manner. I'm not suggesting that change. It enables sharing of software without namespace collusion.

What's missing is a common namespace that doesn't have a brand where Interfaces can be shared with those devs who want to collaborate and do so in a way that promotes interoperability of component-level software. If I want to use Project X's Interface today, I have to manually extract it from the concrete classes it's packaged. Manually check back and see if Project X made changes to the Interface. And, package their Interface with their namespace in my package. 

The point is -- there is no enabling mechanism, no "unbranded vendor prefix", no packaging approach, for those who want to work on common Interfaces and APIs.

I went ahead and extracted my Interfaces from Molajo, put them into a CommonApi repository and packaged them by subsystem. I'll add some documentation and basic unit testing and see if others are interested. We really are missing the ability to work together in this manner. Maybe there are other ideas for how to remove those barriers without having to trust developers to work things out?

Anyway, it's clear this isn't an idea that FIG supports. In time, maybe someone will have an idea for how to support this type of peer-to-peer collaboration.

Is it really that clear? The proposal itself is still pretty unclear to me - can't talk for other's understanding. You have some "shared/unbranded" vendor namespaces that are not owned by a specific vendor, and that kind of leads to peer-to-peer collaboration in a way that is not at all clear to me. All I can see are clashing interfaces that are either specific enough that they won't meet all projects needs, or open enough that they won't serve any real purpose.

Do you have an example story of how a collaborative decision or action would play out? How would you see everyone coming together and making something that can be shared and improved in the process (which I am assuming is what the collaboration aims to do).

Explain to me like I'm five, because I just don't get it. And it could well just be me.
 

Appreciate the feedback.

On the whole, I believe the idea of vendors in the namespace is good. It is not so much about branding, as it is about some person or organisation declaring ownership. That vendor is the driver, the maintainer and the ultimate decision maker. How "shared" any of those aspects are, is down to the vendor. Those that people like will get support and get used, and when they are no longer flavour of the month, will be forked and taken in other directions. But the point is, collaboration happens there now, and where it doesn't, people move on as there are lots of alternatives and choices.

[Beau Simensen]

On Wednesday, November 27, 2013 1:18:13 AM UTC-6, Amy Stephen wrote:

I went ahead and extracted my Interfaces from Molajo, put them into a CommonApi repository and packaged them by subsystem. I'll add some documentation and basic unit testing and see if others are interested.

What you've done here looks a lot like one of the things I proposed as a way I could see this maybe working. You've effectively taken over CommonApi as a vendor namespace. You, and whomever else you grant merge access to for the CommonApi organization, are the gatekeepers controlling what goes into the common API. As long as the organization ( https://github.com/CommonApi ) is the only group actively releasing packages (interface-only packages or otherwise) under the CommonApi namespace, I think this is fine.

If your goal is to encourage other developers to release their own versions of the interfaces under the CommonApi vendor namespace ( say, dflydev could release its own version of CommonApi\IoC\ContainerInterface that conflicts with https://github.com/CommonApi/IoC/blob/master/ContainerInterface.php ) then I think this is a bad idea and it will be harmful to the community. I used some fairly abstract examples but I think that Larry did a great job of fabricating a concrete example of how this will end poorly for people if the CommonApi namespace is a free for all.

I really felt like you were proposing the free for all approach but since you've created the CommonApi organization maybe I misunderstood and never intended people to release their own versions of the interfaces and always had in mind some sort of controlling organization or body to shepherd the process.

We really are missing the ability to work together in this manner. Maybe there are other ideas for how to remove those barriers without having to trust developers to work things out?

...

Anyway, it's clear this isn't an idea that FIG supports. In time, maybe someone will have an idea for how to support this type of peer-to-peer collaboration.

I don't know. I feel like this is what FIG is doing with the Psr namespace. The biggest differences seem to be in who the gatekeeper is. For the Psr namespace, it is FIG. For the CommonApi namespace, it is either anyone/everyone or the CommonApi organization. It isn't clear to me which you intend.

[Amy Stephen]

Jason -- It sounds like you understand the concept, but don't trust an organic, collaborative process to work out the collision issues. Personally, I believe developers looking to collaborate in this area can use a shared namespace for this purpose and they would resolve collisions without oversight. I don't see a cognitive problem that would require explaining it to a five year old, but rather a difference of opinion on how it might or might not play out.

Beau - I hear your concerns (and the concerns of others, above) about name collision. Again, that's why we have the vendor name. Anyone who wants to freely create names without concern about collision can use that approach. I am not recommend any changes to that practice. What's missing is a way to collaborate in a shared namespace. I want to have my Interfaces available for reuse and collaboration. The approach I used is about as close as I can get to my goal.
 

[Jason Judge]

On Wednesday, 27 November 2013 16:12:02 UTC, Amy Stephen wrote:

Jason -- It sounds like you understand the concept, but don't trust an organic, collaborative process to work out the collision issues. Personally, I believe developers looking to collaborate in this area can use a shared namespace for this purpose and they would resolve collisions without oversight. I don't see a cognitive problem that would require explaining it to a five year old, but rather a difference of opinion on how it might or might not play out.

Nothing to do with trust. I just don't understand the mechanism. There are a lot of loaded words: organic, collaborative, oversight - what do you mean by these things. It's ambiguous. I am not trying to argue against this, or pushing an alternative opinion. I *really* do not understand how this proposal would work, and what its expected or desired outcomes are.

What I have seen is people jump in with their own interpretation of what your proposal means, and come to conclusions on how it would work in practices given their assumptions about what it means. Maybe my head is too stuck in the nuts and bolts of coding, and that's why I just don't get it. It's probably just me, so I'll just shut up now and let you get on with it.

[Amy Stephen]

On Wednesday, November 27, 2013 10:36:55 AM UTC-6, Jason Judge wrote:

On Wednesday, 27 November 2013 16:12:02 UTC, Amy Stephen wrote:

Jason -- It sounds like you understand the concept, but don't trust an organic, collaborative process to work out the collision issues. Personally, I believe developers looking to collaborate in this area can use a shared namespace for this purpose and they would resolve collisions without oversight. I don't see a cognitive problem that would require explaining it to a five year old, but rather a difference of opinion on how it might or might not play out.

Nothing to do with trust. I just don't understand the mechanism. There are a lot of loaded words: organic, collaborative, oversight - what do you mean by these things. It's ambiguous. I am not trying to argue against this, or pushing an alternative opinion. I *really* do not understand how this proposal would work, and what its expected or desired outcomes are.

Right, but I don't know how to answer your question except to continue to repeat what has been said. It's a simple concept -- define a high level vendor name (ex. "Api") that developers are encouraged to use for Interfaces that they are willing to share and work towards common definitions. This post attempted to explain a possible process around the use of a common namespace that could help "advertise" usage and drive collaboration. If you have specific questions about that post, I'm happy to respond.

Overall, given the responses from several people on this topic, I'm not seeing a lack of understanding for the proposal but rather a difference of opinion on the namespace collusion this approach might (and would) create. Some believe it could enable collaboration and, as such, is worth exploring. Others are focused on the lack of authority to assist with namespace collusion.

The basic take away I hope everyone has is that we are missing a way to easily share Interfaces today. That's a packaging issue. It's a namespace issue. And, it's an oversight issue. PSR's help solve that problem but the process is slow. Today, there is one solution for Logs. There might soon be a solution for Cache from FIG. But, there is no easy way to enable this collaboration in the broader PHP community at this time. Food for thought.

[Paul M. Jones]

On Nov 27, 2013, at 11:37 AM, Amy Stephen <amyst...@gmail.com> wrote:

> It's a simple concept -- define a high level vendor name (ex. "Api") that developers are encouraged to use for Interfaces that they are willing to share and work towards common definitions.

If you want to pursue this, I assert that the top-level vendor name needs to be something a lot more specific than "Api" or "CommonApi" or anything that carries even a whiff of being generic. I am not pro or con at this point, but a generic name is asking for trouble.


--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com

[Amy Stephen]

On Wednesday, November 27, 2013 12:17:27 PM UTC-6, pmjones wrote:

On Nov 27, 2013, at 11:37 AM, Amy Stephen <amyst...@gmail.com> wrote:

> It's a simple concept -- define a high level vendor name (ex. "Api") that developers are encouraged to use for Interfaces that they are willing to share and work towards common definitions.

If you want to pursue this, I assert that the top-level vendor name needs to be something a lot more specific than "Api" or "CommonApi" or anything that carries even a whiff of being generic.  I am not pro or con at this point, but a generic name is asking for trouble.

Paul -

For clarification, do you mean more like what I originally suggested -- two levels to help provide a little structure? If not, would you please explain a bit more on your point?

Thanks!

 

On Wednesday, November 6, 2013 4:37:27 PM UTC-6, Amy Stephen wrote:

Examples of two level namespace prefixes that could be added to and maintained on the Wiki:

• Api\Authorisation
• Api\Cache
• Api\Controller
• Api\Database
• Api\Email
• Api\Event
• Api\Filesystem
• Api\Http
• Api\IoCC
• Api\Language
• Api\Log
• Api\Model
• Api\Route
• Api\Render
• Api\User

[Paul M. Jones]

On Nov 27, 2013, at 1:32 PM, Amy Stephen <amyst...@gmail.com> wrote:

>
>
> On Wednesday, November 27, 2013 12:17:27 PM UTC-6, pmjones wrote:
>
> On Nov 27, 2013, at 11:37 AM, Amy Stephen <amyst...@gmail.com> wrote:
>
> > It's a simple concept -- define a high level vendor name (ex. "Api") that developers are encouraged to use for Interfaces that they are willing to share and work towards common definitions.
>
> If you want to pursue this, I assert that the top-level vendor name needs to be something a lot more specific than "Api" or "CommonApi" or anything that carries even a whiff of being generic. I am not pro or con at this point, but a generic name is asking for trouble.
>
> Paul -
>
> For clarification, do you mean more like what I originally suggested -- two levels to help provide a little structure? If not, would you please explain a bit more on your point?

I mean that the top-level vendor name should not be generic in any way. DO what you like beneath that, but the top-level name needs to be something very non-generic. "AmysInterfaces" or something like that, not merely "Api", "CommonApi", "SharedStandards", etc.

[Amy Stephen]

You mean me, personally? If so, I would just kept them Molajo. Kind of defeats the purpose of creating a non-branded vendor name that can be shared by multiple developers to make it a brand. =)

I thought you meant for FIG.

Thanks for the clarification.

[justin]

On Wed, Nov 27, 2013 at 2:18 PM, Amy Stephen <amyst...@gmail.com> wrote:

I mean that the top-level vendor name should not be generic in any way.  DO what you like beneath that, but the top-level name needs to be something very non-generic.  "AmysInterfaces" or something like that, not merely "Api", "CommonApi", "SharedStandards", etc.

You mean me, personally? If so, I would just kept them Molajo. Kind of defeats the purpose of creating a non-branded vendor name that can be shared by multiple developers to make it a brand. =)

Something like FriendsOfSymfony would probably be ideal. It's "branded", but branded as something shared, if that makes sense:

http://friendsofsymfony.github.io

That's an organic example of exactly the sort of collaboration you're looking to foster, but focused on Symfony bundles rather than on common interfaces.

--justin

[Amy Stephen]

Thanks, Justin. Yes, that's a very good example of an organic group of developers share code around a common theme, in this case, with a focus on Symfony. 

Is it possible something like that could be beneficial with FIG? Like a "FriendsofFIG" concept with a repository where developers could collaborate around common, shared interfaces and FIG provides oversight somewhat limited, but at least to the extent needed to ensure no name conflicts?

Would that strike the right balance to enable cooperative, organic cooperation without collusion?

If so, I'd be happy to help with that and/or to "turn over" what I have started. That might help build a little involvement with the broader PHP community and provide good base definitions that could then be refined by FIG for use as PSR's.

Thoughts?

--justin

[Amy Stephen]

On Wednesday, November 27, 2013 5:33:17 PM UTC-6, Amy Stephen wrote:

Would that strike the right balance to enable cooperative, organic cooperation without collusion?

Collusion and collision are the almost exactly the same thing, right???? ;-P

Apologies for the word choice/spelling error/mistake.

[Paul M. Jones]

It's an example. Again, I opine that having a *generic-sounding name* of any sort is a bad plan.

[Amy Stephen]

Just to be clear, I'm not recommending anything a name for FIG, should FIG choose to champion such a cause.

[Matthieu Napoli]

Hi Amy,

I think this idea is interesting. David Négrier and I have been discussing lately (here and there) regarding a PSR for Dependency Injection Containers, especially a ContainerInterface. That interface would allow a first form of interoperability between containers.

However, I agree with the general consensus that there is no point building a standard on something that doesn't already exists and that we have experience with. So the first step would be to test such an interface (or several interfaces?) in the wild, and see if it solves the problem and should be made into a PSR.

So what David and I thought was very close to what you suggest, limited to container interfaces. So hey, we could work together!

However, there are things that I'm not really sure about what you started:

- you have already created loads of sub-projects (IoC, controllers, Http, Cache, …) with code. I thought there was going to be discussions, and iterations before ending up with interfaces. The subjects are so different from one another I think it would be best to start from 0 projects, 0 code, and create them when enough people show interest and can agree on something.

- for example, right now I don't agree on the IoC interfaces and I would love to discuss all this and understand how it ended up the way it is, and maybe change it.

- I also think those projects should start in "beta" version, because coming up from start with a 1.0 "stable" version means we can already start a PSR. It also sends the message that this is stable, good and bulletproof. Which is not, unless I don't see it the way you do. Maybe they should even be only non-stable versions. Because what's the goal of all this, if not testing and iteratively build interfaces until we feel confident we can take it to a PSR?

Anyway, that's a good thing you started, I hope we can lead it somewhere.

Matthieu

Le mercredi 6 novembre 2013 23:37:27 UTC+1, Amy Stephen a écrit :

I'd like to gauge interest in a simple PSR for a simple, two-level shared namespace for Interfaces. (This approach is supported by PSR-4 -- meaning it fits the rules and should work with a compatible autoloader).

My thinking is in offering a small amount of structure (two-levels) and a shared namespace (examples below), it could help encourage organic collaboration in the PHP community between willing projects where it does not require as much discussion and collaboration as a PSR.

Many projects have fantastic full sets of Interfaces which have untapped potential driving interoperability.  Over time, these independent efforts would likely to gain support and become a defacto standard that might (or might not) gain official sign-off as a PSR and then use the PSR namespace.

Over the years, in observing open source communities, it seems a little structure, a lot of freedom, and recognition for work well done, lead to innovation. I have found myself thinking about how FIG might build some energy and involvement around its important mission and introduce those opportunities for the broader PHP community to collaborate along common goals.

Towards that end, I offer this idea for your consideration.

[Amy Stephen]

On Friday, November 29, 2013 5:00:36 AM UTC-6, Matthieu Napoli wrote:

Hi Amy,

I think this idea is interesting. David Négrier and I have been discussing lately (here and there) regarding a PSR for Dependency Injection Containers, especially a ContainerInterface. That interface would allow a first form of interoperability between containers.

However, I agree with the general consensus that there is no point building a standard on something that doesn't already exists and that we have experience with. So the first step would be to test such an interface (or several interfaces?) in the wild, and see if it solves the problem and should be made into a PSR.

So what David and I thought was very close to what you suggest, limited to container interfaces. So hey, we could work together!

However, there are things that I'm not really sure about what you started:

- you have already created loads of sub-projects (IoC, controllers, Http, Cache, …) with code. I thought there was going to be discussions, and iterations before ending up with interfaces. The subjects are so different from one another I think it would be best to start from 0 projects, 0 code, and create them when enough people show interest and can agree on something.

- for example, right now I don't agree on the IoC interfaces and I would love to discuss all this and understand how it ended up the way it is, and maybe change it.

- I also think those projects should start in "beta" version, because coming up from start with a 1.0 "stable" version means we can already start a PSR. It also sends the message that this is stable, good and bulletproof. Which is not, unless I don't see it the way you do. Maybe they should even be only non-stable versions. Because what's the goal of all this, if not testing and iteratively build interfaces until we feel confident we can take it to a PSR?

Anyway, that's a good thing you started, I hope we can lead it somewhere.

Matthieu

Cool. The packages are tagged v. 0.1.0 Alpha. I am most certainly open to change (in fact, that's kind of the point, to work with others towards common definitions). Be glad to add you for the IoC repository. I'll email you and we can discuss.

Thanks!

[Matthieu Napoli]

Cool. The packages are tagged v. 0.1.0 Alpha. I am most certainly open to change (in fact, that's kind of the point, to work with others towards common definitions). Be glad to add you for the IoC repository. I'll email you and we can discuss.

Indeed, I was fooled by the "@since 1.0"  in the code ;)