Re: [PHP-DEV] [RFC]

[Guilliam Xavier]

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 {}
const BAR = 2;
function qux() { return '3'; }

}

namespace Mine {

use Theirs\Foo as x;
use const Theirs\BAR as x;
use function Theirs\qux as x;

var_dump(new x); // object(Theirs\Foo)#1
var_dump(x); // int(2)
var_dump(x()); // string(1) "3"

// *** hypothetical: ***

assert(x::class === 'Theirs\Foo');
assert(x::const === 'Theirs\BAR');
assert(x::function === 'Theirs\qux');

assert(x::nameof === ???);

}
```

> Returning a _closure_ instead of a string would be providing a feature we 
> _already_ have instead of one we do _not_ have.
>
> If we had ::function returning a string we could use Closure::fromCallable() 
> to get a closure.  Or today just use fn() => myfunc().
>
> But if ::function instead returned a closure then there still would be no way 
> to extract the name of a function as a string from a symbol where PHP can 
> throw a warning if it does not recognize the symbol, such as in the case of a 
> typo.
>
> Seems to me having a shorter syntax to get a closure is an orthogonal concern.
>
> If we want a shorthand for closure we should create an additional syntax for 
> it but still provide a way to extract a function's name as a string from its 
> symbol since that is currently _not_ possible. Getting a closure from a 
> function symbol currently _is_ possible.
>
> Much better to provide  ::function to return the name of the function and 
> ::closure get a closure that can call the function.
>
> Or have  ::function to return the name of the function and provide a syntax 
> something like ${myfunc} to return a closure, which has been suggested later 
> in this thread.

That might deserve consideration indeed...

-- 
Guilliam Xavier

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Moving the documentation to git

[Andreas Heigl]

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 authors map from SVn to git and
pushed the result to git.php.net/doc. Now the docs are continuously
fetched from SVN, converted to git and pushed to their respective repos.
The english docs every 15 minutes and the translations every two hours.

Currently the leading system (the Single Source Of Truth) is still SVN!

But people can now already contribute via git to the docs as – at least
as far as I understood – the process of pushing changes from git to SVN
is more or less automated (correct me if I'm wrong here, Nikita/Peter).

Now the next steps are to move the toolage from SVN to git.

That means:

* Switch Source Retrieval for Docs building on docs.php.net from
svn.php.net to git.php.net
* Switch Generation of revcheck-files from svn to git (Work is already
done at
https://github.com/phpdoctest/doc-base/blob/master/scripts/revcheck.php)
* Verify that everything works as expected

When that is finished and accepted we can move over to the next stage:

* Switch Source Retrieval for Docs building on rsynv.php.net from SVN to git
* Setup Mirroring and processes to merge PRs from GitHub to
documentation git.
* Rewrite setup-instructions and send email to docs team regarding new
process

And then we can finally make SVN readonly.

(and the cronjobs on svngit.php.net need top be shut down)

I've also added the ToDo list to
https://github.com/phpdoctest/meta/wiki/todo, so that everyone can
follow the process.


As the next steps need access to euk2.php.net which I currently do not
have, I'd need someone to actually do those next tasks. Access –
according to the wiki – have bjori, mgdm, mj, nilgun, philip, salathe,
sobak, tyrael and yannick. I'd be very happy if one of you could ping me
so that we can check the next steps.

Thank you all for the support during the last weeks.

Cheers

Andreas



Am 04.02.20 um 08:09 schrieb Andreas Heigl:
> Hey folks.
> 
> During the last year I took a bit of time aside to bring the
> documentation from SVN to git. And about a month ago I informed the
> DOCs-Mailinglist about the current status and the fact that we are ready
> to move to the next step[1]. Now some tasks need to be done by people
> with appropriate karma to be able to get on with the whole thing, but
> all the background tasks are done and awaiting further processing.
> 
> Sadly there was no response so far. Neither on the email as such nor on
> the different tasks.
> 
> So the main question is now, how the PHP-Project wants to go on with
> moving the documentation from SVN to git? Is there any interest in
> continuing this project? And if so, who can either take on the necessary
> steps or provide us with the appropriate credentials and access rights
> that we can do them ourselves?
> 
> Thanks for reading and looking forward to the results.
> 
> Cheers
> 
> Andreas
> 
> [https://news-web.php.net/php.doc/969387429]
> 

-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC]

[Mike Schinkel]

> 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 of that accepts a function name, also accepts a callable (e.g.
> array_map), but I could be forgetting something.
> 
> If not, then I think it makes sense to return a callable. It might not be
> entirely consistent with the behavior of ::class, but, a class isn't
> entirely consistent with a method/function either, so I think there is some
> latitude for small differences.
> 
> As for the ::func vs ::function. I think ::function is safer, since it's a
> reserved word. Otherwise you might run into issues with something like this:
> 
> class foo {
>  const func = "bar";
> }
> 
> function foo(){}
> 
> echo foo::func;
> 
> Probably not something that happens very often, but, I think the 4 extra
> characters to prevent it would be worth it.---

Returning a _closure_ instead of a string would be providing a feature we 
_already_ have instead of one we do _not_ have.

If we had ::function returning a string we could use Closure::fromCallable() to 
get a closure.  Or today just use fn() => myfunc(). 

But if ::function instead returned a closure then there still would be no way 
to extract the name of a function as a string from a symbol where PHP can throw 
a warning if it does not recognize the symbol, such as in the case of a typo.

Seems to me having a shorter syntax to get a closure is an orthogonal concern. 

If we want a shorthand for closure we should create an additional syntax for it 
but still provide a way to extract a function's name as a string from its 
symbol since that is currently _not_ possible. Getting a closure from a 
function symbol currently _is_ possible.

Much better to provide  ::function to return the name of the function and 
::closure get a closure that can call the function.  

Or have  ::function to return the name of the function and provide a syntax 
something like ${myfunc} to return a closure, which has been suggested later in 
this thread. 

Or best would be to add ::nameof for functions, method, classes, interfaces and 
traits and provide access to closures using either ::closure or a new short 
syntax.

-Mike

P.S. A language I specialized in during the late 80's and early 90's called 
Clipper implemented closures with the following syntax:

- Without parameters:  {|| expr } equivalent to function(){ return expr; } and 
fn() => expr;
- With parameters:  {|a,b| expr } equivalent to function(a,b){ return expr; } 
and fn(a,b) => expr;

If we want a shorter syntax for function closures than fn() => myfunc() maybe 
we consider {|| myfunc() } which would be more general purpose than only 
returning a closure for a function?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Mike Schinkel]

> 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'], $array);
> It avoid add Full I18N  namespace in callback.
> 
> However with functions is different:
> 
> use function \My\I18N\i18n_translate;
> 
> $mapped_array = array_map('\My\I18N\i18n_translate', $array);
> 
> What is the useful here of importing the function?.
> My proposal is ":func" in order to avoid full namespace in callback of
> functions. E.g:
> 
> use function \My\I18N\i18n_translate;
> 
> $mapped_array = array_map(i18n_translate::func, $array);
> 
> "::func" should validate if a function with `` is imported.
> In this case, "::func" is replaced with FQN of this function,
> otherwise with only ""


I proposed ::function on the list a month ago:  
- https://externals.io/message/108045#108084

I had started by suggesting ::interface and ::trait: 
- https://externals.io/message/108045#108069

Marcio Almada suggested that we should use a general ::nameof instead: 
- https://externals.io/message/108045#108085

-Mike

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Michał Brzuchalski]

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 to create closure from syntax
> > nearly the same as invoking but without parentheses.
>
> My message mentioning just about the same idea crossed yours. Thanks for
> pointing at this RFC, I think it just caught our attention again. :)
>
> I quickly scanned the list to see if your RFC was discussed and all I
> could find was threads about a different RFC with almost identical name
> (https://wiki.php.net/rfc/short_closures). Has it not been discussed
> before?
>

No, it hasn't been discussed. It stopped at being a draft.

BR,
--
Michał Brzuchalski

>

Re: [PHP-DEV] [RFC]

[Dik Takken]

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 without parentheses.

My message mentioning just about the same idea crossed yours. Thanks for
pointing at this RFC, I think it just caught our attention again. :)

I quickly scanned the list to see if your RFC was discussed and all I
could find was threads about a different RFC with almost identical name
(https://wiki.php.net/rfc/short_closures). Has it not been discussed before?

Regards,
Dik Takken

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Dik Takken]

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 ambiguous as to whether it referred to
> the value of the property Fot of object $obj, or the method Fot on the
> $obj class.

In that case, the ambiguity issue remains. I was thinking about it as a
construct for wrapping functions and methods into closures. Could you
provide an example of how accepting variables would be useful?

>> another possibility could be: closure(foo);
> 
> That has the downside of exposing the implementation detail, that it's
> implemented through closures, which would be a regrettable choice if
> we ever decided to change the implementation details in the future.

I don't think I understand. Creating a closure is something you do
because of the specific semantics they have. The fact that it yields a
closure is not a detail, it is the reason why I would use it...

> And it also has the downside of looking like a function call, but
> having different rules for what can be put inside it:
> 
> function foo();
> closure(foo); // fine.
> special_closure(foo); // syntax error, undefined constant foo.

That is a downside indeed.

Regards,
Dik Takken

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Michał Brzuchalski]

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:
> >
> > function foo();
> > class Zoq {
> > public function Fot() {}
> > public static function Pik() {}
> > }
> > $obj = new Zoq();
> >
> >
> > Then these:
> >
> > $(foo);
> > $($obj, Fot);
> > $(Zoq, Fot);
> >
> > Would be equivalent to:
> >
> > Closure::fromCallable('foo');
> > Closure::fromCallable([$obj, 'Fot']);
> > Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq',
> 'Fot']);
> >
> > Or similar.
>
> Given the fact that $() would only accept functions and methods as
> argument, this idea could be taken one step further by writing:
>
> $(foo);
> $($obj->Fot);
> $(Zoq::Fot);
>
> Referring to a method like this is normally not possible because it is
> ambiguous. However, wrapped inside $(), which only accepts functions and
> methods, the ambiguity disappears.
>
> The $() syntax is nice and short. And something completely new. As new
> syntax can only be 'spent' once, more familiar alternatives should be
> explored as well. Thinking about the existing list() and array() syntax,
> another possibility could be:
>
> closure(foo);
> closure($obj->Fot);
> closure(Zoq::Fot);
>

It looks like a function but it's not a function cause what you have inside
parentheses looks like a const, property and class const.

IMO a statement like that for consistency it should be with no parentheses
like:

$foo = closure foo;
$foo = closure $obj->Fot;
$foo = closure Zoq::Fot;

Cheers,
--
Michał Brzuchalski

>

Re: [PHP-DEV] [RFC]

[Dan Ackroyd]

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 property Fot of object $obj, or the method Fot on the
$obj class.

Also, just in general using something that has the same syntax as
current PHP code, but a different meaning, sounds like a bad idea.

> another possibility could be: closure(foo);

That has the downside of exposing the implementation detail, that it's
implemented through closures, which would be a regrettable choice if
we ever decided to change the implementation details in the future.

And it also has the downside of looking like a function call, but
having different rules for what can be put inside it:

function foo();
closure(foo); // fine.
special_closure(foo); // syntax error, undefined constant foo.

 Although avoiding new syntax is good in general, if what can go
inside it is different, then I think it requires a new syntax.

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Dik Takken]

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 static function Pik() {}
> }
> $obj = new Zoq();
> 
> 
> Then these:
> 
> $(foo);
> $($obj, Fot);
> $(Zoq, Fot);
> 
> Would be equivalent to:
> 
> Closure::fromCallable('foo');
> Closure::fromCallable([$obj, 'Fot']);
> Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq', 'Fot']);
> 
> Or similar.

Given the fact that $() would only accept functions and methods as
argument, this idea could be taken one step further by writing:

$(foo);
$($obj->Fot);
$(Zoq::Fot);

Referring to a method like this is normally not possible because it is
ambiguous. However, wrapped inside $(), which only accepts functions and
methods, the ambiguity disappears.

The $() syntax is nice and short. And something completely new. As new
syntax can only be 'spent' once, more familiar alternatives should be
explored as well. Thinking about the existing list() and array() syntax,
another possibility could be:

closure(foo);
closure($obj->Fot);
closure(Zoq::Fot);

It is slightly longer but more familiar syntax.

On 11-02-2020 19:46, Larry Garfield wrote:
>
> I would love a nicer way to reference function names; it's really ugly
to do functional code in PHP otherwise, or even just dynamic function
logic within a namespace.  If I never have to write $fn = __NAMESPACE__
. '\a_func' again, it will be too soon. :-)

Perhaps Larry can convince us all to go for something like $() by
posting a fabulous functional programming example?

Regards,
Dik Takken

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Michał Brzuchalski]

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 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 static function Pik() {}
> > }
> > $obj = new Zoq();
> >
> >
> > Then these:
> >
> > $(foo);
> > $($obj, Fot);
> > $(Zoq, Fot);
> >
> > Would be equivalent to:
> >
> > Closure::fromCallable('foo');
> > Closure::fromCallable([$obj, 'Fot']);
> > Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq',
> 'Fot']);
> >
> > Or similar.
> >
> > The justification for having a dedicated syntax is that I think
> > readability is quite important in code, and it's reasonably common for
> > me to have quite long lists of 'callables'.
> >
> > [Bar::class, foo1::function],
> > [Bar::class, foo2::function],
> > [Bar::class, foo3::function],
> > [Bar::class, foo4::function]
> >
> > vs
> >
> > $(Bar, foo1),
> > $(Bar, foo2),
> > $(Bar, foo3),
> > $(Bar, foo4)
> >
> > The latter is far easier to read for me.
> >
> > Nikita Popov wrote:
> > > This would circumvent all the issues outlined in
> > > https://wiki.php.net/rfc/consistent_callables.
> >
> > Probably there would still be some issues with some of the weird stuff
> > happening internally in SPL related code where the deep horrors
> > rest...but we can leave them alone...and they might not wake.
> >
> > cheers
> > Dan
> > Ack
>
> Other option:
>
> Closure::fromCallable('foo');
> Closure::fromCallable([$obj, 'Fot']);
> Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq',
> 'Fot']);
>
> to
>
> 
> <$foo, Fot>
> 
> 
>
> E.g:
>
> array_map(, $array);
> array_map(, $array);
>
> Do you like ?
>

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 without parentheses.

That way we can provide clear intent - I mean if whatever is around: curly
braces or $ with parentheses IMHO it should be consistent with call like
format. For example:

$(strlen) or {strlen} for Closure::fromCallable('foo')

$($foo->Fot) or {$foo->Fot} for Closure::fromCallable([$obj, 'Fot'])

$(Zoq::Fot) or {Zoq::Fot} for Closure::fromCallable('Zoq::Fot')

Etc. The same inside like a call but wrapped in something and with no
parentheses part.

Cheers,
--
Michał Brzuchalski

>

Re: [PHP-DEV] [RFC]

[Larry Garfield]

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 reason is for
> consistency with methods, where we want to capture the scope at the
> time the closure is created, not ran. Imagine passing a private method
> as a callback; if it was done via `[$obj, 'privatemethod']` then it
> will fail at runtime, because the scope it's called in doesn't have
> access.

I would love a nicer way to reference function names; it's really ugly to do 
functional code in PHP otherwise, or even just dynamic function logic within a 
namespace.  If I never have to write $fn = __NAMESPACE__ . '\a_func' again, it 
will be too soon. :-)

I agree with Levi on points 2 and 3, for reasons already stated.

For bikeshedding on the syntax to use, I defer to the engine authors who can 
say what is possible to implement.  However, the guideline should be *short*.  
If we make referencing a function too verbose, no one will want to use it and 
readability will be harmed.  Double-whammy.  That's why I'd say adding ten 
characters (::function) is a definite no-no.

::fn would work.  There was previous discussion of ::name, which could then 
also apply to classes and objects.  That would be acceptable, I think.  

Other alternatives like &(funName) et al are also fine if they actually work; 
Again, I defer to the implementers on that.

But in general, yes please!

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Paul M . Jones]

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 ignore the wider ecosystem that already performs these functions, 
> with more capabilities, and with potentially hundreds of thousands of 
> implementations already in place.
> 
> Does it add capabilities which cannot exist in userland or cannot exist in a 
> reasonably performant way? Doesn't seem so except for a readonly property.
> 
> If not, leave it to userland.

I completely understand that sentiment; I recognize that it is shared by others 
on this list and elsewhere. But if you'll allow me, I'd like to present a 
counterargument in relation to previous PHP extensions.

When ext/pdo was added to core, there was already a "wider ecosystem that 
already performs these functions, with more capabilities, and with potentially 
hundreds of thousands of implementations already in place." Some of those 
implementations at the time included (I'm working from memory here) AdoDB, 
Metabase, MDB, PEAR_DB, and many more that I cannot recall.

PDO did not (to my knowledge) "add capabilities which cannot exist in userland 
or cannot exist in a reasonably performant way". (I'll grant that 
FETCH_INTO_OBJECT setting properties directly without using the constructor was 
not possible in userland, but that's an exception that tests the rule.) Indeed, 
PDO had a relatively reduced feature set in comparison to some of those 
userland libraries, especially AdoDB.

And yet, PDO has turned out to be of great benefit, because it brought together 
features into core that (figuratively speaking) everybody needed and was 
rewriting in userland over and over.

PDO is the strongest example here, but depending on how you count, there are 
2-3 other extensions that also serve: ext/date, ext/phar, and (reaching back to 
antiquity) ext/session.

So, there is a long history of widely-needed userland functionality being 
brought into core. I would say this RFC is a pretty tame example of doing so; 
the proposal presented here is very similar to the way PHP itself already does 
things, just wrapped in object properties and methods, and is very similar to 
how things are being done across a wide swath of userland.

Now, it is possible that the objections you raise *should* have prevented PDO 
(et al.) from going into core. If that is the case, and (in hindsight) we think 
it was a mistake to allow them, then consistency alone makes your objections 
valid here as well.

However, if (in hindsight) it was *not* a mistake to allow those extensions, 
then the raised objections are not especially strong arguments against this 
RFC. That's not to say "because PDO was allowed into core, this RFC must 
therefore be allowed into core" but to say "those objections alone were not a 
barrier to PDO, so they alone should not be a barrier to this RFC".

I hope that's an understandable counterargument, even if you don't agree with 
it.


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Manuel Canga]

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, but I think it's worth considering a new syntax
> for this.
>
> Given the code:
>
> function foo();
> class Zoq {
> public function Fot() {}
> public static function Pik() {}
> }
> $obj = new Zoq();
>
>
> Then these:
>
> $(foo);
> $($obj, Fot);
> $(Zoq, Fot);
>
> Would be equivalent to:
>
> Closure::fromCallable('foo');
> Closure::fromCallable([$obj, 'Fot']);
> Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq', 'Fot']);
>
> Or similar.
>
> The justification for having a dedicated syntax is that I think
> readability is quite important in code, and it's reasonably common for
> me to have quite long lists of 'callables'.
>
> [Bar::class, foo1::function],
> [Bar::class, foo2::function],
> [Bar::class, foo3::function],
> [Bar::class, foo4::function]
>
> vs
>
> $(Bar, foo1),
> $(Bar, foo2),
> $(Bar, foo3),
> $(Bar, foo4)
>
> The latter is far easier to read for me.
>
> Nikita Popov wrote:
> > This would circumvent all the issues outlined in
> > https://wiki.php.net/rfc/consistent_callables.
>
> Probably there would still be some issues with some of the weird stuff
> happening internally in SPL related code where the deep horrors
> rest...but we can leave them alone...and they might not wake.
>
> cheers
> Dan
> Ack

Other option:

Closure::fromCallable('foo');
Closure::fromCallable([$obj, 'Fot']);
Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq', 'Fot']);

to


<$foo, Fot>



E.g:

array_map(, $array);
array_map(, $array);

Do you like ?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Albert Casademont]

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 language behavior that way is not helpful for
> code meant to run everywhere and not stop working just because tomorrow
> someone changed a random ini setting
>

That could be said for all INI settings: yes they can break things if you
touch them without knowing what they do.

I think it might make sense to be able to disable superglobals and response
functions if your codebase is committed to using the new classes, much like
the old "register_globals" did. Why pollute the global namespace if you
don't need them?

Re: [PHP-DEV] [RFC]

[Manuel Canga]

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, but I think it's worth considering a new syntax
> for this.
>
> Given the code:
>
> function foo();
> class Zoq {
> public function Fot() {}
> public static function Pik() {}
> }
> $obj = new Zoq();
>
>
> Then these:
>
> $(foo);
> $($obj, Fot);
> $(Zoq, Fot);
>
> Would be equivalent to:
>
> Closure::fromCallable('foo');
> Closure::fromCallable([$obj, 'Fot']);
> Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq', 'Fot']);
>
> Or similar.
>
> The justification for having a dedicated syntax is that I think
> readability is quite important in code, and it's reasonably common for
> me to have quite long lists of 'callables'.
>
> [Bar::class, foo1::function],
> [Bar::class, foo2::function],
> [Bar::class, foo3::function],
> [Bar::class, foo4::function]
>
> vs
>
> $(Bar, foo1),
> $(Bar, foo2),
> $(Bar, foo3),
> $(Bar, foo4)
>
> The latter is far easier to read for me.
>
> Nikita Popov wrote:
> > This would circumvent all the issues outlined in
> > https://wiki.php.net/rfc/consistent_callables.
>
> Probably there would still be some issues with some of the weird stuff
> happening internally in SPL related code where the deep horrors
> rest...but we can leave them alone...and they might not wake.
>
> cheers
> Dan
> Ack

Hi, Dan,

I like it, although syntax reminds me to JQuery syntax.

Thanks

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Ben Ramsey]

> 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 
> functionality already existing in PHP, in order to reduce the global-state 
> problems that come with superglobals and the various response-related 
> functions.
> 
> The SQLite "about" page says, "Think of SQLite not as a replacement for 
> Oracle but as a replacement for fopen()."  
>  Likewise, think of this RFC not as a replacement for HttpFoundation or 
> PSR-7, or as a model of HTTP messages, but as an object-oriented alternative 
> to superglobals, header(), setcookie(), setrawcookie(), and so on.
> 
> Thanks in advance for your time and consideration while evaluating it.



Regarding the array of arrays for $accept* and $forwarded, what are your 
thoughts on using value objects with properties, rather than arrays with keys?


AcceptValue

* string $value
* string $quality
* array $params
* ?string $type
* ?string $subtype


ForwardedValue

* string $by
* string $for
* string $host
* string $proto


Cheers,
Ben


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC]

[Dan Ackroyd]

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 the code:

function foo();
class Zoq {
public function Fot() {}
public static function Pik() {}
}
$obj = new Zoq();


Then these:

$(foo);
$($obj, Fot);
$(Zoq, Fot);

Would be equivalent to:

Closure::fromCallable('foo');
Closure::fromCallable([$obj, 'Fot']);
Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq', 'Fot']);

Or similar.

The justification for having a dedicated syntax is that I think
readability is quite important in code, and it's reasonably common for
me to have quite long lists of 'callables'.

[Bar::class, foo1::function],
[Bar::class, foo2::function],
[Bar::class, foo3::function],
[Bar::class, foo4::function]

vs

$(Bar, foo1),
$(Bar, foo2),
$(Bar, foo3),
$(Bar, foo4)

The latter is far easier to read for me.

Nikita Popov wrote:
> This would circumvent all the issues outlined in
> https://wiki.php.net/rfc/consistent_callables.

Probably there would still be some issues with some of the weird stuff
happening internally in SPL related code where the deep horrors
rest...but we can leave them alone...and they might not wake.

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Manuel Canga]

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
> consistency with methods, where we want to capture the scope at the
> time the closure is created, not ran. Imagine passing a private method
> as a callback; if it was done via `[$obj, 'privatemethod']` then it
> will fail at runtime, because the scope it's called in doesn't have
> access.

Hi, Levi,

1. Yes
2. Yes, I agree
3. Wouldn't it be the opposite?. E.g:

class Foo {
static function run_callable(callable $callable) {
$callable();
}

private static function private_function() {
echo "bar";
}
}

Foo::run_callable( [ 'Foo', 'private_function' ] );


Currently, this is valid. However, the following is fatal:

class Foo {
static function run_callable(callable $callable) {
$callable();
}

private static function private_function() {
echo "bar";
}
}

Foo::run_callable(Closure::fromCallable(['Foo', 'private_function']));

The same with functions. If "::function" would retrieve a closure,
some code could breaking
when people switch string function syntax( e.g: 'strlen' )  to
"::function" syntax(  strlen::function ).

On other hand, other option is ::callable, This is different to
::function, because it would affect to other
callables, so that, returns could be other( Closure )

Re: [PHP-DEV] [RFC]

[Levi Morrison via internals]

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
time the closure is created, not ran. Imagine passing a private method
as a callback; if it was done via `[$obj, 'privatemethod']` then it
will fail at runtime, because the scope it's called in doesn't have
access.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Manuel Canga]

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, 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 = array_map(i18n_translate::func, $array);
>> > >> ...
>> > >> > What is your opinion ? Do you see it useful ?
>> > >>
>> > >> I've wished for this on many occasions and think it'd be really useful,
>> > as long
>> > >> as it could work with methods as well:
>> > >>
>> > >> $mapped_array = array_map(I18N::translate::function, $array);
>> > >>
>> > >> For what it's worth I guess it could just return [I18N::class,
>> > 'translate'].
>> > >
>> > >
>> > > I wish this would return a Closure instead, making $foo::function the
>> > equivalent of Closure::fromCallable($foo).
>> >
>> > Hi, Nicolas,
>> >
>> > Currently, when ::class is used, class with 
>> > can or cannot exists in that moment.
>> > Using ::func( or ::function ), I think
>> > should keep the same behavior.
>> >
>> > Using ::func as alias of "Closure::fromCallable" check if function
>> > exists in that moment. It is certainly useful, but, I think it's more
>> > important be consistent
>> >
>>
>> Checking whether the function exists is really unavoidable for functions,
>> because you don't know whether
>>
>> namespace Foo;
>> var_dump(strlen::function);
>>
>> refers to 'Foo\strlen' or 'strlen', without first trying to look up the
>> former.
>>
>> I agree with Nicolas that this kind of feature would provide the most value
>> if it created a Closure. This would circumvent all the issues outlined in
>> https://wiki.php.net/rfc/consistent_callables.
>>
>> Regards,
>> Nikita
>
>
> 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 of that accepts a function name, also accepts a callable (e.g. 
> array_map), but I could be forgetting something.
>
> If not, then I think it makes sense to return a callable. It might not be 
> entirely consistent with the behavior of ::class, but, a class isn't entirely 
> consistent with a method/function either, so I think there is some latitude 
> for small differences.
>
> As for the ::func vs ::function. I think ::function is safer, since it's a 
> reserved word. Otherwise you might run into issues with something like this:
>
> class foo {
>   const func = "bar";
> }
>
> function foo(){}
>
> echo foo::func;
>
> Probably not something that happens very often, but, I think the 4 extra 
> characters to prevent it would be worth it.
>
> --
> Chase Peeler
> chasepee...@gmail.com

Hi, Chase,

Yes, '::function' is better. I don't know because I thought 'func' was
used with short functions.
One case which string can be useful but a callable would not be acceptable is:

array_map([I18N::class, translate::function] );

Although it's true that can have side effects.

Thanks, Chase,

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Chase Peeler]

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 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 see it useful ?
> > >>
> > >> I've wished for this on many occasions and think it'd be really
> useful,
> > as long
> > >> as it could work with methods as well:
> > >>
> > >> $mapped_array = array_map(I18N::translate::function, $array);
> > >>
> > >> For what it's worth I guess it could just return [I18N::class,
> > 'translate'].
> > >
> > >
> > > I wish this would return a Closure instead, making $foo::function the
> > equivalent of Closure::fromCallable($foo).
> >
> > Hi, Nicolas,
> >
> > Currently, when ::class is used, class with 
> > can or cannot exists in that moment.
> > Using ::func( or ::function ), I think
> > should keep the same behavior.
> >
> > Using ::func as alias of "Closure::fromCallable" check if function
> > exists in that moment. It is certainly useful, but, I think it's more
> > important be consistent
> >
>
> Checking whether the function exists is really unavoidable for functions,
> because you don't know whether
>
> namespace Foo;
> var_dump(strlen::function);
>
> refers to 'Foo\strlen' or 'strlen', without first trying to look up the
> former.
>
> I agree with Nicolas that this kind of feature would provide the most value
> if it created a Closure. This would circumvent all the issues outlined in
> https://wiki.php.net/rfc/consistent_callables.
>
> Regards,
> Nikita
>

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 of that accepts a function name, also accepts a callable (e.g.
array_map), but I could be forgetting something.

If not, then I think it makes sense to return a callable. It might not be
entirely consistent with the behavior of ::class, but, a class isn't
entirely consistent with a method/function either, so I think there is some
latitude for small differences.

As for the ::func vs ::function. I think ::function is safer, since it's a
reserved word. Otherwise you might run into issues with something like this:

class foo {
  const func = "bar";
}

function foo(){}

echo foo::func;

Probably not something that happens very often, but, I think the 4 extra
characters to prevent it would be worth it.

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC]

[Manuel Canga]

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 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 see it useful ?
>> >>
>> >> I've wished for this on many occasions and think it'd be really useful, 
>> >> as long
>> >> as it could work with methods as well:
>> >>
>> >> $mapped_array = array_map(I18N::translate::function, $array);
>> >>
>> >> For what it's worth I guess it could just return [I18N::class, 
>> >> 'translate'].
>> >
>> >
>> > I wish this would return a Closure instead, making $foo::function the 
>> > equivalent of Closure::fromCallable($foo).
>>
>> Hi, Nicolas,
>>
>> Currently, when ::class is used, class with 
>> can or cannot exists in that moment.
>> Using ::func( or ::function ), I think
>> should keep the same behavior.
>>
>> Using ::func as alias of "Closure::fromCallable" check if function
>> exists in that moment. It is certainly useful, but, I think it's more
>> important be consistent
>
>
> Checking whether the function exists is really unavoidable for functions, 
> because you don't know whether
>
> namespace Foo;
> var_dump(strlen::function);
>
> refers to 'Foo\strlen' or 'strlen', without first trying to look up the 
> former.
>
> I agree with Nicolas that this kind of feature would provide the most value 
> if it created a Closure. This would circumvent all the issues outlined in 
> https://wiki.php.net/rfc/consistent_callables.
>
> Regards,
> Nikita

Thanks, Nikita. I don't know that RFC.

In that case, why don't use ::callable ?. This will be useful for
functions and others callable. E.g:

enqueue_task([I18n::class, 'translate']::callable);
enqueue_task(translate::callable);

Would it be hard to implement in PHP ?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

[Ben Ramsey]

> 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 argue that "string" is not a verb like "traverse",
>>> "serialize", "count", "throw" etc.
>>> Potential alternatives would be Stringifyable (or Stringifiable?),
>>> StringCastable, StringConvertible...
>>> (Even though I personally have no problem with "Stringable")
>>> 
>> Maybe StringObject? We do already have ArrayObject.
> 
> A StringObject would need to offer the same methods that are available
> for strings (even if ArrayObject doesn't do that completely).
> 
> Even if "string" isn't a verb, it matches the intended meaning:
> serialize -> Serializeable -> can be serialized
> count -> Countable -> can be counted
> throw -> Throwable -> can be thrown
> 
> If I take the alternatives into account, I would still opt for
> "Stringable" because it's:
> - easy to spell
> - easy to remember
> - shorter than the alternatives
> - matches exactly the intended meaning
> - consistent with the other PHP class nameings


In English, pretty much any noun can be used as a verb.

Also, string does have a verb form. It can mean “to thread on or as if on a 
string” or “to put together (words, ideas, etc.) like objects threaded on a 
string” or “to form into strings.”

In computing, a string is a series of characters that have been strung together.

https://www.merriam-webster.com/dictionary/string

:-)

Cheers,
Ben

Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

[Aimeos | Norbert Sendetzky]

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", "throw" etc.
>> Potential alternatives would be Stringifyable (or Stringifiable?),
>> StringCastable, StringConvertible...
>> (Even though I personally have no problem with "Stringable")
>>
> Maybe StringObject? We do already have ArrayObject.

A StringObject would need to offer the same methods that are available
for strings (even if ArrayObject doesn't do that completely).

Even if "string" isn't a verb, it matches the intended meaning:
serialize -> Serializeable -> can be serialized
count -> Countable -> can be counted
throw -> Throwable -> can be thrown

If I take the alternatives into account, I would still opt for
"Stringable" because it's:
- easy to spell
- easy to remember
- shorter than the alternatives
- matches exactly the intended meaning
- consistent with the other PHP class nameings

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Nikita Popov]

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 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 see it useful ?
> >>
> >> I've wished for this on many occasions and think it'd be really useful,
> as long
> >> as it could work with methods as well:
> >>
> >> $mapped_array = array_map(I18N::translate::function, $array);
> >>
> >> For what it's worth I guess it could just return [I18N::class,
> 'translate'].
> >
> >
> > I wish this would return a Closure instead, making $foo::function the
> equivalent of Closure::fromCallable($foo).
>
> Hi, Nicolas,
>
> Currently, when ::class is used, class with 
> can or cannot exists in that moment.
> Using ::func( or ::function ), I think
> should keep the same behavior.
>
> Using ::func as alias of "Closure::fromCallable" check if function
> exists in that moment. It is certainly useful, but, I think it's more
> important be consistent
>

Checking whether the function exists is really unavoidable for functions,
because you don't know whether

namespace Foo;
var_dump(strlen::function);

refers to 'Foo\strlen' or 'strlen', without first trying to look up the
former.

I agree with Nicolas that this kind of feature would provide the most value
if it created a Closure. This would circumvent all the issues outlined in
https://wiki.php.net/rfc/consistent_callables.

Regards,
Nikita

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Paul M. Jones]

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,
> 
> thanks for bringing it back. Got some questions:
> 
> 1. In your RFC $_ENV is bound to $request.
> 
> Looking at HttpFoundation can see it's build from $_GET, $_POST, $_FILES, 
> $_COOKIE, $_SESSION and then looking at PSR ServerSideRequest it's build from 
> $_COOKIE, $_GET, $_POST, $_FILES, $_SERVER but none of them bounds $_ENV.
> 
> Server environment variables basically don't change over time when server 
> process runs. What is the specific use case that requires them to be coupled 
> with $request instance?

I have no specific use case; I recall that $_ENV showed up in more than a 
couple of reviewed implementations, and so included it here. If there is no 
objection from John Boehr (who did the majority of heavy lifting C), or from 
anyone else, then I would be fine with removing the ENV-related element. I have 
no strong feelings on $_ENV representation either way.


> 2. In your RFC all headers are mapped to $request properties
> 
> This behaviour is unclear and unusual to me, for eg. in summary can see that 
> if server request has "Header-Name" it is found in 
> $_SERVER["HTTP_HEADER_NAME"] and that one is bound to 
> $request->headers["header-name"], ok but the next line with example for 
> "Content-Type" shows that it's bound to $request->contentType - which means
> probably that it can be accessed in $request->headers["content-type"] as 
> well, right? seems logic.

I'm not sure if that is a question/comment/criticism, or a statement of "OK so 
far, but ...". Please bear with me, so I can make sure I'm addressing your 
question properly.

First: Not *all* headers are mapped to $request properties; the only ones that 
get special $request properties are the ones that showed up as frequently 
getting special treatment in other implementations.

Next: the $header array is populated by all $_SERVER['HTTP_*'] values, plus 
$_SERVER['CONTENT_TYPE'] and $_SERVER['CONTENT_LENGTH']. The latter two do not 
follow the 'HTTP_*' pattern because of RFC 3875; they come in as (e.g.) 
`Content-Type: text/plain`, so you might expect $_SERVER['HTTP_CONTENT_TYPE'], 
but RFC 3875 dictates otherwise.

Finally: yes, $request->header['content-type'] is available at the same time as 
$request->contentType, but they are not quite the same thing. The Content-Type 
header also allows you to specify a charset, which value gets populated into 
$request->contentCharset. So, you can read these values these ways:

- $request->header['content-type'] => 'text/plain; charset=UTF-8' (the original 
header)
- $request->contentType => 'text/plain' (parsed out by ServerRequest)
- $request->contentCharset => 'UTF-8' (parsed out by ServerRequest)

Likewise, PHP puts `Content-Length: 123' into $_SERVER['CONTENT_LENGTH']; 
ServerRequest additionally puts it into $request->headers['content-length'] as 
a string; and then further tries to represent the value as an integer in 
$request->contentLength. So:

