The need for a delineation between 'standards' and 'standard implementations'

[ezzatron]

Hi all

I've been watching some of the recent GitHub issues and pull requests and I have some concerns I'd like to share and discuss.

There have been several issues raised (#44, #24, #17, #11 in particular) that, in my opinion, do not belong in the FIG standards.

The issues in question all propose standard implementations rather than standards themselves. This is not a good thing.

One of PHP's problems is that its standard library suffers from bloat. These proposals are all, in fact, proposals for 'standard library'-type features. The fact that they will not end up in the actual PHP standard library makes little difference.

If anything, these proposals would make more sense if the FIG decided to create its own standard library. But when it comes down to it, especially considering the advent of Composer, why would anyone want another monolithic standard library? When would that ever be preferable to pulling in the exact libraries you need to accomplish your task?

Event systems, cache implementations, and HTTP clients would be much better solved as standalone libraries. You want everyone to adopt your implementation? Fine, make your implementation the best one available and everyone will use it.

Just my 2¢.

- Erin

[TechnoSophos]

To some extent I agree. I'd hate to see FIG turn into a tool for assigning legitimacy to certain projects merely by calling them "standard."

But there is a good reason -- and plenty of precedent -- for standardizing interfaces.

As a paramount example, I will suggest on of the standards that I think has been the most successful. The W3C has standardized the Document Object Model (DOM) essentially by dictating an interface that any DOM implementation must follow. This has been hugely successful:

* All major browsers support the majority of the DOM in their JavaScript implementations, and even in lower-level libraries.

* All major procedural/OO programming languages have a DOM implementation

* The vast majority of developers have at least some understanding of how to work with a DOM, be it for an XML configuration file or HTML web content.

This is immensely valuable.

Now, the FIG group stakes more modest territory: We're only working in PHP-specific standards. But there is something to aspire to here. Tasks such as working with HTTP are the bread-and-butter of PHP developers, yet each of us has to know many ways of working with HTTP. Sometimes we're using stream wrappers, and sometimes CURL libraries. Sometimes we use libraries built into a CMS (viz. Drupal) or a framework like Symfony. And sometimes we work with independent libraries like Guzzle.

Now, I don't think we need to dictate a particular *library*, but providing a standard Request/Response interface would certainly go a long way toward simplifying this. If there is a standard interface that each of us (again -- we here represent many frameworks and systems) can use as a basis for implementation, we've made the life of the developer easier.

I think that's exactly what a standards body should do.

There is, of course, a caveat: Choose your battles wisely. Standards are only going to be useful (and adopted) when they standardize ubiquitous (or at least common) needs. So the triaging of standards proposals should include an assessment of whether or not the proposed subject matter really needs a standard. The point at which a standard is more burdensome on developers than it is helpful is the point at which a standard is bad.

Matt Butcher

-- 

TechnoSophos

Blog: http://technosophos.com

Twitter: @technosophos

Sent with Sparrow

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/3L8uWDxy7BUJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Lukas Kahwe Smith]

On Aug 7, 2012, at 14:37, ezzatron wrote:

