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`
symbols (of distinct kinds) in scope?
```
namespace Theirs {
class Foo {}
> On Feb 11, 2020, at 6:13 AM, Manuel Canga wrote:
>
> Hi internals,
> I Would like to present a possible new "::func resolution" for your
> consideration.
>
> In first place, PHP now support "::class" in this way:
>
> use My\I18N;
>
> $mapped_array = array_map([I18N::class, 'translate'],
Hey Internals and docs-folks
On Monday we finished the first important step of moving the
documentation to git.
Nikita created all the missing repos and Peter provided me with push
access to all those repos via the phpdocbot account. I then cloned all
currently active language-repos using an
> On Feb 11, 2020, at 9:51 AM, Chase Peeler wrote:
>
> Can anyone thing of a use-case where you would want a string name of a
> function and a callable would not be acceptable, besides possibly debugging
> code that said 'echo "I'm calling ".myfunction::function;'? Everything that
> I can think
Hi internals,
I Would like to present a possible new "::func resolution" for your
consideration.
In first place, PHP now support "::class" in this way:
use My\I18N;
$mapped_array = array_map([I18N::class, 'translate'], $array);
It avoid add Full I18N namespace in callback.
However with
On Tue, Jan 28, 2020 at 5:23 PM Nikita Popov wrote:
> Hi internals,
>
> As the last RFC for the day, I've opened voting on
> https://wiki.php.net/rfc/variable_syntax_tweaks.
>
> The vote will stay open until 2020-02-11.
>
The proposal has been accepted unanimously with 47 votes in favor.
On Tue, Jan 28, 2020 at 10:15 AM Nikita Popov wrote:
> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/class_name_literal_on_object. Voting closes
> 2020-02-11.
>
The proposal has been accepted unanimously with 60 votes in favor.
Regards,
Nikita
On Tue, Jan 28, 2020 at 10:59 AM Nikita Popov wrote:
> Hi internals,
>
> I've opened voting on the "static" return type RFC:
> https://wiki.php.net/rfc/static_return_type
>
> Voting closes on 2020-02-11.
>
The proposal has been accepted unanimously, with 54 votes in favor.
Regards,
Nikita
I'm sorry. I forgot subject due to nerves. I add it.
On Tue, 11 Feb 2020 at 12:13, Manuel Canga wrote:
>
> Hi internals,
> I Would like to present a possible new "::func resolution" for your
> consideration.
>
> In first place, PHP now support "::class" in this way:
>
> use My\I18N;
>
>
As others have mentioned, this will do nothing but make people annoyed
and switch to the hash_file() version of exactly the same thing or put
up another hurdle to updgrading PHP.
The password hashing API now provides an obvious go-to for password hashing.
For other hashing usages there are, I
On Tue, 11 Feb 2020 at 09:34, AllenJB wrote:
> If you want to change the way developers think about hashing when
> writing PHP, I would start with the documentation rather than
> deprecating functions which are essentially aliases and are highly
> likely used all over the place in cases where
Le lun. 27 janv. 2020 à 10:19, Nikita Popov a écrit :
> On Wed, Jan 22, 2020 at 4:47 PM Nicolas Grekas <
> nicolas.grekas+...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> as announced last week, I'm officially opening a discussion for adding a
>> "Stringable" interface to PHP 8.
>>
>> The RFC
Zitat von Paul M. Jones :
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
Hi internals,
I'd like to get some feedback on the idea implemented in
https://github.com/php/php-src/pull/5168. It provides an easy way to
implement decorates, by taking care of forwarding any methods you do not
want to override in a type-safe way. See the PR description for details.
I've been
Hi Manuel
Thanks for bringing this idea forward.
Adding a non-string construct to reference functions uniquely seems
like a good idea and would be consistent with the existing ::class
keyword for classes.
I'm wondering if it would be useful to take a page out of the book of
other
Le mar. 11 févr. 2020 à 12:52, Diogo Galvao a écrit :
> On Tue, Feb 11, 2020 at 8:14 AM Manuel Canga
> wrote:
> >
> > Hi internals,
> > I Would like to present a possible new "::func resolution" for your
> > consideration.
> ...
> > use function \My\I18N\i18n_translate;
> >
> > $mapped_array =
Hi,
On Tue, Feb 11, 2020 at 1:09 PM Manuel Canga wrote:
>
> I was thinking about 'function' or 'func'. 'function' is more
> semantic, but 'func' is used with "short functions"( PHP 7.4 ) and
> these will be used for callbacks. Then I think 'func' will be more
> consistent.
Actually PHP 7.4's
Ups!. What big mistake!
Then ::function should be a better option.
Thanks, Guilliam,
On Tue, 11 Feb 2020 at 13:47, Guilliam Xavier wrote:
>
> Hi,
>
> On Tue, Feb 11, 2020 at 1:09 PM Manuel Canga wrote:
> >
> > I was thinking about 'function' or 'func'. 'function' is more
> > semantic, but
On Tue, Feb 11, 2020 at 2:11 PM Michał Brzuchalski
wrote:
>
> wt., 11 lut 2020 o 13:59 Guilliam Xavier
> napisał(a):
>>
>> On Tue, Feb 11, 2020 at 1:12 PM Nicolas Grekas
>> wrote:
>> >
>> > >
>> > > Just so someone has mentioned it... is "Stringable" really the best name
>> > > for this
Am 11.02.20 um 14:11 schrieb Michał Brzuchalski:
>>> Traversable, Serializable, Countable, Throwable, JsonSerializable
>>> all are related to some special engine behavior, which this ones also is.
>>
>> But one could argue that "string" is not a verb like "traverse",
>> "serialize", "count",
Hi Tom,
I thought about that short version. However, in order to avoid
conflicts with constants, I chosen "::func". If this is not problem in
low level of PHP, then I agree with you in shorter version is better.
Thanks for your opinion, Tom
On Tue, 11 Feb 2020 at 12:33, Tom Gerrits wrote:
On Tue, Feb 11, 2020 at 9:57 AM Nicolas Grekas
wrote:
> Le lun. 27 janv. 2020 à 10:19, Nikita Popov a
> écrit :
>
> > On Wed, Jan 22, 2020 at 4:47 PM Nicolas Grekas <
> > nicolas.grekas+...@gmail.com> wrote:
> >
> >> Hello everyone,
> >>
> >> as announced last week, I'm officially opening a
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 changing basic language behavior that way is not helpful for
code meant to run everywhere and not
On Tue, Feb 11, 2020 at 1:12 PM Nicolas Grekas
wrote:
>
> >
> > Just so someone has mentioned it... is "Stringable" really the best name
> > for this interface? Reddit really didn't like it ;) Some possible
> > alternatives: ToString, HasToString, CastsToString.
> >
>
> Naming things...
> I'm not
On Tue, Feb 11, 2020 at 1:43 PM Manuel Canga wrote:
> On Tue, 11 Feb 2020 at 13:16, Nicolas Grekas
> wrote:
> >
> >
> >
> > Le mar. 11 févr. 2020 à 12:52, Diogo Galvao a écrit
> :
> >>
> >> On Tue, Feb 11, 2020 at 8:14 AM Manuel Canga
> wrote:
> >> >
> >> > Hi internals,
> >> > I Would like
>
> Just so someone has mentioned it... is "Stringable" really the best name
> for this interface? Reddit really didn't like it ;) Some possible
> alternatives: ToString, HasToString, CastsToString.
>
Naming things...
I'm not sure reddit is the way to lobby php-internals...
I proposed Stringable
On Tue, 11 Feb 2020 at 13:16, Nicolas Grekas
wrote:
>
>
>
> Le mar. 11 févr. 2020 à 12:52, Diogo Galvao a écrit :
>>
>> On Tue, Feb 11, 2020 at 8:14 AM Manuel Canga wrote:
>> >
>> > Hi internals,
>> > I Would like to present a possible new "::func resolution" for your
>> > consideration.
>> ...
This is very interesting, thanks!
Would it make sense to also add an INI setting to disable superglobals and
response functions?
On Tue, Feb 11, 2020 at 10:34 AM Jan Schneider wrote:
>
> Zitat von Paul M. Jones :
>
> > Hi Internals,
> >
> > After a couple of years of incubation, I am happy to
wt., 11 lut 2020 o 13:59 Guilliam Xavier
napisał(a):
> On Tue, Feb 11, 2020 at 1:12 PM Nicolas Grekas
> wrote:
> >
> > >
> > > Just so someone has mentioned it... is "Stringable" really the best
> name
> > > for this interface? Reddit really didn't like it ;) Some possible
> > > alternatives:
On Tue, Feb 11, 2020 at 8:14 AM Manuel Canga wrote:
>
> Hi internals,
> I Would like to present a possible new "::func resolution" for your
> consideration.
...
> use function \My\I18N\i18n_translate;
>
> $mapped_array = array_map(i18n_translate::func, $array);
...
> What is your opinion ? Do you
Hi, Diogo
That's right. I could be useful with classes as well.
I was thinking about 'function' or 'func'. 'function' is more
semantic, but 'func' is used with "short functions"( PHP 7.4 ) and
these will be used for callbacks. Then I think 'func' will be more
consistent.
Thanks, Diogo,
On Tue,
Hi Michał,
Good to hear from you!
(While writing this, I realized I made a couple of mistakes in the RFC examples
related to CONTENT_LENGTH and CONTENT_TYPE that might have caused confusion; I
have now fixed them.)
> On Feb 10, 2020, at 10:46, Michał Brzuchalski
> wrote:
>
> Hi Paul,
>
>
Am 11.02.20 um 12:58 schrieb Nikita Popov:
> Just so someone has mentioned it... is "Stringable" really the best name
> for this interface? Reddit really didn't like it ;) Some possible
> alternatives: ToString, HasToString, CastsToString.
I would vote for "Stringable" because PHP already has
On 2/10/2020 3:42 PM, Chase Peeler wrote:
On Mon, Feb 10, 2020 at 5:36 PM Mark Randall wrote:
On 10/02/2020 21:49, Tom Van Looy via internals wrote:
I suggest to deprecated the functions md5_file() and sha1_file(). This
will
make people think about upgrading to a better alternative.
It
> On Feb 11, 2020, at 07:20, Aimeos | Norbert Sendetzky
> wrote:
>
> Am 11.02.20 um 14:11 schrieb Michał Brzuchalski:
Traversable, Serializable, Countable, Throwable, JsonSerializable
all are related to some special engine behavior, which this ones also is.
>>>
>>> But one could
On Tue, Feb 11, 2020 at 8:19 AM Nikita Popov wrote:
> On Tue, Feb 11, 2020 at 1:43 PM Manuel Canga
> wrote:
>
> > On Tue, 11 Feb 2020 at 13:16, Nicolas Grekas
> > wrote:
> > >
> > >
> > >
> > > Le mar. 11 févr. 2020 à 12:52, Diogo Galvao a
> écrit
> > :
> > >>
> > >> On Tue, Feb 11, 2020 at
On Tue, 11 Feb 2020 at 16:27, Levi Morrison
wrote:
>
> I have three immediate thoughts:
>
> 1. It should be `fn` or `function`; reserving a new word even if it's
> contextual is pointless here.
> 2. It should support methods.
> 3. It should return a closure, not a string. The reason is for
>
On Tue, 11 Feb 2020 at 15:51, Chase Peeler wrote:
>
>
>
> On Tue, Feb 11, 2020 at 8:19 AM Nikita Popov wrote:
>>
>> On Tue, Feb 11, 2020 at 1:43 PM Manuel Canga wrote:
>>
>> > On Tue, 11 Feb 2020 at 13:16, Nicolas Grekas
>> > wrote:
>> > >
>> > >
>> > >
>> > > Le mar. 11 févr. 2020 à 12:52,
I have three immediate thoughts:
1. It should be `fn` or `function`; reserving a new word even if it's
contextual is pointless here.
2. It should support methods.
3. It should return a closure, not a string. The reason is for
consistency with methods, where we want to capture the scope at the
Nicolas Grekas wrote:
> I wish this would return a Closure instead, making $foo::function the
> equivalent of Closure::fromCallable($foo).
I didn't include the following in that RFC, because I thought it would
be too controversial, but I think it's worth considering a new syntax
for this.
Given
> On Feb 10, 2020, at 10:18, Paul M. Jones wrote:
>
> 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
>
On Tue, 11 Feb 2020 at 14:19, Nikita Popov wrote:
>
> On Tue, Feb 11, 2020 at 1:43 PM Manuel Canga wrote:
>>
>> On Tue, 11 Feb 2020 at 13:16, Nicolas Grekas
>> wrote:
>> >
>> >
>> >
>> > Le mar. 11 févr. 2020 à 12:52, Diogo Galvao a écrit :
>> >>
>> >> On Tue, Feb 11, 2020 at 8:14 AM Manuel
On 11-02-2020 17:48, Dan Ackroyd wrote:
> I didn't include the following in that RFC, because I thought it would
> be too controversial, but I think it's worth considering a new syntax
> for this.
>
> Given the code:
>
> function foo();
> class Zoq {
> public function Fot() {}
> public
On Tue, 11 Feb 2020 at 19:08, Dik Takken wrote:
> $($obj->Fot);
> However, wrapped inside $(), which only accepts
> functions and methods
I don't think I meant that. I think it still should accept variables
as well, so it would still be ambiguous as to whether it referred to
the value of the
On Tue, 11 Feb 2020 at 17:49, Dan Ackroyd wrote:
>
> Nicolas Grekas wrote:
> > I wish this would return a Closure instead, making $foo::function the
> > equivalent of Closure::fromCallable($foo).
>
> I didn't include the following in that RFC, because I thought it would
> be too controversial,
wt., 11 lut 2020, 20:08 użytkownik Dik Takken
napisał:
> On 11-02-2020 17:48, Dan Ackroyd wrote:
> > I didn't include the following in that RFC, because I thought it would
> > be too controversial, but I think it's worth considering a new syntax
> > for this.
> >
> > Given the code:
> >
> >
Hi Mark,
> On Feb 10, 2020, at 11:02, Mark Randall wrote:
>
> I suspect this is a similar sentinment to the previous version, but I can
> personally see no major benefit to having this as a core extension.
>
> I think the reality is that discussing it "on its own merits" is to
> completely
On Tue, Feb 11, 2020 at 1:59 PM Reindl Harald (privat)
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 changing basic
On Tue, 11 Feb 2020 at 17:49, Dan Ackroyd wrote:
>
> Nicolas Grekas wrote:
> > I wish this would return a Closure instead, making $foo::function the
> > equivalent of Closure::fromCallable($foo).
>
> I didn't include the following in that RFC, because I thought it would
> be too controversial,
On Tue, Feb 11, 2020, at 9:27 AM, Levi Morrison via internals wrote:
> I have three immediate thoughts:
>
> 1. It should be `fn` or `function`; reserving a new word even if it's
> contextual is pointless here.
> 2. It should support methods.
> 3. It should return a closure, not a string. The
wt., 11 lut 2020, 18:42 użytkownik Manuel Canga
napisał:
> On Tue, 11 Feb 2020 at 17:49, Dan Ackroyd wrote:
> >
> > Nicolas Grekas wrote:
> > > I wish this would return a Closure instead, making $foo::function the
> > > equivalent of Closure::fromCallable($foo).
> >
> > I didn't include the
On 11-02-2020 20:01, Michał Brzuchalski wrote:
> wt., 11 lut 2020, 18:42 użytkownik Manuel Canga
> napisał:
>
> That reminds me an old draft RFC https://wiki.php.net/rfc/short-closures
> where I thought curly braces can be used to create closure from syntax
> nearly the same as invoking but
wt., 11 lut 2020, 21:14 użytkownik Dik Takken
napisał:
> On 11-02-2020 20:01, Michał Brzuchalski wrote:
> > wt., 11 lut 2020, 18:42 użytkownik Manuel Canga
> > napisał:
> >
> > That reminds me an old draft RFC https://wiki.php.net/rfc/short-closures
> > where I thought curly braces can be used
On 11-02-2020 20:20, Dan Ackroyd wrote:
> On Tue, 11 Feb 2020 at 19:08, Dik Takken wrote:
>
>> $($obj->Fot);
>> However, wrapped inside $(), which only accepts
>> functions and methods
>
> I don't think I meant that. I think it still should accept variables
> as well, so it would still be
54 matches
Mail list logo