- $request->server['CONTENT_LENGTH'] => (string) '123'
- $request->headers['content-length'] => (string) '123'
- $request->contentLength => (int) 123

My apologies if all of that was stuff you already knew and understood. (And if 
you did not already know it, maybe that means I should write up a narrative of 
the logic being applied.)


> Going further, for eg. $_SERVER["PHP_AUTH_PW"] is bound to $request->authPw 
> and then what will happen if the request will receive "Auth-Pw" header?

In that example, PHP would populate two $_SERVER elements: 'PHP_AUTH_PW' from 
the password, and 'HTTP_AUTH_PW' from the header. ServerRequest only populates 
PHP_AUTH_PW into $authPw; the HTTP_AUTH_PW value would (per the above 
description) go into $request->headers['auth-pw'].

I hope that made sense; let me know if it did not.


> With those above I would see a set of getters like getContentType() or 
> getAuthPassword() etc. instead of ServerRequest instance properties and a 
> single point to retrieve header values just like well known ParameterBag's 
> from HttpFoundation to operate on get, post, headers etc.

Does the above explanation help to modify your preferences here? If not, we can 
continue talking about it.


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

[Guilliam Xavier]

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 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 because it is the most consistent to me:
>> > 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", "throw" etc.
>> Potential alternatives would be Stringifyable (or Stringifiable?),
>> StringCastable, StringConvertible...
>> (Even though I personally have no problem with "Stringable")
>>
>
> Maybe StringObject? We do already have ArrayObject.