> Hi all
>
> I've been watching some of the recent GitHub issues and pull requests and I have some concerns I'd like to share and discuss.
>
> There have been several issues raised (#44, #24, #17, #11 in particular) that, in my opinion, do not belong in the FIG standards.
>
> The issues in question all propose standard implementations rather than standards themselves. This is not a good thing.

Agreed that FIG should only maintain "standards" and not implementations. However I think you are off base with saying at all the above noted issues attempt to get "implementations" published. They do talk about implementations because this is one way to ensure that the "standard" is actually real world compatible. Its also custom by many standards bodies to require a reference implementation and test suite.

> One of PHP's problems is that its standard library suffers from bloat. These proposals are all, in fact, proposals for 'standard library'-type features. The fact that they will not end up in the actual PHP standard library makes little difference.
>
> If anything, these proposals would make more sense if the FIG decided to create its own standard library. But when it comes down to it, especially considering the advent of Composer, why would anyone want another monolithic standard library? When would that ever be preferable to pulling in the exact libraries you need to accomplish your task?
>
> Event systems, cache implementations, and HTTP clients would be much better solved as standalone libraries. You want everyone to adopt your implementation? Fine, make your implementation the best one available and everyone will use it.

To me this sounds very ranty.

That being said, especially your last paragraph is all fine and dandy, but you fail to realize that by going with such an approach you create a hard binding between those libraries and the code using them unless its all based on an independent set of interfaces that make it easy to swap in other libraries.

While I agree that building higher level code from smaller decoupled libraries is an improvement over monolithic codebases, its not that much better if the net result is then a coupling onto these previously decoupled libraries.

regards,
Lukas Kahwe Smith
m...@pooteeweet.org

[Jelmer Schreuder]

I pretty much agree with ezzatron.

A lot of these examples suffer from implementation-by-interface. Especially the Cache proposal seems to want to implement about everything about the interface and leave very little up to the person implementing it. I think the right approach to most of these would be to define a small subset of the most fundamental parts of the interface and standarize those.

Another example I saw was the Request-Response proposals, which were combined while these should be separate proposals (related yes, mixed no).

If the goal really is interoperability many of those proposals could be declined out of hand because they want to standarize how things work. That part of should be left up to the creativity of the implementer. I don't think we want everything to work the same, we want things to be able to interface with eachother. Thus the standards set should be minimalistic and straight-forward, leaving not just the internals but also any advanced capabilities up to the lib implementing it.

(and as I just commented on the Event proposal, that's mostly duplicating SplSubject & SplObserver)

regards,

Jelmer Schreuder

FuelPHP

Op dinsdag 7 augustus 2012 17:02:19 UTC+2 schreef Lukas Smith het volgende:

[Lukas Kahwe Smith]

On Aug 8, 2012, at 11:31, Jelmer Schreuder wrote:

> If the goal really is interoperability many of those proposals could be declined out of hand because they want to standarize how things work. That part of should be left up to the creativity of the implementer. I don't think we want everything to work the same, we want things to be able to interface with eachother. Thus the standards set should be minimalistic and straight-forward, leaving not just the internals but also any advanced capabilities up to the lib implementing it.

I agree that we should not try to cover advanced functionality in the first proposal. Imho the sensible approach is to come up with interfaces that cover 80% of the use cases. Then later on in another proposal people can then look to build on top with more advanced functionality if there is a clear need.

This has several advantages:
- we do not create standards that are so hard to implement that only a few actually do
- we stay closer to real world needs
- we can much easier conclude discussions

Finally we still have a learning process to go through here to find the right balance between focusing on really just the interface (ie leaving the implementors as much room for creativity) but still ensuring that the interface is real world implementable and also actually covers enough to provide a benefit for a significant number of users.

[Erin Millard]

I'd like to make it clear that I'm not saying that a collaborative effort towards a well-thought-out HTTP client or other component is a bad idea. What I am saying is that a standards document is the wrong place for it. I'll attempt to clarify my thoughts on some points that have been raised.

 

As a paramount example, I will suggest on of the standards that I think has been the most successful. The W3C has standardized the Document Object Model (DOM) essentially by dictating an interface that any DOM implementation must follow. This has been hugely successful:

* All major browsers support the majority of the DOM in their JavaScript implementations, and even in lower-level libraries.

* All major procedural/OO programming languages have a DOM implementation

* The vast majority of developers have at least some understanding of how to work with a DOM, be it for an XML configuration file or HTML web content.

This is immensely valuable.

The difference in the case of the DOM is that the developer usually has no choice about the implementation they get. They have what they are provided by the browser and must make do.

This is completely different to the situation in PHP. There are no constraints on what libraries a developer can use for DOM traversal/manipulation in PHP, and you can tell, because most people end up using a library or hand-rolled system that abstracts the clunky default DOM implementation.

Now, I don't think we need to dictate a particular *library*, but providing a standard Request/Response interface would certainly go a long way toward simplifying this. If there is a standard interface that each of us (again -- we here represent many frameworks and systems) can use as a basis for implementation, we've made the life of the developer easier.

I think that's exactly what a standards body should do.

The point I'm trying to make, and I think it's still completely valid, is that this would make much more sense in the context of a standard library. As a specification of an API in a standards document, it is not going to help interoperability between libraries.

If you are creating an application in PHP that takes a HTTP request as a parameter, you may well want to accept any object that implements a well-defined HTTP request interface. That makes perfect sense. Your implementation can work with anything that produces a request implementing that interface.

But the key here is that it is an actual PHP interface. Therefore it is part of a library somewhere that must be included in your application. And this is an important point, because unless you want everyone to revert to ducktyping their HTTP request handling, your 'standard' HTTP request needs a standard implementation to be useful in any real-world sense.

I would almost certainly use a FIG standard HTTP library if it was really well designed, and vetted by the community. That does not mean that PSR-x should enforce architectural decisions upon developers by designing their interfaces for them.

So, I think the most appropriate course of action is to create a clear delineation between FIG standards and FIG standard libraries. That doesn't mean that the process of triage and discussion should go away - those are obviously very valuable. I'm suggesting that if FIG wants to create libraries then it needs to be segregated clearly, in both documentation, and in practice (repositories for libraries that are separate from the standards documents).

That being said, especially your last paragraph is all fine and dandy, but you fail to realize that by going with such an approach you create a hard binding between those libraries and the code using them unless its all based on an independent set of interfaces that make it easy to swap in other libraries.

To some degree this is correct; but implementing a set of interfaces in a library somewhere doesn't remove the problem of the dependency, it simply moves it somewhere else. As I said above, it does not belong in a standard, it belongs in a library.

What do you think of the idea of separating library proposals from standards proposals? How best could it be achieved?

[Jelmer Schreuder]

I think this has been partially talked about already, but it came down to standardizing a set of interfaces. I wouldn't call that a library in the functional sense, though maybe a library of interfaces. Which is part of what I think this group could/should be about.

As for offering default implementations: I'm very much opposed to that. It'll be a recipe for generating a civil war within this group. And with the collective development power of the projects collaborating here we should have multiple implementations to choose from in no time. Which is very much preferable to any attempts to get all these projects to start looking exactly alike at any level above basic library interfaces.

Thus my opinion is that the group shouldn't so much separate library proposals from standards, but should completely stay out of the library/implementation corner altogether.

Op woensdag 8 augustus 2012 14:07:18 UTC+2 schreef Erin Millard het volgende:

[Evert Pot]

On Aug 8, 2012, at 2:28 PM, Jelmer Schreuder wrote:

> I think this has been partially talked about already, but it came down to standardizing a set of interfaces. I wouldn't call that a library in the functional sense, though maybe a library of interfaces. Which is part of what I think this group could/should be about.
>
> As for offering default implementations: I'm very much opposed to that. It'll be a recipe for generating a civil war within this group. And with the collective development power of the projects collaborating here we should have multiple implementations to choose from in no time. Which is very much preferable to any attempts to get all these projects to start looking exactly alike at any level above basic library interfaces.
>
> Thus my opinion is that the group shouldn't so much separate library proposals from standards, but should completely stay out of the library/implementation corner altogether.

I think Erin is also implying that interface == implementation.

I strongly disagree with that notion though.

Evert

[ezzatron]

If you mean 'interface' as in an API defined in a spec and not an actual PHP interface, then no, that's not what I'm saying.

I'm saying that a standard that defines an API does nothing for interoperability. The only way you can design a library to accept any and all concrete implementations of a standard is to use duck-typing, which is very much inferior to a real PHP interface.

[Evert Pot]

On Aug 8, 2012, at 2:45 PM, ezzatron wrote:

> If you mean 'interface' as in an API defined in a spec and not an actual PHP interface, then no, that's not what I'm saying.
>
> I'm saying that a standard that defines an API does nothing for interoperability. The only way you can design a library to accept any and all concrete implementations of a standard is to use duck-typing, which is very much inferior to a real PHP interface.

But.. defining it as a real PHP interface, makes it implementation.. I got that correct?

Evert

[Erin Millard]

To me, a PHP interface is an implementation, yes. Even though there's no defined logic, it certainly has the ability to impose design decisions.

[Evert Pot]

On Aug 8, 2012, at 3:53 PM, Erin Millard wrote:

> To me, a PHP interface is an implementation, yes. Even though there's no defined logic, it certainly has the ability to impose design decisions.

So at what point is it still an API defined in a spec, and when does it become implementation?

Is it implementation if it's passes 'php -l', or does it become implementation because it uses the 'interface' keyword? Is it implementation if there's a .php file attachment?
Obviously defining method names is ok, since you mention ducktyping as an alternative to instanceof.

If we can define methodnames in an API, why can we not define what the result should be of ($obj instanceof X)?

Where is your line between interface and implementation?

I'm not arguing against your point for simplicity, because I wholeheartedly agree.. I just think the concept of interface and implementation for you, are different from the traditional point of view.

After all, the php keyword is interface, not implementation.

Evert

[Jelmer Schreuder]

To add to Evert:

The whole points of the concept of interfaces in a language is to allow for classes to depend on an API instead of an implementation. That completely separates the concept of an interface from the practice of implementation.

I too am in agreement that these APIs should remain simple and that a huge number of current proposals implements too much. But I'm very much a proponent of establishing some shared interfaces through FIG that increase how interchangeable libraries are.

Erin: But I'm not really shure what you want? You are arguing against interfaces as standards and at the same time you're arguing against duck-typing. What is it you do think should be done?

Op woensdag 8 augustus 2012 16:01:05 UTC+2 schreef Evert Pot het volgende:

[Erin Millard]

I'm not arguing against the use of standard interfaces. I'm saying that these proposed components belong in a library and not a standards document.

A library with standard interfaces and/or implementations makes sense, and adds something of value to the PHP community.

A standards document that defines a PHP API for a type of component that developers must implement to be compliant adds nothing of value, and in fact detracts from the value of the FIG standards as a whole.

So what I think is best is a clear separation of the two. If and when FIG decides it actually wants to implement standard libraries it should at least be a separate project and completely optional. That's all I'm trying to say.

It would probably also help to have a separate GitHub project for library propositions in the meantime.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/Ficj47NO9k0J.

[Evert Pot]

> A standards document that defines a PHP API for a type of component that developers must implement to be compliant adds nothing of value, and in fact detracts from the value of the FIG standards as a whole.
>
> So what I think is best is a clear separation of the two. If and when FIG decides it actually wants to implement standard libraries it should at least be a separate project and completely optional. That's all I'm trying to say.
>
> It would probably also help to have a separate GitHub project for library propositions in the meantime.

Most of the proposals that are in there are what most people would consider standards documents.
Your definition of a standards document is clearly different, as you call these 'standard library components' and 'implementations'.

Lets take a step back and not argue about how we call them, it's clear to me that you feel that these don't belong in the standard repository and should be separated.
Are there any practical arguments you can give why this would be a good idea. That they would 'detract value' is a judgement call & highly subjective, so you should at least try to come up with some real-world situations where this would be the case. Convince me.

Evert

[Erin Millard]

Sure. A warning though, wall of text follows.

Let's say that a HTTP request spec became part of PSR-3, and that the spec document says that HTTP requests MUST implement this API:

public function headers();

public function content();

// etc.

Now kriswallsmith decides to make his Buzz HTTP request match the spec. So he implements his version:

<?php

namespace Buzz\Message;

class Request

{

    public function headers()

    {

        // ...

    }

    public function content()

    {

        // ...

    }

    // etc.

}

And Guzzle update their implementation to match the spec:

<?php

namespace Guzzle\HTTP\Message;

class Request

{

    public function headers()

    {

        // ...

    }

    public function content()

    {

        // ...

    }

    // etc.

}

Great! Now there are two compliant implementations of PSR-3 HTTP requests.

Now I come along and want to write a component that does something with a PSR-3 standard HTTP request:

<?php

namespace Ezzatron;

class RequestHandler

{

    public function handle(Request $request)

    {

        // etc.

    }

}

But there's something missing here. I don't have a use statement yet. But which implementation do I use?

If I use Buzz\Message\Request I can't use Guzzle\HTTP\Message\Request and vice versa. The only way to accept any and all possible implementations is to drop the type hint and assume I'm getting a standard implementation:

<?php

namespace Ezzatron;

class RequestHandler

{

    public function handle($request)

    {

        // let's hope I've got a standard request otherwise this will fail...

        $content = $request->content();

    }

}

The above is pretty undesirable. It's flaky and it's inconsistent with typical OO design.

So what's the better alternative? Obviously a common PHP interface. But an common interface must live somewhere outside the two projects.

So let's assume that FIG implements a HTTP message library which defines a common interface:

<?php

namespace FIG\HTTP\Message;

interface Request

{

    /**

     * @return array

     */

    public function headers();

    /**

     * @return string

     */

    public function content();

}

And let's also assume that Buzz and Guzzle mark their request implementations as implementing the above interface.

Now my component can be implemented in a nice, elegant way:

<?php

namespace Ezzatron;

use FIG\HTTP\Message\Request;

class RequestHandler

{

    public function handle(Request $request)

    {

        // etc.

    }

}

This makes a lot more sense. If implementers wish to participate in PSR-3 HTTP request compatibility, they simply bring in the FIG library as a dependency and implement the interface.

Now consider that another HTTP library comes on the scene, but in its HTTP request implementation, it does things a little differently. Maybe instead of a string for the request content, it provides an object that helps with consuming multipart MIME data:

<?php

namespace Some\Awesome\HTTP\Message;

use Some\Awesome\HTTP\Content\ContentInterface;

class Request

{

    /**

     * @return array

     */

    public function headers()

    {

        // etc.

    }

    /**

     * @return ContentInterface

     */

    public function content()

    {

        // etc .

    }

}

This new implementation arguably does a better job than any existing one, but because there is a standards document, rather than just being non-compatible, it gets the bad connotation of being 'non-standards-compliant'.

So let's review what the standardization provided versus the actual implementation.

The implementation of a standard interface:

•  Allowed me to provide support for any HTTP request implementing the standard interface.
•  Allowed developers to implement said interface for better interoperability.
•  Allowed developers the freedom to choose to break compatibility in favour of an improved API.

The standard itself (without an implementation):

• Forced me to implement my component in a less than desirable way.
• Did not greatly improve interoperability.
• Stifled progression and created a negative stigma associated with a technically better but non-compliant implementation.

That is why I say that the HTTP request and things like it do not belong in specs, but in libraries; and that they are in fact detrimental.

Evert

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.

[Lukas Kahwe Smith]

On Aug 8, 2012, at 18:06, Erin Millard wrote:

> This new implementation arguably does a better job than any existing one, but because there is a standards document, rather than just being non-compatible, it gets the bad connotation of being 'non-standards-compliant'.

Its simply not compatible. So it goes.
Obviously the interface should be defined in such a way that as much low level implementation creativity is possible without making the work for implementors overly hard. It will always be a balancing act and like said I think its normal for subsequent PSR's to come along that expand on previous ones.

> So let's review what the standardization provided versus the actual implementation.
>
> The implementation of a standard interface:
> • Allowed me to provide support for any HTTP request implementing the standard interface.
> • Allowed developers to implement said interface for better interoperability.
> • Allowed developers the freedom to choose to break compatibility in favour of an improved API.
> The standard itself (without an implementation):
> • Forced me to implement my component in a less than desirable way.
> • Did not greatly improve interoperability.
> • Stifled progression and created a negative stigma associated with a technically better but non-compliant implementation.
> That is why I say that the HTTP request and things like it do not belong in specs, but in libraries; and that they are in fact detrimental.

Indeed you are using terminology very different than I think is common.
But yes, the goal is to have a set of PHP interfaces that will be packaged on packagist.org etc and that people can include in their code.

I wonder what your POV is on https://github.com/phpcr/phpcr
This is obviously a very complex set of interfaces but it has worked quite well with 2 separate implementations being build on top of it: https://github.com/jackalope/jackalope and http://midgard-project.org/phpcr/

But indeed its a bit iffy where those interfaces are suppose to live. Related to this I blogged on the idea of "loose interface coupling" http://pooteeweet.org/blog/2056

[Evert Pot]

>

<snip>

I'm going to jump right ahead, to what I feel is your main argument..

>
> This new implementation arguably does a better job than any existing one, but because there is a standards document, rather than just being non-compatible, it gets the bad connotation of being 'non-standards-compliant'.

SPDY is currently defined, which for some.. is a 'better HTTP'. HTTP itself was lauded as a better gopher..
RFC6350 is a 'better' RFC2426, and to many.. non-standard 'REST' is a better way to deal with webservices than the 'standard' SOAP.

A standard is a common agreement that allows different projects to agree.. 'this is a good way to do things'. Nobody has the illusion that these will live forever, and perfect is such a regard that we never need something else, or covers every usecase.

For now it allows people to speak the API, for those who choose so.

The way I interpret this statement, is that you feel that the act of defining a standard, is a bad thing for people who wish not to follow it. That may be true, but not something I particularly care about.

>
> So let's review what the standardization provided versus the actual implementation.
>
> The implementation of a standard interface:
> • Allowed me to provide support for any HTTP request implementing the standard interface.
> • Allowed developers to implement said interface for better interoperability.
> • Allowed developers the freedom to choose to break compatibility in favour of an improved API.

These all sound like reasons to provide a standard interface (?)

> The standard itself (without an implementation):
> • Forced me to implement my component in a less than desirable way.
> • Did not greatly improve interoperability.
> • Stifled progression and created a negative stigma associated with a technically better but non-compliant implementation.
> That is why I say that the HTTP request and things like it do not belong in specs, but in libraries; and that they are in fact detrimental.

I think the idea of providing a standard without an interface is fully coined by yourself, so most people here will agree that the standards should indeed ship the interfaces for the 3 reasons you stated here, and others.

Evert

[Phil Sturgeon]

I've skipped a large part of this conversation because it got really really really long, so sorry if my reply misses anything.

Look at it from a developers point of view. I make some crazy components like OAuth 2 for example, which obviously requires a fair chunk of HTTP interaction. Now I have a few choices how I handle that HTTP request building:

1. Write my own HTTP Request library and bundle it in my OAuth2 package. That is how it is now, and it's stupid.
2. Require Buzz specifically. You might have Guzzle installed, but f**k you I require Buzz.
3. Require a FIG/HTTP/Request object, which could be Buzz, Guzzle, or any other FIG HTTP compatible library.

I like the sound of 3. It doesn't matter what funky frills the "Project X" developer has decided to add in on top of the basic "interface" implementation, what extra methods, features, whatever are all irrelevant. I know that I can do my basic interaction in the exact same way, so I don't have to build 6 different "glue" classes for interacting with various packages.

This to me is what the FIG is all about. If the HTTP interfaces have been getting it wrong then I'll argue with the people suggesting anything against this idea until I am blue in the face.

Do we agree? Is this what we are trying to do or did I join the wrong club?

[ezzatron]

Again, I am not saying that a library of common interfaces is bad. I am not saying that standard implementations are bad.

Regardless of what terminology you use to describe them, these proposed components are a very different kettle of fish to the PSR-0, PSR-1, and PSR-2 standards, and should be treated as such.

The current PSRs do not have implications for library design. These proposals most certainly do.

PSR-2 tells me I have to use 4 spaces instead of tabs. A 'standard' HTTP client would tell me how I should design my interfaces. Can you not see that there is a huge, and important, difference there?

What I'm saying is:

1. These components should just be libraries.
2. There's nothing wrong with them just being libraries.
   
3. Make a clear separation between the current standards and things that will end up being an 'official' FIG library.

[TechnoSophos]

Where a standard exceeds an interface is that it can define behavioral aspects beyond what in interface can require. This is done by (a) providing textual descriptions of all necessary components, interactions, and behaviors, (2) providing supporting structural details (such as parsing rules where applicable), (3) point to other standards that must be obeyed, (4) supply compliance tests, and (5) providing interfaces or perhaps even a reference implementation.

One can observe these in any of the normal standards, from W3 to JSRs to RFCs.

A standard isn't *just* a batch of PHP interfaces, and the conversation is getting derailed by neglecting this obvious point. Take a look at some existing standards (I've already proposed the DOM standards*) and then let's gear the argument more toward addressing whether or not FIG wants to pursue these types of standards.

Matt Butcher

-- 

TechnoSophos

Blog: http://technosophos.com

Twitter: @technosophos

Sent with Sparrow

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/B7xvvEioyeAJ.

[Evert Pot]

On Aug 9, 2012, at 6:00 PM, TechnoSophos wrote:

> Where a standard exceeds an interface is that it can define behavioral aspects beyond what in interface can require. This is done by (a) providing textual descriptions of all necessary components, interactions, and behaviors, (2) providing supporting structural details (such as parsing rules where applicable), (3) point to other standards that must be obeyed, (4) supply compliance tests, and (5) providing interfaces or perhaps even a reference implementation.
>
> One can observe these in any of the normal standards, from W3 to JSRs to RFCs.
>
> A standard isn't *just* a batch of PHP interfaces, and the conversation is getting derailed by neglecting this obvious point. Take a look at some existing standards (I've already proposed the DOM standards*) and then let's gear the argument more toward addressing whether or not FIG wants to pursue these types of standards.

