On 12 February 2020 23:12:34 GMT+00:00, Manuel Canga
wrote:
>El mié., 12 feb. 2020 23:01, Rowan Tommins
>escribió:
>In your example, you has the same options:
>
>>
>1. Change import
>2. Add namespace:
>
>['Acme\Global\I18N',\translate::function]
There is no collision between 'Foo::translate()'
On 13 February 2020 03:33:32 GMT+00:00, Mike Schinkel
wrote:
>> On Feb 12, 2020, at 5:47 PM, Rowan Tommins
>wrote:
>>
>> On 12/02/2020 03:58, Mike Schinkel wrote:
>>> Returning a_closure_ instead of a string would be providing a
>feature we_already_ have instead of one we do_not_ have.
>>
>
Hi!
I really like this RFC.
> On 12 Feb 2020, at 23:46, Paul M. Jones wrote:
>
> Hi Allen & Robin,
>
> Allen, you asked:
>
>> On Feb 12, 2020, at 15:27, AllenJB wrote:
>>
>> This might be more a "future scope" thing, but I would like to see a way to
>> access the raw request body as part of
> On Feb 12, 2020, at 5:47 PM, Rowan Tommins wrote:
>
> On 12/02/2020 03:58, Mike Schinkel wrote:
>> Returning a_closure_ instead of a string would be providing a feature
>> we_already_ have instead of one we do_not_ have.
>
>
> Not really, because you still need a way to get the fully-qual
Hi Ben,
> On Feb 11, 2020, at 10:58, Ben Ramsey wrote:
>
> Regarding the array of arrays for $accept* and $forwarded, what are your
> thoughts on using value objects with properties, rather than arrays with keys?
It's a fair suggestion, but I am not keen to expand the number of new
declarati
El mié., 12 feb. 2020 23:01, Rowan Tommins
escribió:
> On 12/02/2020 21:47, Manuel Canga wrote:
> > You is importing function and you are using different. It is the same
> > case like:
> >
> > namespace MyProject;
> >
> > use Vendor/Controller;
> >
> > class Controller extends Controller {
> > }
On 12/02/2020 03:58, Mike Schinkel wrote:
Returning a_closure_ instead of a string would be providing a feature
we_already_ have instead of one we do_not_ have.
Not really, because you still need a way to get the fully-qualified name
of the function. This is not valid:
namespace MyVendo
Hi Allen & Robin,
Allen, you asked:
> On Feb 12, 2020, at 15:27, AllenJB wrote:
>
> This might be more a "future scope" thing, but I would like to see a way to
> access the raw request body as part of this. Currently (as far as I know) the
> only way is to open/read php://input, which isn't p
Hi Albert,
> On Feb 11, 2020, at 11:22, Albert Casademont
> wrote:
>
>> Am 11.02.20 um 13:42 schrieb Albert Casademont:
>>
>>> This is very interesting, thanks!
>>>
>>> Would it make sense to also add an INI setting to disable superglobals
>>> and response functions?
>>
>> no because changin
On 12/02/2020 21:47, Manuel Canga wrote:
You is importing function and you are using different. It is the same
case like:
namespace MyProject;
use Vendor/Controller;
class Controller extends Controller {
}
In that example, you're defining two things of the same type with the
same name, w
El mié., 12 feb. 2020 22:36, Rowan Tommins
escribió:
> On 11/02/2020 15:13, Manuel Canga wrote:
> > One case which string can be useful but a callable would not be
> acceptable is:
> >
> > array_map([I18N::class, translate::function] );
>
>
> I wouldn't expect that to work anyway, because the who
On 12/02/2020 18:20, Niklas Keller wrote:
Type Safety
I think the API should be type safe. Currently $request->get['key']
can be null | string | string[] | ... Most parameters only appear a
single time, so a method returning the first parameter value or null
could be used instead.
I may be mis
On 11/02/2020 15:13, Manuel Canga wrote:
One case which string can be useful but a callable would not be acceptable is:
array_map([I18N::class, translate::function] );
I wouldn't expect that to work anyway, because the whole purpose of the
keyword would be to resolve "translate" as a functio
This might be more a "future scope" thing, but I would like to see a way
to access the raw request body as part of this. Currently (as far as I
know) the only way is to open/read php://input, which isn't particularly
intuitive in my opinion.
AllenJB
On 10/02/2020 16:18, Paul M. Jones wrote:
Hello Andreas,
> But people can now already contribute via git to the docs as – at least
Does that mean that we can skip the (inaccessible) edit.php.net and
send pull requests on Github?
Thanks!
--
With best regards from Germany,
Andre
Skype: menelion_elensule
Twitter (English only): @AndreP
Hi Jan,
> I like this proposal a lot, since it provides a clear, concise interface to
> these commonly uses, yet inconveniant to use, existing functions and
> variables without having to always use a full-featured userland library.
Glad to hear the RFC is hitting the right notes!
> Speaking
> On Feb 12, 2020, at 1:40 PM, Manuel Canga wrote:
> IMO, we should limit RFC to '::function'( scope and accept/reject ).
Agreed.
> After this, other RFC can be added/checked like Short closures( of Michal )
> or other purposes with other variation like :interface and ::trait: ( of Mike
> )
Th
On Wed, 12 Feb 2020 at 15:08, Dan Ackroyd wrote:
> On Tue, 11 Feb 2020 at 13:19, Nikita Popov wrote:
> >
> > https://wiki.php.net/rfc/consistent_callables.
> >
>
> btw it's probably worth mentioning the other reason I didn't pursue
> https://wiki.php.net/rfc/consistent_callables.
>
> By itself,
> On Feb 12, 2020, at 1:20 PM, Niklas Keller wrote:
> I think the request / response API is entirely fine being solved in
> userland instead of in php-src.
I want to disagree in support of this RFC.
While is *has* been solved in userland, but it has been solved 25+ times in 25+
different incom
> Hi Internals,
>
> After a couple of years of incubation, I am happy to offer a second version
> of this RFC:
>
> https://wiki.php.net/rfc/request_response
>
> It proposes an object-oriented approach around request and response
> functionality already existing in PHP, in order to reduce the gl
> On Feb 12, 2020, at 7:47 AM, Paul M. Jones wrote:
>
> That is essentially what it does now; the difference is that you mimic the
> $GLOBALS array at construction time, and the instance locks automatically:
>
>$request = new ServerRequest([
>'_GET' => ['foo' => 'bar'],
>'_C
Hi Johannes,
> What indication is there that this will be more successfull than the
> filter API?
Fair question. While I can't say how successful (or not) ext/filter has been, I
*can* say that the proposal does not present extraordinary or dramatically
different ways of working than PHP does c
Hi everyone,
I happy to open the vote for the Stringable RFC:
https://wiki.php.net/rfc/stringable#vote
The vote will stay open until 2020-02-26.
Cheers,
Nicolas
On Tue, 11 Feb 2020 at 13:19, Nikita Popov wrote:
>
> https://wiki.php.net/rfc/consistent_callables.
>
btw it's probably worth mentioning the other reason I didn't pursue
https://wiki.php.net/rfc/consistent_callables.
By itself, the callable type isn't much use. It only allows you to
specify tha
Hi Mike,
> I like this, a lot. ... In general I think this would definitely be a nice
> enhancement to PHP, IMO.
Thanks for saying!
> I do have questions about ServerResponse. It is not clear how that interacts
> with existing echo, header(), setcookie(), etc? You say it creates a buffer;
> On Feb 12, 2020, at 2:12 AM, Guilliam Xavier
> wrote:
>
> On Wed, Feb 12, 2020 at 4:58 AM Mike Schinkel wrote:
>>
>> Or best would be to add ::nameof for functions, method, classes, interfaces
>> and traits
>
> One problem is how would `x::nameof` resolve when you have several `x`
> symbol
26 matches
Mail list logo