But ArrayObject is not a interface (ArrayAccess is).

-- 
Guilliam Xavier

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

[Michał Brzuchalski]

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: ToString, HasToString, CastsToString.
> > >
> >
> > Naming things...
> > I'm not sure reddit is the way to lobby php-internals...
> > I proposed Stringable because it is the most consistent to me:
> > 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", "throw" etc.
> Potential alternatives would be Stringifyable (or Stringifiable?),
> StringCastable, StringConvertible...
> (Even though I personally have no problem with "Stringable")
>
>
Maybe StringObject? We do already have ArrayObject.

BR,
--
Michał Brzuchalski

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Reindl Harald (privat)]

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 stop working just because tomorrow
someone changed a random ini setting

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

[Guilliam Xavier]

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 sure reddit is the way to lobby php-internals...
> I proposed Stringable because it is the most consistent to me:
> 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", "throw" etc.
Potential alternatives would be Stringifyable (or Stringifiable?),
StringCastable, StringConvertible...
(Even though I personally have no problem with "Stringable")

-- 
Guilliam Xavier

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Manuel Canga]

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 '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 short closures / array functions use `fn`, not `func`.
> But `::fn` would look... weird.
> I agree with Diogo that `::function` would be more consistent.
>
> --
> Guilliam Xavier

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Guilliam Xavier]

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 short closures / array functions use `fn`, not `func`.
But `::fn` would look... weird.
I agree with Diogo that `::function` would be more consistent.