Historically, this has actually always been the goal and what has been discussed. PSR-1 & 2 were (i think) considered more controversial when first proposed, because they *weren't* like that.

In the end we should just pursue the standards that a majority deems useful as a sole basis, rather than try to define that beforehand.

This discussion I find a lot more interesting, rather than the always returning threads about semantics and process.
I feel that these standards or recommendations stand or fall if the big projects are still interested. Specifically Matthew Weier O'Phinney (from Zend Framework) has mentioned the following:

> Honestly, I'd rather projects simply provide interfaces for anything allowing substitution. This gives the developer a way to bridge from one project to another. It takes work, but you lose no flexibility or features. It's also more productive than bikeshedding about who's interpretation of a pattern is more correct.

This quote was specifically in the 'Event based programming' thread, but from what I understand talking to him (please correct me if I'm wrong) he feels this way about the idea of common interfaces in general.

If a larger majority feels this way, I think we're kind of wasting our time here :)

Evert

[Larry Garfield]

On 08/09/2012 11:00 AM, TechnoSophos wrote:

Where a standard exceeds an interface is that it can define behavioral aspects beyond what in interface can require. This is done by (a) providing textual descriptions of all necessary components, interactions, and behaviors, (2) providing supporting structural details (such as parsing rules where applicable), (3) point to other standards that must be obeyed, (4) supply compliance tests, and (5) providing interfaces or perhaps even a reference implementation.

One can observe these in any of the normal standards, from W3 to JSRs to RFCs.

A standard isn't *just* a batch of PHP interfaces, and the conversation is getting derailed by neglecting this obvious point. Take a look at some existing standards (I've already proposed the DOM standards*) and then let's gear the argument more toward addressing whether or not FIG wants to pursue these types of standards.

