Closed Gerschtli closed 7 years ago
This would mean we would have to maintain BC on all these properties, which is bad for maintenance (it would make it impossible to merge #35 for instance)
It's hard to imagine that properties like $this->request or $this->response would change their name or go away in any foreseeable future
+1 for exposing the request and response. It makes it far easier to extend the context. For example, when making a POST request I want to examine the headers of the response to make sure there is a 'Location'. Can't do it because I don't have access to $this->response
. Maybe even better would be to expose $this->client
. It has a well defined interface.
@valthebald they will change their type in the near future, because of #35, meaning it would be a BC break if it is exposed
Maybe could you provide some concrete use cases for that?
It's maybe possible to find another way.
@stof Is this is going to be merged, #35 should be indeed be merged first.
Specific use case is like others mention - extending the base context class. +1 for #35 to be merged first, and in that case, child classes won't need $this->request, only $this->response and/or $this->client
This is a needed feature, testing requires flexible extensions and accesible data.
@Gerschtli Can you please rebase your PR since #35 is merged?
Closed, see #69
It's very helpful, when properties like response and request are accessible in the custom feature context class, if you want to add some extra functionality that's currently not supported.