-- 
Guilliam Xavier

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Manuel Canga]

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.
>> ...
>> > use function \My\I18N\i18n_translate;
>> >
>> > $mapped_array = array_map(i18n_translate::func, $array);
>> ...
>> > What is your opinion ? Do you see it useful ?
>>
>> I've wished for this on many occasions and think it'd be really useful, as 
>> long
>> as it could work with methods as well:
>>
>> $mapped_array = array_map(I18N::translate::function, $array);
>>
>> For what it's worth I guess it could just return [I18N::class, 'translate'].
>
>
> I wish this would return a Closure instead, making $foo::function the 
> equivalent of Closure::fromCallable($foo).

Hi, Nicolas,

Currently, when ::class is used, class with 
can or cannot exists in that moment.
Using ::func( or ::function ), I think
should keep the same behavior.

Using ::func as alias of "Closure::fromCallable" check if function
exists in that moment. It is certainly useful, but, I think it's more
important be consistent

Thanks, Nicolas,

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Albert Casademont]

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 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
> > global-state problems that come with superglobals and the various
> > response-related functions.
>
> 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.
> Speaking of interfaces: since you suggest using decoration and
> composition over extension for ServerResponse, I am missing a
> ServerResponseInterface, so that you can easily typehint such userland
> decorators.
>
> --
> Jan Schneider
> The Horde Project
> https://www.horde.org/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [RFC] deprecate md5_file and sha1_file