Matt Butcher

A bit late to this thread, but it is an important discussion...

Matt, you're entirely correct that a good standard is more than merely an interface definition, especially since a PHP interface cannot define and enforce certain rather important details (return types, for instance).  However, do you feel that a standard that encompasses a PHP interface is a bad thing?

For my part, I'd argue that Erin has provided ample justification of why a standard that does NOT include an interface definition is in practice useless to me.  (I know that wasn't his intent, but he did it anyway. <g>)  Simply knowing that a request object should have a method named "headers" that returns an array doesn't do anything to make code interoperable, unless I drop language typing and just pray.  And while I could build a whole bunch of bridge interfaces or subclasses to make my otherwise-effectvely-compatible library work in a given code base... why go to that trouble?  Really.

The argument that a formal interface as part of a spec limits further extension and innovation is untrue as well, I think.  Or, rather, it's no worse than with a properly defined human-language standard.

Imagine an English-standard: "The request object should have a method on it called headers that returns a sequential array of headers, as strings."

OK, great, I know what to do with that.  Now, someone has the great idea that their request object should return an associative array instead, so that it's more useful and easier to parse.  But they can't change the return structure of the method without breaking any code that is expecting a sequential list.  That's the exact problem that was levied against a language-interface approach.  That would be just as  "eew, eew, evil, non-standard-compliant!" as if there were a language interface.

