search

pennyphp / penny

:moneybag: Php Framework made of other components
http://penny.gianarb.it/
Other
40 stars 7 forks source link

Request and Response only PSR-7 why? #21

Closed gianarb closed 9 years ago

gianarb commented 9 years ago

I'm speaking with @fntlnz about this line of code

use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\RequestInterface;

public function run(RequestInterface $request = null, ResponseInterface $response = null)

He helps me to do a question: "Why $request and $response should be implement this interfaces?"

I have the worse response: "I don't know why!".

I thought about this question and in my opinion we can remove this interface because PSR-7 is only a possible street but there are a lot of http implementation around the world.

EmanueleMinotto commented 9 years ago

Imho the libraries should implement those interfaces, we're talking of a PSR, not a generic Foo\Bar\Request.

My questions are:

gianarb commented 9 years ago

Thanks @EmanueleMinotto for your questions. I try to expose my idea

  • why shouldn't them be forced?

Because PSR is not a "supreme state", it is only another opinable implementations of classes..

  • what could happen if a $request is a mixed value?

In this library nothing because I don't use this objects to write logic. The logic overt this objects is leave to application level..

  • how can a $request be used without an interface? without an interface it could be everything

Same response above :D

This change introduces these problems:

I don't know if they are bad problems

fntlnz commented 9 years ago

Not forcing them can give the developer the ability to focus on what the application does instead on how it's done (tools, frameworks, interfaces)

If the request is a mixed value the user will provide a dispatcher that can handle that kind of request and controllers will receive, say, a string as request instead of an object.

We must obviously provide a few examples on how to use it with diactoros, Httpkrnel, Zend\Request and so on but I don't think that this is not feasible.

IMO the fact that it could be everything is the cool thing. This way we will not bind the developer to anything else than a few layers to put together other components so he can focus on doing things how he want on top of these layers.

However these are only my 50 cents (or pennies if you want :D) and these thoughts must be proven with a real implementation to tell if are sensed or not.

I'm from mobile If I was not clear tell me.

L

On Tue, Aug 25, 2015, 12:11 Emanuele Minotto notifications@github.com wrote:

Imho the libraries should implement those interfaces, we're talking of a PSR, not a generic Foo\Bar\Request.

My questions are:

  • why shouldn't them be forced?
  • what could happen if a $request is a mixed value?
  • how can a $request be used without an interface? without an interface it could be everything

— Reply to this email directly or view it on GitHub https://github.com/gianarb/penny/issues/21#issuecomment-134546486.

EmanueleMinotto commented 9 years ago

Sounds cool, and I agree that PSRs shouldn't be strong like a language requirement. Then could this be considered a political choice? :)

Flexibility and more responsibilities to the final developer instead of driving him/her to the right way.

gianarb commented 9 years ago

Flexibility and more responsibilities to the final developer instead of driving him/her to the right way.

this is the basis of this project :)

At the moment I maintain how default this implementation with diactoros but every devs could change this library.

fntlnz commented 9 years ago

What do you mean by "default implementation"?

gianarb commented 9 years ago

At the moment if you don't override $request and $response I build for your diactoros object.. I maintain this flow.. Remove only Interfaces from run signature

fntlnz commented 9 years ago

I don't like maintaining the default flow but should be in the list of examples of possible implementations though , and I think that the dispatcher at this point should accept something different than the request. Maybe a dedicated dispatch object?

Maintaining the default implementation as you want to do would just pollute the code and divert attention from the main purpose.

One could just think: hey, look at these n00bs of Penny they used request and response from diactoros but missed types in signature. How can this actually work? It will just break!

gianarb commented 9 years ago

I agree with you but I don't know if it's a good idea create now all this layers

In my opinion we can maintain a default flow into the framework but it is need a lot of example to extend it and create his implementation.

Another problem to create an "interpolation layer" is that it is impossible to create it for all..

Every router libraries could expect different parameters to resolve the request.. FastRouter expects method and path, Symfony\Router no. Same stuff for the Request/Response object and for all different crosses.

Maybe we can start with a very free signatures and we can think how resolve this issue step by step.. After few implementation

fntlnz commented 9 years ago

Ok and what do you think about not having the dispatch at all in the framework? We can put it in examples and user can use the one they prefer for their router. Maybe we can write a few dispatch to match the most frequent needs. And another thing... This framework is intended to be used to expose contents to the web so it's a web framework right now. Shouldn't it be a more generic thing? The user impelentation could define if is the case to be a web application or a console application or a php gtk application or a space shuttle.

L.