[Thomas Hruska]

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 won't.

At best it will make people switch to the hash function. At worst people
will not upgrade.

If people are using the existing md5 / sha1 algorithms, chances are it's
because they're actually wanting to get a hash to compare to something
that has already been stored.

There's not much point in deprecating the algorithm if we don't
eventually plan to remove it, and there is an exactly zero percent
chance of it being removed at any point in the next 50 years.

Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Why? What does deprecating those two functions do to make PHP a better
language? It doesn't add any new features. It doesn't fix any security
issues. It doesn't even take away the ability to perform the functionality
that they provide, since it still exists in the hash_file function.

If you don't like the function, then don't use it.


I'd be fine with someone just adding a Warning to the documentation that 
MD5 and SHA-1 are known broken hashing algorithms when used for 
*cryptographic/security* purposes.  The algorithms and related functions 
are completely fine though for other purposes such as detecting 
single-bit changes in file data where something a little more robust 
than CRC32 is needed but don't want to waste a lot of storage space. 
md5() and sha1() already have basic warnings applied.


--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Nicolas Grekas]

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 = array_map(i18n_translate::func, $array);
> ...
> > What is your opinion ? Do you see it useful ?
>
> I've wished for this on many occasions and think it'd be really useful, as
> long
> as it could work with methods as well:
>
> $mapped_array = array_map(I18N::translate::function, $array);
>
> For what it's worth I guess it could just return [I18N::class,
> 'translate'].
>