As a workaround, you could add another method, headersAsAssoc(), which wouldn't break the standard.  But you have that option just the same if there is a language interface.

As a workaround, you could add an optional argument to the method for $assoc = FALSE, and if TRUE then it would return the alternate data structure.  But as long as it is optional you have the exact same capability with an interface-defined specification.

So really, the "OMG can't innovate it's too restricting" argument applies equally to any standard, regardless of whether there is a PSR\HTTP\Request interface defined or not.  And regardless of whether or not there is a language interface defined, defining future-compatible standards is always a challenge.  Just ask W3C. :-)

So yes, +1 to including an interface definition in a PSR, although as Matt says a proper standard consists of much more than just that.

--Larry Garfield

[Jurgens du Toit]

I couldn't agree more.

For me interfaces are the best way to translate standards into code.

By implementing an interface, you tell the world that you comply to the (coded) standard and that it's enforced by the PHP parser (with the exception of return and native types).

By expecting an interface, public function Foo(BarInterface $bar), you can code confidently knowing that the object passed will conform to the (coded) standards.

By coded standards I mean a standard implemented as an interface.

Without interfaces, a coder cannot accept with confidence that an object will perform as advertised, especially in development code.

J

[Phil Sturgeon]

> There's nothing wrong with them just being libraries.

There is everything wrong with them just being libraries.

HTTP Libraries: Guzzle, Buzz, HTTPful, HTTPFoundation, etc.

Why make a new one? If these guys can pick a standard set of methods and create an interface, then we have standardised the components and I can interact with all of them in the same way. THAT is the point, we don't want to start "condoning" libraries, or writing new ones.

[Paul Dragoonis]

It's pretty clear that we want consistency between HTTP related libraries.

Usually people will pick a library because of how easy it is to
integrate rather than how suitable it is for their project.
Consistency through generalised interfaces will let us do
plug-and-play with http libraries more easily.

How are we coming along with some draft interfaces? Ones that relate
to the commonalities between the libraries mentioned: "Guzzle, Buzz,
HTTPful, HTTPFoundation".

Apologies if this stuff has already been discussed but I've missed a
lot of http talk due to "tl;dr" reasons :-)

Thanks,
Paul.

> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To post to this group, send email to php...@googlegroups.com.
> To unsubscribe from this group, send email to
> php-fig+u...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/php-fig/-/arhYQPvxpKAJ.

[Brian C. Dilley]

This is the same issue we had with the ObjectCache.

http://en.wikipedia.org/wiki/KISS_principle

Simple interfaces without implementation specific detail is the goal.