Is it possible to chain function calls, i.e. session().get('foo').? I don't think so. So if not, it would require to assign it to a variable first which makes things rather verbose compared to the global variable.

@Tobion, yes, you can chain them.

In case of session().get('foo'), I'd rather see something simpler such as session('foo'). Same goes for request('foo'). Both would be equivalent to $request->get('foo') and $session->get('foo').

@iltar symfony 2 has no magic anymore and this doesn't work generically. Why would it be a shortcut for get and not some other method...

@Tobion It's not magic and why shouldn't it work?

public function getRequest($name = null)
{
    $request = $this->request_stack->getCurrentRequest();
    return $name ? $request->get($name) : $request;
}

Edit: Why get and not something else? Because why would you set something in the request in your template? That's a bad practice IMO. If you want something else:
{{ request().attributes.get('foo') }}

@iltar, because you do many things with a Request besides getting a value from the query/request/cookie/...

@fabpot in the controller I would agree. In the template I think you don't want to have that all available.

Doing a grep app.request in a fresh installation of the CMF sandbox, I see lots of things except app.request.get. I agree with @fabpot and @Tobion here.

However, I tend to agree a bit with what @hhamon said in the previous PR:

Having functions to access global objects sounds strange to me as Twig functions are meant to generate/create values if I'm not mistaking. These functions always return the same values everytime they're called.

ping @symfony/deciders Good idea or not?

@iltar IMO, it is important to be able to get a param from the query string or from the attributes only. Allowing to get it from the query string when you expect it to be in the attributes can even be a security issue in your app depending of what you do with it, because the user can put what he wants in the query string. So calling $request->get() directly is a -1 from me.
For the session access, there is the same issue: your proposal forbids accessing flash messages (or requires adding another function for that)

@stof Session wise it depends on whether you do or do not use the SessionInterface as a base for this function..

I also agree with the objection

Having functions to access global objects sounds strange to me as Twig functions are meant to generate/create values if I'm not mistaking.

@fabpot what was your main argument/idea for the change?

@Tobion I'm not convinced myself that this is a good idea. Closing now.