I wish this would return a Closure instead, making $foo::function the
equivalent of Closure::fromCallable($foo).

Nicolas

Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

[Nicolas Grekas]

>
> 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 because it is the most consistent to me:
Traversable, Serializable, Countable, Throwable, JsonSerializable
all are related to some special engine behavior, which this ones also is.
I'm on the side of keeping Stringable.



> Something to keep in mind is that there has been a recent proposal for
> "Arrayable" as well, and that had very different semantics (not about
> __toArray() at all)
>

I didn't take part on this discussion, but I'm totally on Marco's side on
this one, I really hope this will NOT make it into the engine, for the
reasons he gives... :)

Nicolas

Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

[Aimeos | Norbert Sendetzky]

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 interfaces like
Throwable, Countable, Traversable, Serializable and so on :-)

> Something to keep in mind is that there has been a recent proposal for
> "Arrayable" as well, and that had very different semantics (not about
> __toArray() at all).

I came up with the proposal of an Arrayable interface whose intention is
in fact very close to Stringable (can be used like an array and
converted to array vs. can be converted to string)

But time doesn't seem to be ripe for Arrayable because the __toArray()
RFC isn't accepted yet and there needs to be more discussion if
Arrayable should only contain __toArray() or if it should extend from
Countable and Traversable too.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Manuel Canga]

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, 11 Feb 2020 at 12:51, Diogo Galvao  wrote:
>
> 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 see it useful ?
>
> I've wished for this on many occasions and think it'd be really useful, as 
> long
> as it could work with methods as well:
>
> $mapped_array = array_map(I18N::translate::function, $array);
>
> For what it's worth I guess it could just return [I18N::class, 'translate'].
>
> Also for keeping consistency and avoiding new keywords wouldn't it fit better 
> as
> ::function instead of ::func?
>
>
> Best regards.
> Diogo

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