On Tuesday, August 25, 2015, Gianluca Arbezzano notifications@github.com wrote:

this stuff sounds good but I don't know if it's a good idea create all this layers

In my opinion we can maintain a default flow into the framework but it is need a lot of example to extend it and create his implementation.

Another problem to create an "interpolation layer" is that it is impossible to create it for all..

Every router libraries could expect different parameters to resolve the request.. FastRouter expects method and path, Symfony\Router no. Same stuff for the Request/Response object and for all different crosses.

Maybe we can start with a very free signatures and we can think how resolve this issue step by step.. After few implementation

— Reply to this email directly or view it on GitHub https://github.com/gianarb/penny/issues/21#issuecomment-134611418.

debo commented 9 years ago

I'm not sure what the problem is here and what we are discussing or trying to achieve exactly. I understand that the main concern here is flexibility in the sense of "We don't want to force the end user to buy into a specific implementation" which is a noble goal but as usual comes to a price. When we are talking about OO having a clear and well defined interface is very important to ensure the stability of the code; OO is all about messaging and contracts. If you think that enforcing diactoros is too much of an enforcement then create a new interface that will act as an adapter for whichever other interface will be used. Hexagonal architecture might help in this case. If your runner needs to be able to run pretty much anything then it should be able to know exactly what he is about to receive in terms of message/api otherwise your runner will soon become a clusterfuck of conditionals and exception trying to handle all the possible scenarios of a mixed parameter.

fntlnz commented 9 years ago

I got your point. From what you just said I can ensure you that you understood what we are talking about. However I wouldn't call it "problem", we are just discussing about other ways to do the same thing. My first thought was to replace diactoros's request and response with PSR7 interfaces but @gianarb wanted something more flexible than that so he proposed to not define/use an interface at all giving the end user/skeleton-application the responsibility to do so. I think that the PSR7 way is probably the best approach in this case since without doubt a lot of libraries will start supporting it in the next future.

Maybe one could use that interface to create adapters for non PSR7 libraries such as React HTTP for example.

L.

On Tuesday, August 25, 2015, Debo notifications@github.com wrote:

I'm not sure what the problem is here and what we are discussing or trying to achieve exactly. I understand that the main concern here is flexibility in the sense of "We don't want to force the end user to buy into a specific implementation" which is a noble goal but as usual comes to a price. When we are talking about OO having a clear and well defined interface is very important to ensure the stability of the code; OO is all about messaging and contracts. If you think that enforcing diactoros is too much of an enforcement then create a new interface that will act as an adapter for whichever other interface will be used. Hexagonal architecture might help in this case. If your runner needs to be able to run pretty much anything then it should be able to know exactly what he is about to receive in terms of message/api otherwise your runner will soon become a clusterfuck of conditionals and exception trying to handle all the possible scenarios of a mixed parameter.

— Reply to this email directly or view it on GitHub https://github.com/gianarb/penny/issues/21#issuecomment-134641516.

debo commented 9 years ago

@fntlnz truth is that there is nothing more flexible than a good and well defined interface so that people knows how to coply with it. When you properly apply the OCP to your library having and interface to implement is the only way to know you are in the right direction and doing the right thing to talk with that library. So +1 for the adoption on a PSR7 compatible interface from me.

fntlnz commented 9 years ago

I agree with you if the road here is that penny knows about request and response like how is done in the current inolementation.

If penny acts just as pushing paper and does nothing with request and response if not sending them to the user defined code it should not bind them to a specific interface IMHO.

The second option however will make all more and more difficult to manage both for us and for the end user. That's te cost of this kind of implementation.

In any case I do prefer the first option. A few things like this should be well defined in order to allow the user to use the framework without worrying about that level of detail. This would also give the user a certain level of flexibility without too much hassle. One can just use a PSR7 compliant message (request/response) or write an adapter for a non compliant one. In this way the framework can continue providing a default message implementation without precluding the user the ability to replace it with another subtype of PSR7'S Request and Response interfaces respecting also lsp.

With the first option the only thing that should be done is to replace diactoros types with psr7 ones. With the second a lot of things must be considered before moving forward.

L On Aug 25, 2015 6:33 PM, "Debo" notifications@github.com wrote:

@fntlnz https://github.com/fntlnz truth is that there is nothing more flexible than a good and well defined interface so that people knows how to coply with it. When you properly apply the OCP to your library having and interface to implement is the only way to know you are in the right direction and doing the right thing to talk with that library. So +1 for the adoption on a PSR7 compatible interface from me.

— Reply to this email directly or view it on GitHub https://github.com/gianarb/penny/issues/21#issuecomment-134663373.