[Nikita Popov]

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 discussion for adding a
> >> "Stringable" interface to PHP 8.
> >>
> >> The RFC and its rationale are presented here as required:
> >> https://wiki.php.net/rfc/stringable
> >>
> >> The patch is found on GitHub, where some discussions happened already,
> you
> >> might be interested in having a look:
> >> https://github.com/php/php-src/pull/5083
> >>
> >> TL;DR, I think we need an interface to allow passing objects with a
> >> __toString() method in a type-safe way, using the string|Stringable
> type.
> >> Here is the stub of the proposal:
> >> interface Stringable { public function __toString(): string; }
> >>
> >> I invite everyone to review the RFC before commenting here as I tried to
> >> sum up considerations that some already had before and that you might
> have
> >> too.
> >>
> >> Cheers,
> >> Nicolas
> >>
> >
> > I'm wondering whether it could make sense to automatically implement this
> > interface for all classes that define __toString(). Explicitly
> implementing
> > the interface is useful for the transition period (where old PHP versions
> > also need to be supported), but when considering only PHP 8 support, I
> > think it may make sense to implicitly implement the interface. If the
> > __toString() functionality also works fine without implementing the
> > interface, and there's probably only going to be relatively few consumers
> > of the Stringable type, it will likely be quite common that the interface
> > will not get implemented...
> >
>
>
> This proposal has been implemented by Nikita himself on the linked PR, see
> 2nd commit:
> https://github.com/php/php-src/pull/5083
>
> I updated the RFC accordingly:
> https://wiki.php.net/rfc/stringable
>
> I think the RFC is ready for entering the voting stage.
> Any other comments before?
>

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.

Something to keep in mind is that there has been a recent proposal for
"Arrayable" as well, and that had very different semantics (not about
__toArray() at all).

Regards,
Nikita

Re: [PHP-DEV] [RFC]

[Diogo Galvao]

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 see it useful ?

I've wished for this on many occasions and think it'd be really useful, as long
as it could work with methods as well:

$mapped_array = array_map(I18N::translate::function, $array);

For what it's worth I guess it could just return [I18N::class, 'translate'].

Also for keeping consistency and avoiding new keywords wouldn't it fit better as
::function instead of ::func?


Best regards.
Diogo

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Manuel Canga]

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:
>
> 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 programming languages in order to shorten the notation further:
>
> > // First file.
> > namespace A\B;
> >
> > function foo() { }
> >
> > // Second file.
> > use function A\B\foo;
> >
> > function bar(callable $c) { }
> >
> >
> > // Current approach.
> > bar('\A\B\foo');
> >
> > // Notation without parantheses, references imported function.
> > // Similarly, in the future, Class::method could reference a
> > // class method.
> > bar(foo);
> >
> > // Notation with references, could be expanded in the future
> > // for static class methods, such as ::method.
> > bar();
>
> The second example can already be achieved by defining your own
> constant that references the fully qualified name and importing it.
> However, an explicit, separate, import of these constants is still
> needed, which is not ideal.
>
> A suffix "::func" would also be useful, but allowing shorter notation
> would improve readability when using the functional programming
> paradigm and composing functions.
>
> Op di, feb 11, 2020 at 12:13 schreef Manuel Canga
> :
> > 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 functions is different:
> >
> > use function \My\I18N\i18n_translate;
> >
> > $mapped_array = array_map('\My\I18N\i18n_translate', $array);
> >
> > What is the useful here of importing the function?.
> > My proposal is ":func" in order to avoid full namespace in callback of
> > functions. E.g:
> >
> > use function \My\I18N\i18n_translate;
> >
> > $mapped_array = array_map(i18n_translate::func, $array);
> >
> > "::func" should validate if a function with `` is
> > imported.
> > In this case, "::func" is replaced with FQN of this function,
> > otherwise with only ""
> >
> > What is your opinion ? Do you see it useful ?
> >
> > Thanks and I'm sorry for my English( I'm a Spanish ).
> >
> > Regards
>
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]

[Tom Gerrits]

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 programming languages in order to shorten the notation further:



// First file.
namespace A\B;

function foo() { }

// Second file.
use function A\B\foo;

function bar(callable $c) { }


// Current approach.
bar('\A\B\foo');

// Notation without parantheses, references imported function.
// Similarly, in the future, Class::method could reference a
// class method.
bar(foo);

// Notation with references, could be expanded in the future
// for static class methods, such as ::method.
bar();


The second example can already be achieved by defining your own 
constant that references the fully qualified name and importing it. 
However, an explicit, separate, import of these constants is still 
needed, which is not ideal.


A suffix "::func" would also be useful, but allowing shorter notation 
would improve readability when using the functional programming 
paradigm and composing functions.


Op di, feb 11, 2020 at 12:13 schreef Manuel Canga 
:

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 functions is different:

use function \My\I18N\i18n_translate;

$mapped_array = array_map('\My\I18N\i18n_translate', $array);

What is the useful here of importing the function?.
My proposal is ":func" in order to avoid full namespace in callback of
functions. E.g:

use function \My\I18N\i18n_translate;

$mapped_array = array_map(i18n_translate::func, $array);

"::func" should validate if a function with `` is 
imported.

In this case, "::func" is replaced with FQN of this function,
otherwise with only ""

What is your opinion ? Do you see it useful ?

Thanks and I'm sorry for my English( I'm a Spanish ).

Regards


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] ::func resolution for functions

[Manuel Canga]

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;
>
> $mapped_array = array_map([I18N::class, 'translate'], $array);
> It avoid add Full I18N  namespace in callback.
>
> However with functions is different:
>
> use function \My\I18N\i18n_translate;
>
> $mapped_array = array_map('\My\I18N\i18n_translate', $array);
>
> What is the useful here of importing the function?.
> My proposal is ":func" in order to avoid full namespace in callback of 
> functions. E.g:
>
> use function \My\I18N\i18n_translate;
>
> $mapped_array = array_map(i18n_translate::func, $array);
>
> "::func" should validate if a function with `` is imported. 
> In this case, "::func" is replaced with FQN of this function, 
> otherwise with only ""
>
> What is your opinion ? Do you see it useful ?
>
> Thanks and I'm sorry for my English( I'm a Spanish ).
>
> Regards
>
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] deprecate md5_file and sha1_file

[Peter Bowyer]

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 they do exactly what
> people want.
>

I agree. It isn't wrong to use MD5 or SHA1 in the right situation (or even
CRC32). The documentation can tell people when they can use these
algorithms, and when they must not think about using them. Mark them in the
documentation as "RECOMMENDED DO NOT USE" and guide people away.

Peter

[PHP-DEV] [RFC]

[Manuel Canga]

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 functions is different:

use function \My\I18N\i18n_translate;

$mapped_array = array_map('\My\I18N\i18n_translate', $array);

What is the useful here of importing the function?.
My proposal is ":func" in order to avoid full namespace in callback of
functions. E.g:

use function \My\I18N\i18n_translate;

$mapped_array = array_map(i18n_translate::func, $array);

"::func" should validate if a function with `` is imported.
In this case, "::func" is replaced with FQN of this function,
otherwise with only ""

What is your opinion ? Do you see it useful ?

Thanks and I'm sorry for my English( I'm a Spanish ).

Regards

[PHP-DEV] Re: [VOTE] Variable syntax tweaks

[Nikita Popov]

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.

Regards,
Nikita

[PHP-DEV] Re: [VOTE] Allow ::class on objects

[Nikita Popov]

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

[PHP-DEV] Re: [VOTE] Static return type

[Nikita Popov]

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

[PHP-DEV] [Pre-RFC] Support for decorator patterns

[Nikita Popov]

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 playing with this thought for a while, and decided to try this
out now, because typed properties in PHP 7.4 offer a very nice syntax
choice for this feature.

Any initial thoughts?

Regards,
Nikita

Re: [PHP-DEV] [RFC] deprecate md5_file and sha1_file

[AllenJB]

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 think, basically two scenarios 
developers find themselves in:


1) I'm using an API or some other external service and that requires the 
use of md5 / sha1 - I don't have a choice


2) What do I use instead? Internet searches return "sha1 / md5 is fine 
for this purpose" or recommend algorithms that aren't natively supported 
in PHP.


The (hash library) documentation does nothing towards helping developers 
decide what algorithms (or even which hash library functions) they 
should use for what purposes (and there are a lot of acronyms that many 
developers are likely to have never encountered that are never explained 
- HMAC, PBKDF2, HKDF).


Yes, of course developers can use third party sources to supplement the 
information in the manual, but who has time to go seartching for that 
(esp. when most of the first page on Google probably tells you md5/sha1 
is fine anyway)?


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 they do exactly what 
people want.


AllenJB

On 10/02/2020 21:49, Tom Van Looy via internals wrote:

Hi

While in some environments the use of MD5 and SHA1 are still acceptable for
some use cases like file integrity verification etc. the use of these
algorithms should be discouraged and not be your choice when developing new
applications.

I suggest to deprecated the functions md5_file() and sha1_file(). This will
make people think about upgrading to a better alternative. If you still
need this functionality you can always switch to the hash_file() function.

Carrying around these two dedicated functions seems a bit too much for a
modern PHP. What do you think?

My feeling was that this is a no brainer. Should I open an RFC for this?

Kind regards,

Tom Van Looy



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Jan Schneider]

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 order to reduce the  
global-state problems that come with superglobals and the various  
response-related functions.


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.
Speaking of interfaces: since you suggest using decoration and  
composition over extension for ServerResponse, I am missing a  
ServerResponseInterface, so that you can easily typehint such userland  
decorators.


--
Jan Schneider
The Horde Project
https://www.horde.org/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

[Nicolas Grekas]

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 and its rationale are presented here as required:
>> https://wiki.php.net/rfc/stringable
>>
>> The patch is found on GitHub, where some discussions happened already, you
>> might be interested in having a look:
>> https://github.com/php/php-src/pull/5083
>>
>> TL;DR, I think we need an interface to allow passing objects with a
>> __toString() method in a type-safe way, using the string|Stringable type.
>> Here is the stub of the proposal:
>> interface Stringable { public function __toString(): string; }
>>
>> I invite everyone to review the RFC before commenting here as I tried to
>> sum up considerations that some already had before and that you might have
>> too.
>>
>> Cheers,
>> Nicolas
>>
>
> I'm wondering whether it could make sense to automatically implement this
> interface for all classes that define __toString(). Explicitly implementing
> the interface is useful for the transition period (where old PHP versions
> also need to be supported), but when considering only PHP 8 support, I
> think it may make sense to implicitly implement the interface. If the
> __toString() functionality also works fine without implementing the
> interface, and there's probably only going to be relatively few consumers
> of the Stringable type, it will likely be quite common that the interface
> will not get implemented...
>


This proposal has been implemented by Nikita himself on the linked PR, see
2nd commit:
https://github.com/php/php-src/pull/5083

I updated the RFC accordingly:
https://wiki.php.net/rfc/stringable

I think the RFC is ready for entering the voting stage.
Any other comments before?

Cheers,
Nicolas