Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

[Ryan Pallas]

On Tue, Feb 6, 2018 at 8:24 AM, Larry Garfield 
wrote:
>
>
> That said, I'm not sure that function autoloading will be that big of a
> carrot
> for the major projects at this point.  Wordpress is going to ignore
> anything
> we do here anyway for at least 15 years, and pretty much every other
> project
> in existence has gone all-OOP or nearly-all-OOP at this point (good or bad
> is
> beside the point).  Namespaced user defined functions are rare in my
> experience
> outside of very specific libraries (such as functional tooling libs).  So
> "yay,
> you can now autoload namespaced user-defined functions" will likely be met
> with
> a lot of "what are those?"
>
>
I disagree with this assessment. Many functions are actually collected in
static classes so they can be autoloaded. So instead of,

namespace Foo\Bar;

class Map {
public static function modelToApi(Model $model) : array {}
}

The function can now just be in a namespace directly, instead of treating a
class like a namespace. You can then also import just the function you
need, instead of the whole class. Many of these classes exist in projects
I've worked on just for the purpose of being able to autoload the functions
when needed. My 2 cents.


> --Larry Garfield

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Ryan Pallas]

On Thu, Jan 25, 2018 at 9:21 AM, Derick Rethans <der...@php.net> wrote:

> On Thu, 25 Jan 2018, Ryan Pallas wrote:
>
> > On Thu, Jan 25, 2018 at 7:52 AM, Derick Rethans <der...@php.net> wrote:
> >
> > > On Wed, 24 Jan 2018, Michael Morris wrote:
> > >
> > > > Ok, here's another idea I've been mulling over. This I know is
> possible
> > > > because I've done it using user land code, specifically Drupal 8's
> > > > Assertion\Inspector class.
> > > >
> > > > https://api.drupal.org/api/drupal/core%21lib%21Drupal%
> > > 21Component%21Assertion%21Inspector.php/class/Inspector/8.5.x
> > > >
> > > > These methods provide a means to inspect collections - arrays
> usually but
> > > > also Traversables. They fill a hole in the PHP library - the ability
> to
> > > > check collection integrity.
> > >
> > > IMO, it makes a lot more sense to check integrity when creating the
> > > "array" structure. Instead, I would suggest to add a native Collection
> > > type, that takes a "type" as argument. They aren't quite full generics,
> > > but it does 1. fix something; 2. isn't really complicated.
> > >
> > > What I am suggesting is to add a new syntax "Collection<$type>",
> > > mimicking a class, but having a type as "argument":
> > >
> > >
> > Just like to point out if it's considered a class, or takes the same
> space
> > there is likely collisions. While most collection classes on github look
> to
> > be in a namespace, there are lots that aren't. Of course github only
> gives
> > us a view of open source projects that happen to be on github.
>
> PHP owns the top-level namespace. It has always done that. It's even
> documented: http://docs.php.net/manual/en/userlandnaming.rules.php


And yet, it's a point of contention that every proposal adding to the root
namespace has faced.


>
>
> cheers,
> Derick
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> or become my Patron: https://www.patreon.com/derickr
> twitter: @derickr and @xdebug
>

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Ryan Pallas]

On Thu, Jan 25, 2018 at 7:52 AM, Derick Rethans  wrote:

> On Wed, 24 Jan 2018, Michael Morris wrote:
>
> > Ok, here's another idea I've been mulling over. This I know is possible
> > because I've done it using user land code, specifically Drupal 8's
> > Assertion\Inspector class.
> >
> > https://api.drupal.org/api/drupal/core%21lib%21Drupal%
> 21Component%21Assertion%21Inspector.php/class/Inspector/8.5.x
> >
> > These methods provide a means to inspect collections - arrays usually but
> > also Traversables. They fill a hole in the PHP library - the ability to
> > check collection integrity.
>
> IMO, it makes a lot more sense to check integrity when creating the
> "array" structure. Instead, I would suggest to add a native Collection
> type, that takes a "type" as argument. They aren't quite full generics,
> but it does 1. fix something; 2. isn't really complicated.
>
> What I am suggesting is to add a new syntax "Collection<$type>",
> mimicking a class, but having a type as "argument":
>
>
Just like to point out if it's considered a class, or takes the same space
there is likely collisions. While most collection classes on github look to
be in a namespace, there are lots that aren't. Of course github only gives
us a view of open source projects that happen to be on github.


> $a = new Collection;
>
> And then $a can act as if you'd use an ArrayAccess'ed class.
> Upon each set or update, the type of the value can then be checked
> against the type.
>
> Consequently, this would also mean you can type hint on Collection
> instead of for example an earlier suggested array of type, where upon
> passing in the array each member was checked for its type (slow).
>
> And on top of this, this could be extended to do proper generics too.
>
> cheers,
> Derick
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> or become my Patron: https://www.patreon.com/derickr
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

[Ryan Pallas]

On Fri, Oct 13, 2017 at 3:40 AM, Thomas Punt  wrote:

> Morning internals,
>
>
> I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more
> flexible[1]. Any thoughts?
>

I really like this, and I don't think it's that hard to not use the marker
in the body at the far left of a line unattached to other characters. In my
experience, people that use these syntaxes (like me) already make sure not
to use something within the body.


>
>
> Thanks,
>
> Tom
>
>
> [1]: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes
>

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

[Ryan Pallas]

On Fri, Sep 15, 2017 at 11:50 AM, Sara Golemon  wrote:

> On Fri, Sep 15, 2017 at 1:35 PM,   wrote:
> > The `extract` function takes an associative array and
> > puts it into the local symbol table.
> > http://php.net/manual/en/function.extract.php
> >
> > I seriously doubt the usefulness of this function,
> > especially looking at the potential risks. The fact
> > that overwriting the local variables is the default
> > behaviour doesn’t make it any better. I suggest
> > deprecating it in PHP 7.3 and removing it in 8.
> >
> Preface: I despise extract() as well.  It's breaks assumptions for
> both the developer and the runtime.  I save some of my frowniest of
> faces for extract().
>
> That said...
>
> > I can see it’s usefulness in this case.
> > But wouldn’t it be better to implement this by hand
> > in these rare cases (it’s 3 lines of code) instead of
> > encouraging the pollution of the symbol table by
> > unknown input? It’s also clearer since people who
> > don’t know the `extract` function probably don’t
> > expect it to mutate the local symbol table.
> >
> Let's be clear on what that looks like: foreach ($data as $key =>
> $value) { $$key = $value; }
>
> This is SO MUCH WORSE for several reasons, no least of all what
> happens when $data contains keys named 'data', 'key', or 'value'.
>

This is a very good point. I hadn't thought about keys being named that
way, but obviously they could! *grumble*


>
> I'd like to kill extract(), but it does have a reason for being, and I
> couldn't in any good conscience support removing it without a
> replacement that's at least marginally better.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

[Ryan Pallas]

On Fri, Sep 15, 2017 at 11:38 AM, <ilija.tov...@me.com> wrote:

> Hi Ryan
>
> I can see your argument. The reasoning behind it is that a function in the
> standard library should not encourage unsafe code. Admittedly, since this
> function is rarely used except for templating systems one could call this a
> non-issue. I just wanted to bring it up.
>

That makes sense. What about performance difference? On a reasonable sized
array (not 10k items and not 2) which is faster?

extract($array);

- or -

foreach ($array as $key => $value)
$$key = $value;

Honestly, I don't know (ps 2 lines without braces instead of 3!)


>
> Regards
>
>
> On 15 Sep 2017, 19:30 +0200, Ryan Pallas <derokor...@gmail.com>, wrote:
>
>
>
> On Sep 15, 2017 11:22 AM, <ilija.tov...@me.com> wrote:
>
> Hi!
>
> The `extract` function takes an associative array and puts it into the
> local symbol table.
> http://php.net/manual/en/function.extract.php
>
> ```
> $array = [
> ‘foo’ => ‘foo’,
> ‘bar’ => ‘bar’,
> ];
>
> extract($array);
>
> print $foo; // "foo"
> ```
>
> As a second parameter the `extract` function takes some options to make
> this function less dangerous, like `EXTR_SKIP` that prevents an existing
> local variable of being overwritten. There’s a few more options, go ahead
> and take a look at the documentation. `EXTR_OVERWRITE` is the default one
> though. You can also pass a prefix for the variable names as a third
> argument.
>
> I seriously doubt the usefulness of this function, especially looking at
> the potential risks. The fact that overwriting the local variables is the
> default behaviour doesn’t make it any better. I suggest deprecating it in
> PHP 7.3 and removing it in 8.
>
> In a whole Symfony-Stack (3.4) with all of it’s dependencies I could only
> find two usages of this function, both of which could be easily rewritten
> in vanilla PHP:
> https://github.com/symfony/symfony/blob/master/src/Symfony/
> Component/Templating/PhpEngine.php#L148
> https://github.com/symfony/symfony/blob/master/src/Symfony/
> Component/Templating/PhpEngine.php#L158
>
> Only downside: A polyfill is probably impossible since you cannot mutate
> the local symbol table of the callee (as far as I’m aware).
>
> Any thoughts?
>
>
> I see no gain by removing this function. I've also seen it used for
> templating quite often. Yes the functionality could be changed not to use
> extract and end up working the same to the consumer but why make people
> rewrite these things for no apparent gain (and likely a small performance
> hit)?
>
>
> Regards
>
>
>
>

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

[Ryan Pallas]

On Sep 15, 2017 11:22 AM,  wrote:

Hi!

The `extract` function takes an associative array and puts it into the
local symbol table.
http://php.net/manual/en/function.extract.php

```
$array = [
‘foo’ => ‘foo’,
‘bar’ => ‘bar’,
];

extract($array);

print $foo; // "foo"
```

As a second parameter the `extract` function takes some options to make
this function less dangerous, like `EXTR_SKIP` that prevents an existing
local variable of being overwritten. There’s a few more options, go ahead
and take a look at the documentation. `EXTR_OVERWRITE` is the default one
though. You can also pass a prefix for the variable names as a third
argument.

I seriously doubt the usefulness of this function, especially looking at
the potential risks. The fact that overwriting the local variables is the
default behaviour doesn’t make it any better. I suggest deprecating it in
PHP 7.3 and removing it in 8.

In a whole Symfony-Stack (3.4) with all of it’s dependencies I could only
find two usages of this function, both of which could be easily rewritten
in vanilla PHP:
https://github.com/symfony/symfony/blob/master/src/
Symfony/Component/Templating/PhpEngine.php#L148
https://github.com/symfony/symfony/blob/master/src/
Symfony/Component/Templating/PhpEngine.php#L158

Only downside: A polyfill is probably impossible since you cannot mutate
the local symbol table of the callee (as far as I’m aware).

Any thoughts?


I see no gain by removing this function. I've also seen it used for
templating quite often. Yes the functionality could be changed not to use
extract and end up working the same to the consumer but why make people
rewrite these things for no apparent gain (and likely a small performance
hit)?


Regards

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Ryan Pallas]

On Wed, Sep 13, 2017 at 8:06 AM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> On 13 September 2017 14:15:43 BST, Ryan Pallas <derokor...@gmail.com>
> wrote:
> >I must be missing something, there is no autoloader shipped with PHP.
>
> Just to be pedantically correct, there actually is an implementation
> shipped, see http://php.net/spl_autoload It's even the default if you
> don't pass your own function to spl_autoload_register.
>

Almost 2 decades in PHP, and still so much I don't know haha. I will point
out though, that according to a comment [1] it does not replace the
underscores with slashes as mentioned, and I see no where in the code [2]
that it does either.

[1] http://php.net/manual/en/function.spl-autoload.php#98762
[2] https://github.com/php/php-src/blob/master/ext/spl/php_spl.c#L306


>
> Nonetheless, you are quite right that Tony's complaint is nonsensical,
> because he could implement whatever autoloader suited his directory
> structure, if he wanted to - even a case insensitive one.
>
> It is true that autoloading isn't mandatory, but it's also a complete
> straw man, because Sara already made the same point herself:
>
> > I don't feel as though that's true of ...
> > projects where autoloaders
> > aren't used (not a small number).
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Ryan Pallas]

On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston 
wrote:

>
>>
> You seem to forget that autoloading is an option, not a requirement. I
> don't use autoloading in my 14 year old framework for several reasons:
> - An autoloader did not exist when I created my framework.
> - I built an alternative mechanism into my framework, so I don't need an
> autoloader.
> - I don't like the way autoloaders work - all my class names are in snake
> case (lowercase with underscore separators) and the autoloader converts '_'
> into '/' thus producing a file path which does not exist.
>

I must be missing something, there is no autoloader shipped with PHP. You
have to define your own and register it. You can choose to change _ into /
within your autoloader, but that is entirely preference and not
specifically part of autoloading. For example, here's my autoloader which
does no such symbol replacement https://pastebin.com/rQRrXzCa


>
> By convention I always use uppercase for constants which makes them
> instantly recognisable in my code as all other names are either completely
> lowercase or mixed case. Making constants case sensitive instead of
> insensitive would not affect me.
>
> However, I would be totally against switching the rest of the language to
> be case sensitive for the following reasons:
> - It would be a huge BC break no little or no benefit.
> - It would allow developers to shoot themselves in the foot by having
> different functions with the same name but different mixtures of case, so
> that foo(), Foo() FOO() and fOO() would be treated as different functions.
> - if people move from keyboard input to speech recognition, then simply
> speaking a name would not work - you would have to spell it out character
> by character, and specify either upper or lowercase for each character.
>

This is about deprecating the third parameter in define, so userland
constants defined by this function cannot be case insensitive. As mentioned
before by Christoph this is not an attempt to change case sensitivity for
other identifiers (functions, classes, etc) even if it was brought up
before. That is not his intention here, and we need to stick to the focus
of this RFC.


> People who think that case sensitive software is cool are deluding
> themselves. When I started working on mainframe computers (UNIVAC and IBM)
> in the early 1970s everything was case-insensitive. This was only changed
> by people who did not understand the ramifications of their choice.
>
> --
> Tony Marston
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Match expression

[Ryan Pallas]

On Sep 10, 2017 1:23 PM, "li...@rhsoft.net"  wrote:



Am 10.09.2017 um 21:16 schrieb Theodore Brown:

> On Sunday, September 10, 2017 12:45 PM Rowan Collins <
> rowan.coll...@gmail.com> wrote:
>
> Would it be possible to add an optional `$strict` parameter to
 switch? E.g.
 ```
 switch ($i, true) {

>>>
>>> I'd very much prefer a "strict switch ($i) { ... }" over a second
>>> parameter.
>>>
>>
>> What do either of you think of my "switch-use" proposal, which would
>> spell this as "switch ($i) use (===)"?
>>
>
> That seems more complicated and confusing than either of the other
> options. Normally `use()` is for inheriting variables in anonymous
> functions.
>
>
where did you see `use()` in the proposed SYNTAX?
hint: it's not there

it's just "strict switch" versus "switch"


Rowan's suggestion included use.



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

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Ryan Pallas]

On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder <p...@fleshgrinder.com> wrote:

> On 6/5/2017 9:03 PM, Ryan Pallas wrote:
> > However, ($obj) -> $var is valid variable property syntax.
> >
>
> Gosh, we really have support for everything. :D That one is even very
> important for stuff like `(new A)->f()`.
>
> How about ~> which I at least cannot think of any place it is used at
> all. ~ in binary negation and the only place we use it (I checked the
> language parser this time to make sure).
>
> I really dislike the ==> idea. One of the main reasons here is to write
> less and it looks too much like => or even >= which I really don't like.
>
> ($a, $b) ==> $a >= $b
>
> ($a, $b) ~> $a >= $b
>
>
I can get behind using the tilde. Keeps it concise, but it's visually
different than existing syntax, making it easier to recognize (IMO).


> --
> Richard "Fleshgrinder" Fussenegger
>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Ryan Pallas]

On Jun 5, 2017 12:53 PM, "Fleshgrinder"  wrote:

On 6/5/2017 8:36 PM, Rasmus Schultz wrote:
> Ugh, you're right, that's totally unreadable... the => is far too
ambiguous
> with array syntax, I agree.
>
> How about just a thin arrow?
>
> (params) -> expr
>
> If the parens around params were required, it's not ambiguous with the
> trailing -- operator, is it?
>
> $foo->bar(($baz) -> $baz + 1);
>
> Consistent use of parens around the params might make closures a bit
easier
> to spot in the wild?
>

This would actually work with everything, me likes.

  () -> 42
  ($a, $b) -> $a + $b
  ($a) (&$b) -> $b += $a

  public static Foo() -> new static('Foo');


However, ($obj) -> $var is valid variable property syntax.


It also avoid any association with 

Re: [PHP-DEV] Parameter type widening RFC

[Ryan Pallas]

On Fri, May 26, 2017 at 9:01 AM, li...@rhsoft.net  wrote:

>
>
> Am 26.05.2017 um 16:26 schrieb Dan Ackroyd:
>
>> On 26 May 2017 at 13:23, li...@rhsoft.net  wrote:
>>
>>> does that also fix the issue https://bugs.php.net/bug.php?id=74394
>>>
>>
>>
>> Dear Anonymous,
>>
>> That "issue" is actually 3 issues.
>>
>> case 1
>>
>> class A {
>>public function test($a) {}
>> }
>> class B extends A {
>>public function test(string $a) { }
>> }
>>
>> This breaks LSP - because B::test doesn't accept all the things that
>> A::test can accept and so is unlikely to ever be supported.
>>
>
> and how is that a problem?
>
> A accepts anything
> B limits it's inut to a *subset* of "anything"
>
> Because, if I have a function foo(A $a) { $a->test(new Bar()) } that I
cannot pass B into this function, even though it is a subclass of A. You
should be able to pass any subclass where its parent is expected, allowing
parameter narrowing (covariance) would break this.

Re: [PHP-DEV] messages not delivering?

[Ryan Pallas]

On Wed, May 17, 2017 at 8:25 AM, Adam Baratz  wrote:

> > > I'm think this problem might've cropped up again. I didn't receive this
> > > message:
> > > http://news.php.net/php.internals/99052
> > >
> > > I only heard about it because it was mentioned in a PR thread.
> > >
> >
> > I remember finding this one in the Spam dir (Gmail). It appears that
> > DMARC validation failed for it.
> >
> Weird, didn't see it in mine, also Gmail, at all.
>

Yeah, I also can't find it. Also on gmail.

Re: [PHP-DEV] my concept ( new PDO FETCH MODE )

[Ryan Pallas]

Couldn't you just use

return $stmt->fetch() ?: null;

to return null instead of false?

On Wed, May 10, 2017 at 9:51 AM, Csonka Titus  wrote:

> Greetings,
>
> I want to propose a new PDO FETCH MODE.
>
> Whenever I fetch(http://php.net/manual/en/pdostatement.fetch.php) a
> class, it  returns the new instance of the requested class or false in any
> other cases.
>
> However with the new php7.1 return type declaration(https://wiki.php.
> net/rfc/nullable_types) Upon defining a nullable class as return type, I
> need to add extra code at the end of my function if my database don't have
> a row to return.
>
> PDO will return a false, my function will trigger a fatal error.
>
> My proposal is to add a new style of fetch(PDO::FETCH_NULL_IFNODATA),
> returning null if the PDOStatement::fetch has no result.
>
> //this function will trigger a fatal error if the user is not found
> function getUserByName($name): ?UserClass{
> $pdo = new PDO(dsn, user, pass, driver_options);
> $sql = "SELECT * FROM user WHERE name = {$pdo->quote($name)}";
> $stmt = $pdo->query($sql);
> $stmt->setFetchMode(PDO::FETCH_CLASS,'UserClass');
>
> return $stmt->fetch();
> }
>
> //this function will return null representing the absent of user
> function getUserByName($name): ?UserClass{
> $pdo = new PDO(dsn, user, pass, driver_options);
> $sql = "SELECT * FROM user WHERE name = {$pdo->quote($name)}";
> $stmt = $pdo->query($sql);
> $stmt->setFetchMode(PDO::FETCH_CLASS|PDO::FETCH_NULL_
> IFNODATA,'UserClass');
>
> return $stmt->fetch();
> }
>
> Looking forward to you answer
>
> Best regards
> Miklos Csonka
>

Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter

[Ryan Pallas]

On May 9, 2017 15:46, "Yasuo Ohgaki"  wrote:

Hi Andrey,

On Sun, Apr 30, 2017 at 8:26 AM, Yasuo Ohgaki  wrote:

> On Sun, Apr 30, 2017 at 8:14 AM, Yasuo Ohgaki  wrote:
>
>> I don't need your view of HKDF RFC or usage, but I do need good practical
>> examples that justify your point of view. Please don't waste of your/my
>> time,
>> just give some good examples in next reply. Thanks.
>>
>
> BTW, valid (yet not common/proper) example that I can think of is,
>
>  $strong_512bit_key = random_bytes(64);
> $strong_256bit_key = hash_hkdf('sha3-512', $strong_512bit_key, 32);
> ?>
>
> while it does not even require HKDF, though.
>
>  $strong_512bit_key = random_bytes(64);
> $strong_256bit_key = hash('sha3-256', $strong_512bit_key);
> ?>
>
> should be good enough.
>
> Even with "Info", following HMAC is enough.
>
>  $strong_512bit_key = random_bytes(64);
> $strong_256bit_key = hash_hmac('sha3-256', $strong_512bit_key,
$some_info);
> ?>
>

I'm only asking examples for long enough time.
I presume you cannot think of any valid and good example that
justify current hash_hkdf() signature.


Dude, he doesnt have to provide anything. The proposal was turned down
unanimously. Why do you keep sending mail after mail on this? Also, try
sending one mail instead of many when replying. Also, consider that the
likelihood of changing minds is now far gone as continuing this thread
without modifying your stance just biases people more against it.


Then documentation must stress not to use hash_hkdf() only with
"length" and "length/info".

Regards,

P.S.
Draft doc patch is this. (Not updated yet)
https://gist.github.com/anonymous/ace4fa267f20041676f265fe58c3f1ea

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Add is_vectorlike($array) function

[Ryan Pallas]

On Sat, May 6, 2017 at 9:42 AM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> On 5 May 2017 22:19:51 BST, Ryan Pallas <derokor...@gmail.com> wrote:
> >I just read this thread and am wondering what exactly is the use case?
> >Like
> >are you going to do something if it is vector-like, and do something
> >different (or not do anything at all) if it's not vector-like? I mean,
> >if
> >you have to crawl it, and need a vector, why not just call array_values
> >and
> >guarantee you have a vector?
>
> I gave one use case in an earlier message: many serialisation formats have
> a different form for ordered lists vs key-value pairs. As an obvious
> example, look at JSON arrays and objects, and many other formats have
> similar types.
>

Ah, so you would do something like

private serializeArray(array $data) {
   return is_vector($data) ? $this->serializeVector($data) :
$this->serializeAssoc($data);
}

is that right?


> It can also be quite intuitive to have a function accept either a list of
> prepared items or a set of key-value pairs representing structured data.
> For instance, HTTP headers might be prepared like ['User-Agent: example']
> or structured like ['User-Agent' => 'example']. Turning the second into the
> first requires more than just running array_values, but can be skipped if
> the input is known to be vector-like.
>

Ah, that's a great example and makes perfect sense now! Thanks :)


>
> Arrays that have integer keys, but not all sequential, can be a bit of an
> edge case, but treating them as a list throws away information, so it's
> usually safer to treat them as key-value pairs.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Add is_vectorlike($array) function

[Ryan Pallas]

On Tue, May 2, 2017 at 3:13 AM, Jesse Schalken  wrote:

> Related to the optimisation made by Sara Golemon here:
> https://github.com/php/php-src/commit/c74bc87c74f48bc55541b3bf2fc67d
> 595f58a3b5
>
> I often define a function like this, which checks if an array is "vector
> like" i.e. has keys 0,1,2..N:
>
> function is_vectorlike(array $a): bool {
>   $i = 0;
>   foreach ($a as $k => $v) {
> if ($k !== $i++) {
>   return false;
> }
>   }
>   return true;
> }
>
> The problem is that this function is O(n), but in PHP7 an array that is
> vector-like is likely to be packed and without holes (HT_IS_PACKED(x) &&
> HT_IS_WITHOUT_HOLES(x)), in which case it is known to be vector-like
> without needing to iterate over it, but PHP code can't check for this (nor
> should it be able to, since it's really an implementation detail).
>
> Would it be a good idea to define this is_vectorlike() function in the PHP
> runtime, so it can short circuit to return true on packed arrays without
> holes? The above code would be a suitable polyfill.
>


I just read this thread and am wondering what exactly is the use case? Like
are you going to do something if it is vector-like, and do something
different (or not do anything at all) if it's not vector-like? I mean, if
you have to crawl it, and need a vector, why not just call array_values and
guarantee you have a vector?

Also, given the implementation above, why does the array have to be ksorted
correctly to count? Specifically, why isn't this array considered vector
like?
$arr = [
1=> 1,
0=> 0,
];

Wouldn't the following be a better test?
function is_vectorlike(array $a): bool {
  $l = count($a);
  for (i=0; $i<$l, $i++) {
if (!array_key_exists($i, $a)) {
  return false;
}
  }
  return true;
}

Re: [PHP-DEV] ; on the end of the line

[Ryan Pallas]

On Thu, Mar 30, 2017 at 12:19 PM, Johannes Schlüter 
wrote:

> On Do, 2017-03-30 at 00:07 -0700, Davey Shafik wrote:
> > Notice each of these has two statements. (Note: I don't think any of
> > these
> > are particularly good ways to write readable code, but they are all
> > syntactically valid code).
>
> The imo more relevant cases are the one where an optional semicolon
> causes unclear behavior. Consider we make it optional, what is the
> behavior of this code:
>
>  $a = [1, 2, 3]
> [rand(0, 2)]
> var_dump($a)
> ?>
>
> $a could either be an array with three elements or a single integer
> value which is randomly chosen out of the array. Requiring a statement
> separator like semicolon makes this clear.
>
> > While I know some languages make semicolons optional (javascript), or
> > omit them entirely (python),  semicolons in PHP will not be going
> > away (or optional) any time soon.
>
> JavaScript shouldn't be our role model here - it has relatively complex
> rules for this (essentially "if treating a following line as belonging
> to the statement leaves valid code then treat it as part of the same
> statement else terminate the statement on the new line")
> Python does this by requiring indention on the continuing line. As PHP
> isn't whitespace-programming this isn't applicable for s either, while
> it's a way more consistent design than JavaScript in that regard.
>

I would also point out, that I haven't worked on a JavaScript project in
ages where the conventions / rules of that project allow leaving off
semi-colons. While the language may make it acceptable, most organizations
have rules requiring semi-colons. The reason is to avoid the disambiguation
as Johannes has pointed out.


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

Re: [PHP-DEV] Directory separators on Windows

[Ryan Pallas]

On Thu, Mar 30, 2017 at 8:05 AM, Rowan Collins 
wrote:

> On 30 March 2017 14:25:02 BST, Rasmus Schultz  wrote:
>
> >Returning backslashes on Windows seems rather unnecessary in the first
> >place, since forward slashes work just fine?
>
> This may be true when using the paths within PHP, but is it true outside
> of it? If your JSON file had been read in by a .net application, or used to
> generate a DOS/NT batch file, wouldn't forward slashes there have been just
> as broken as backslashes on a Linux box?
>
>
In my experience, forward slashes work just fine in .NET 4.0+ (haven't ever
used less than 4.0, so I won't claim to know), PowerShell and batch files.
Command prompt deals with it just fine.


> Sadly, I fear this is like trying to automate line ending conversion - the
> more you try to avoid being platform-specific, the more awkward cases you
> introduce.
>

I tend to agree. It's really not that hard to handle in the application
itself, instead of relying on the language to perform some magic. We
generally know that magic features aren't so great, so let's not go adding
more.


>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Add __toArray() method to objects that would be called on cast to array

[Ryan Pallas]

On Mar 15, 2017 5:03 PM, "Marco Pivetta" <ocram...@gmail.com> wrote:

Hi Ryan,

I'm top-posting because I'm writing from a phone. I always do and I also
stopped caring for top-posters myself because it's fairly normal, plus
modern email clients deal with it. If I can write a damn mail from a phone
keyboard because I don't have any better right now, then you can probably
use the scroll wheel once on your pc too.

I'll just say this: I'm also on a mobile device. Don't make assumptions.


The BC break applies to API that accepts `object` (any object). Such API is
common in library code in frameworks, data-mappers, etc.

Such code would not work anymore for cases where the magic method is
implemented, adding either exceptions (forcing a library-level BC break) or
simply by causing the existing stable versions of these libs to be
incompatible with newer php versions.


I must misunderstand what constitutes an BC break. I thought a BC break was
when identical code produced different results. But you're saying its a
break because someone could change their code to use a new feature and
break their use of your library?




On 15 Mar 2017 11:57 p.m., "Ryan Pallas" <derokor...@gmail.com> wrote:



On Mar 15, 2017 16:40, "Marco Pivetta" <ocram...@gmail.com> wrote:

Which is precisely the BC break: such a library would now throw an
exception "unsupported class X" when `__toString` is implemented. Also,
such a library would break silently when this feature is implemented.

Much like the already very broken `__debugInfo()`, this automatic type-cast
is a giga-Joule footgun.


First please stop top posting.

Second bc means that if no code changes no functionality is changed. That's
exactly what we're talking about. If the class doesn't change neither does
the functionality. So unless classes already have __toArray they will not
change in behaviour.

As pointed out in answer to my question earlier a class with no code change
would see no change in casting behaviour. Only if new method is implemented
will behaviour change. How does that not maintain bc?


On 15 Mar 2017 11:36 p.m., "Ryan Pallas" <derokor...@gmail.com> wrote:

>
>
> On Wed, Mar 15, 2017 at 4:33 PM, Marco Pivetta <ocram...@gmail.com> wrote:
>
>> It's the only way to distinguish between set and unset properties. Also
>> the
>> only way to get all properties from an instance of an inheritance tree.
>
> Also, it's covered by tests that were explicitly added to prevent
>> regressions on this.
>>
>> Same as all similar discussions before this one: need an alternative way
>> to
>> do things before proposing a BC break.
>>
>>
> As mentioned in previous mails - the intent isn't to change existing
> behaviour, but to provide a way for a class to override the default
> behaviour. As long as those classes you are casting to array don't
> implement __toArray they will behave exactly as they always have. The only
> concern then, is that you might be relying on a library to not implement
> that function on a class you are casting.
>
>
>> On 15 Mar 2017 11:27 p.m., "Kalle Sommer Nielsen" <ka...@php.net> wrote:
>>
>> > Hi
>> >
>> > 2017-03-15 21:41 GMT+01:00 Marco Pivetta <ocram...@gmail.com>:
>> > > This is a BC break due to the fact that the `(array)` cast is used to
>> > > extract property information from private properties in library code.
>>
> >
>> > Yep, but then again that is more of an
>> > undocumented-not-really-supported case afair, if anything then
>> > Reflection should have the APIs to officially allow that, although I
>> > am still skeptic of this.
>>
> Does it not through get properties?

>
>> >
>> > --
>> > regards,
>> >
>> > Kalle Sommer Nielsen
>> > ka...@php.net
>> >
>>
>
>

Re: [PHP-DEV] Add __toArray() method to objects that would be called on cast to array

[Ryan Pallas]

On Mar 15, 2017 16:40, "Marco Pivetta" <ocram...@gmail.com> wrote:

Which is precisely the BC break: such a library would now throw an
exception "unsupported class X" when `__toString` is implemented. Also,
such a library would break silently when this feature is implemented.

Much like the already very broken `__debugInfo()`, this automatic type-cast
is a giga-Joule footgun.


First please stop top posting.

Second bc means that if no code changes no functionality is changed. That's
exactly what we're talking about. If the class doesn't change neither does
the functionality. So unless classes already have __toArray they will not
change in behaviour.

As pointed out in answer to my question earlier a class with no code change
would see no change in casting behaviour. Only if new method is implemented
will behaviour change. How does that not maintain bc?


On 15 Mar 2017 11:36 p.m., "Ryan Pallas" <derokor...@gmail.com> wrote:

>
>
> On Wed, Mar 15, 2017 at 4:33 PM, Marco Pivetta <ocram...@gmail.com> wrote:
>
>> It's the only way to distinguish between set and unset properties. Also
>> the
>> only way to get all properties from an instance of an inheritance tree.
>> Also, it's covered by tests that were explicitly added to prevent
>> regressions on this.
>>
>> Same as all similar discussions before this one: need an alternative way
>> to
>> do things before proposing a BC break.
>>
>>
> As mentioned in previous mails - the intent isn't to change existing
> behaviour, but to provide a way for a class to override the default
> behaviour. As long as those classes you are casting to array don't
> implement __toArray they will behave exactly as they always have. The only
> concern then, is that you might be relying on a library to not implement
> that function on a class you are casting.
>
>
>> On 15 Mar 2017 11:27 p.m., "Kalle Sommer Nielsen" <ka...@php.net> wrote:
>>
>> > Hi
>> >
>> > 2017-03-15 21:41 GMT+01:00 Marco Pivetta <ocram...@gmail.com>:
>> > > This is a BC break due to the fact that the `(array)` cast is used to
>> > > extract property information from private properties in library code.
>> >
>> > Yep, but then again that is more of an
>> > undocumented-not-really-supported case afair, if anything then
>> > Reflection should have the APIs to officially allow that, although I
>> > am still skeptic of this.
>> >
>> >
>> > --
>> > regards,
>> >
>> > Kalle Sommer Nielsen
>> > ka...@php.net
>> >
>>
>
>

Re: [PHP-DEV] Add __toArray() method to objects that would be called on cast to array

[Ryan Pallas]

On Wed, Mar 15, 2017 at 4:33 PM, Marco Pivetta  wrote:

> It's the only way to distinguish between set and unset properties. Also the
> only way to get all properties from an instance of an inheritance tree.
> Also, it's covered by tests that were explicitly added to prevent
> regressions on this.
>
> Same as all similar discussions before this one: need an alternative way to
> do things before proposing a BC break.
>
>
As mentioned in previous mails - the intent isn't to change existing
behaviour, but to provide a way for a class to override the default
behaviour. As long as those classes you are casting to array don't
implement __toArray they will behave exactly as they always have. The only
concern then, is that you might be relying on a library to not implement
that function on a class you are casting.


> On 15 Mar 2017 11:27 p.m., "Kalle Sommer Nielsen"  wrote:
>
> > Hi
> >
> > 2017-03-15 21:41 GMT+01:00 Marco Pivetta :
> > > This is a BC break due to the fact that the `(array)` cast is used to
> > > extract property information from private properties in library code.
> >
> > Yep, but then again that is more of an
> > undocumented-not-really-supported case afair, if anything then
> > Reflection should have the APIs to officially allow that, although I
> > am still skeptic of this.
> >
> >
> > --
> > regards,
> >
> > Kalle Sommer Nielsen
> > ka...@php.net
> >
>

Re: [PHP-DEV] Add __toArray() method to objects that would be called on cast to array

[Ryan Pallas]

On Wed, Mar 15, 2017 at 11:49 AM, Benoît Burnichon 
wrote:

> Hi all,
>
> Looking at code of PHPUnit, I stumbled upon an inconsistent array
> conversion:
>
> --
> /**
>  * @param ArrayAccess|array $other
>  */
> function evaluate($other)
> {
>   // type cast $other as an array to allow
>   //support in standard array functions.
>   if ($other instanceof ArrayAccess) {
> $data = (array) $data;
>   }
>
>   $patched = array_replace_recursive($other, $this->subset);
>
>   // ...
> }
> -
>
> This would work only for `ArrayAccess` implementations extending
> `ArrayObject` as shown by https://3v4l.org/ti4aY
>
> Looking at the manual
> http://php.net/manual/en/language.types.array.php#
> language.types.array.casting
> ,
> it seems `ArrayObject` class does not comply to array casting because
> integer public properties could also be retrieved. Some tests showed that
> regular class always have string keys even when a `$key = 0; $this->{$key}
> = 'avalue';` is called. In this case, `var_export((array)$object);` returns
> `array('0' => 'avalue')` (Notice the quote around key 0 -
> https://3v4l.org/6QW70)
>
> What do you think of adding an optional `__toArray()` method to classes
> which would default to current behavior but would allow specifying
> behavior. The way of internal `__toString()` method and could explain
> inconsistency of the `ArrayObject` class?
>

I like the idea kind of, but would this remove the ability to cast to array
all classes not implementing __toArray, as is the case with __toString?
This would be a HUGE BC if so:

$ php -r 'class Foo {public $foo = "foobar";} var_dump((array) (new Foo));'
array(1) {
  ["foo"]=>
  string(6) "foobar"
}
$ php -r 'class Foo {public $foo = "foobar";} var_dump((string) (new Foo));'
PHP Recoverable fatal error:  Object of class Foo could not be converted to
string in Command line code on line 1
$ php -v
PHP 7.1.2 (cli) (built: Feb 27 2017 00:02:44) ( ZTS )


> Regards,
>
> Benoît Burnichon
>

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

[Ryan Pallas]

On Wed, Mar 8, 2017 at 9:50 AM, Ryan Pallas <derokor...@gmail.com> wrote:

>
>
> On Wed, Mar 8, 2017 at 8:51 AM, Fleshgrinder <p...@fleshgrinder.com> wrote:
>
>> Hey! :)
>>
>> The reference is actually not a problem for a Stringable because you
>> would get the "Only variables can be passed by reference" error with an
>> object if `strict_types` is enabled.
>>
>> Simply because the object **MUST** be converted into a string. The
>> object itself does not satisfy the constraint, but the object clearly
>> states that it can be converted into a string at any point.
>>
>
> This is the part I disagree with. The object clearly states that it can be
> turned into a string when you are done using it as a object. If it gets
> turned into a string, you can no longer use it as a object.
>
> There is a difference between changing an int to string and an object to
> string, in that afterwards the int->string can continue to be treated as an
> int afterwards, thanks to loose typing (otherwise it wouldn't have become a
> string in the first place). However with an object->string afterwards it
> can ONLY be treated as a string, it can no longer be treated as an object.
> Meaning
>
> $int = 3;
> foo(3);
>
Sorry this should have been:
foo($int);

> var_dump(++$int); // 4, success, no errors
>
> $obj = new Foo('a');
> foo($obj);
> var_dump($obj->method()); // Fatal error: call to member function method
> on string.
>
> To me, this doesn't make sense.
>
>>
>> Not doing so would violate what `strict_types` actually promise us. ;)
>>
>> --
>> Richard "Fleshgrinder" Fussenegger
>>
>
>

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

[Ryan Pallas]

On Wed, Mar 8, 2017 at 8:51 AM, Fleshgrinder  wrote:

> Hey! :)
>
> The reference is actually not a problem for a Stringable because you
> would get the "Only variables can be passed by reference" error with an
> object if `strict_types` is enabled.
>
> Simply because the object **MUST** be converted into a string. The
> object itself does not satisfy the constraint, but the object clearly
> states that it can be converted into a string at any point.
>

This is the part I disagree with. The object clearly states that it can be
turned into a string when you are done using it as a object. If it gets
turned into a string, you can no longer use it as a object.

There is a difference between changing an int to string and an object to
string, in that afterwards the int->string can continue to be treated as an
int afterwards, thanks to loose typing (otherwise it wouldn't have become a
string in the first place). However with an object->string afterwards it
can ONLY be treated as a string, it can no longer be treated as an object.
Meaning

$int = 3;
foo(3);
var_dump(++$int); // 4, success, no errors

$obj = new Foo('a');
foo($obj);
var_dump($obj->method()); // Fatal error: call to member function method on
string.

To me, this doesn't make sense.

>
> Not doing so would violate what `strict_types` actually promise us. ;)
>
> --
> Richard "Fleshgrinder" Fussenegger
>

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

[Ryan Pallas]

Sorry, accidently sent in the middle of typing that...

On Wed, Mar 8, 2017 at 7:42 AM, Ryan Pallas <derokor...@gmail.com> wrote:

>
>
> On Wed, Mar 8, 2017 at 5:25 AM, Andrey Andreev <n...@devilix.net> wrote:
>
>> Hi all,
>>
>> I submitted a GitHub PR* to allow objects implementing __toString() to
>> *optionally* pass is_string() validation. More verbose wording of my
>> motivation can be seen in the PR description, but here are the main
>> points:
>>
>> - Simpler way to do checks like: is_string($var) ||
>> method_exists($var, '__toString')
>> - Can be used for stricter string parameter validation in
>> strict_types=0 mode (otherwise any scalar type is accepted)
>
> - Can be used for looser string parameter validation in strict_types=1
>> mode (__toString() objects aren't accepted there)
>> - Regardless of the last 2 points, it is intentionally not limited to
>> parameter types
>>
>
> If I understand correctly, you want the following to work:
>
> declare(strict_type = 0);
function foo(string $bar) {
return $bar.'foo';
}

class Foo {
private $val;
public function __construct(string $val) {
$this->val = $val;
}
public function __toString() {
return $this->$val;
}
}

echo foo(new Foo('this is ')); // this is foo

But what happens if I change the foo function like:
function foo(string &$bar) {
$bar .= 'foo';
}

$foo = new Foo('object');
foo($foo);
var_dump($foo); // will this be an instance of Foo, or the string
"objectfoo"??

If $foo remains an object in this scope, then the function is not modifying
its value. If it becomes a string, it's an unexpected change IMO. It is
probably fine in this case, but not in the case of a more complex object.

>
>
>
>>
>> * https://github.com/php/php-src/pull/2408
>>
>> ---
>>
>> I didn't have time to write this email right after submitting the
>> patch, and in the meantime got some feedback from Fleshgrinder on
>> GitHub, which I'll quote and address here:
>>
>> > Thanks for your effort and initiative.
>> >
>> > However, I strongly believe that this is the wrong approach. Adding a
>> flag to a function directly results in the fact that the function violates
>> the single responsibility principle. What we actually need to make this
>> work is a "stringable" pseudo-type like the iterable type that was
>> introduced in PHP 7.1. This "stringable" pseudo-type is the union of the
>> scalar primitive string and any class that implements the __toString method.
>> >
>> > This has the advantage that we are actually able to use it together
>> with strict_types, plus we have separate dedicated functions like
>> "is_stringable" that adhere to the single responsibility principle. I
>> actually wanted to create an RFC for that along with an implementation
>> since iterable was accepted, but did not find the time yet.
>> >
>> > Closing note: these pseudo-types are necessary in PHP because it has no
>> coherent type system, and there is nothing we can do about this in short
>> term. Hence, adding such pseudo-types is the only short term solution that
>> we actually have.
>>
>> I ultimately wouldn't care if it's a separate function and did in fact
>> think of an is_stringable() function, but wasn't happy with the naming
>> - who's to say that e.g. integers aren't stringable? Bar
>> horribly-verbose names like
>> "string_or_objects_implementing__toString", I don't think there's a
>> way to avoid that ambiguity. :/
>> If we want a "stringable" type though, I guess we'll have to live with
>> that.
>>
>> I feel that debating the actual type system is way broader than I
>> intended this to be, so I'll refrain from going further on that for
>> now, as I've got some more radical ideas about it.
>>
>> ---
>>
>> Thoughts?
>>
>> Cheers,
>> Andrey.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

[Ryan Pallas]

On Wed, Mar 8, 2017 at 5:25 AM, Andrey Andreev  wrote:

> Hi all,
>
> I submitted a GitHub PR* to allow objects implementing __toString() to
> *optionally* pass is_string() validation. More verbose wording of my
> motivation can be seen in the PR description, but here are the main
> points:
>
> - Simpler way to do checks like: is_string($var) ||
> method_exists($var, '__toString')
> - Can be used for stricter string parameter validation in
> strict_types=0 mode (otherwise any scalar type is accepted)

- Can be used for looser string parameter validation in strict_types=1
> mode (__toString() objects aren't accepted there)
> - Regardless of the last 2 points, it is intentionally not limited to
> parameter types
>

If I understand correctly, you want the following to work:
declare(strict_type = 0);
function foo(string $bar) {



>
> * https://github.com/php/php-src/pull/2408
>
> ---
>
> I didn't have time to write this email right after submitting the
> patch, and in the meantime got some feedback from Fleshgrinder on
> GitHub, which I'll quote and address here:
>
> > Thanks for your effort and initiative.
> >
> > However, I strongly believe that this is the wrong approach. Adding a
> flag to a function directly results in the fact that the function violates
> the single responsibility principle. What we actually need to make this
> work is a "stringable" pseudo-type like the iterable type that was
> introduced in PHP 7.1. This "stringable" pseudo-type is the union of the
> scalar primitive string and any class that implements the __toString method.
> >
> > This has the advantage that we are actually able to use it together with
> strict_types, plus we have separate dedicated functions like
> "is_stringable" that adhere to the single responsibility principle. I
> actually wanted to create an RFC for that along with an implementation
> since iterable was accepted, but did not find the time yet.
> >
> > Closing note: these pseudo-types are necessary in PHP because it has no
> coherent type system, and there is nothing we can do about this in short
> term. Hence, adding such pseudo-types is the only short term solution that
> we actually have.
>
> I ultimately wouldn't care if it's a separate function and did in fact
> think of an is_stringable() function, but wasn't happy with the naming
> - who's to say that e.g. integers aren't stringable? Bar
> horribly-verbose names like
> "string_or_objects_implementing__toString", I don't think there's a
> way to avoid that ambiguity. :/
> If we want a "stringable" type though, I guess we'll have to live with
> that.
>
> I feel that debating the actual type system is way broader than I
> intended this to be, so I'll refrain from going further on that for
> now, as I've got some more radical ideas about it.
>
> ---
>
> Thoughts?
>
> Cheers,
> Andrey.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Comparable

[Ryan Pallas]

On Tue, Jan 31, 2017 at 3:48 PM, Fleshgrinder  wrote:

> Hi :)
>
> I have a few questions regarding the comparable RFC:
>
> https://wiki.php.net/rfc/comparable
>
> Couldn't find the thread in my history and thus cannot respond directly
> to any of the past threads. Maybe not that bad after more than a year of
> silence. :)
>
> My question might sound silly but I am genuinely interested in the
> explanation: why `compareTo` and not `comparedTo` as method name? Is it
> simply because of Java? To me it sounds kind of wrong:
>
> if ($this->compareTo($other) === -1) { }
>
> Especially if we add a nice Ordering Enum with some real behavior to the
> game:
>
> if ($this->compareTo($other)->isLess()) { }
>
> Compare this to:
>
> if ($this->comparedTo($other)->isLess()) { }
>
> This gets close to what I would understand as proper English. Then again
> there might be valid reasons for the former name that I am not aware of?!?
>

I would say compareTo makes sense, because that's what you're asking the
method to do. Methods aren't usually past tense as it would seem weird.
Think about PDOStatement::fetch vs fetched, Exception::getMessage vs
gotMessage. Honestly I can't think of a single example of a past tense
method off the top of my head (doesn't meant they don't exist!). Even
functions and language constructs are present (echo, require, print).


>
> There are other things that I think should be added along with this RFC.
> However, I need to investigate a bit further first before going into
> detail here.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Pipe Operator v2

[Ryan Pallas]

On Thu, Jan 19, 2017 at 4:08 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:
>
>
> On 19/01/2017 22:17, Ryan Pallas wrote:
>
>>
>> When you say assert the right hand side is callable, does that mean to
>> call an object method, you would do [$obj, 'method']? What about
>> functions,
>> is it just the name like $str |> trim, or is it $str |> trim()?
>>
>
> This is a good point. The difference between the pipe operator as proposed
> by Sara and the combination of two separate operators is that in Sara's
> proposal you'd always write this:
>
> $str |> trim($$)
>
> But in Levi's proposal as I understand it, the right-hand side is not
> syntax, it's just constrained to be callable, so the simpler (but rather
> ugly) form would be:
>
> $str |> 'trim'
>

See I don't like that at all, I hate having to put functions/methods in
strings, as find usages and refactor tools generally don't find the
strings. But sometimes I have to yield my preference to those who outrank
me (aka those with voting power)

Re: [PHP-DEV] Pipe Operator v2

[Ryan Pallas]

On Thu, Jan 19, 2017 at 5:54 AM, Levi Morrison  wrote:

> On Wed, Jul 20, 2016 at 5:42 PM, Sara Golemon  wrote:
> > With the branching of 7.1, and after some reflection on the previous
> > feedback, I'd like to reopen discussion of the Pipe Operator RFC
> > https://wiki.php.net/rfc/pipe-operator which I had previously put on
> > hold.  I've changed much of the argument wording of the proposal, but
> > not the substantive feature set.  If you still feel it's unworkable,
> > I'd like to encourage you to respond with what you think would make it
> > workable (if anything).  Thanks.
> >
> > -Sara
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> I've talked to you about this RFC off-list, but I figured I should
> mention it on-list as well. I think we should make `|>` and `$$` two
> independent operators that work well together (rather than only
> together).
>
> The `|>` symbol would be the piping operator with these semantics:
>
> 1. Evaluate the left-hand side.
> 2. Evaluate the right-hand side. Assert that the result is callable.
> 3. Pass the result from 1. as the single argument to 2.
>
> When you say assert the right hand side is callable, does that mean to
call an object method, you would do [$obj, 'method']? What about functions,
is it just the name like $str |> trim, or is it $str |> trim()? Neither
makes sense to me in the context of PHP since methods/functions are named
objects, which is why when you pass a callback you have to give the string
name of the function instead of just the name of the function, IE
array_filter($arr, 'trim') vs array_filter($arr, trim).

Re: [PHP-DEV] PHP 5.6 end of active support

[Ryan Pallas]

On Wed, Dec 14, 2016 at 1:39 PM, Dennis Clarke 
wrote:

> On 12/14/2016 03:31 PM, Marco Pivetta wrote:
>
>> See https://secure.php.net/supported-versions.php
>>
>
> I see.
>
> I guess the question has to be "why is the 5.6.x codebase only to receive
> security fixes for a very brief while into 2017" ?  Just
> curious what the thinking is here.


It goes to 2018, see the RFC [1] that extended it.


[1] https://wiki.php.net/rfc/php56timeline

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

Re: [PHP-DEV] PHP 7.1.0 GA

[Ryan Pallas]

Great work everyone! Your users appreciate all you do!

https://media.giphy.com/media/nEUsjV11iZCPS/giphy.gif

On Tue, Nov 22, 2016 at 11:36 AM, Joe Watkins  wrote:

> Evening internals,
>
> I'm excited to announce that PHP 7.1.0 will be GA on December 1st.
>
> It has taken a lot of hard work from a lot of people, so stop whatever you
> are doing and give those people a round of applause.
>
> Cheers
> Joe
>

Re: [PHP-DEV] Request for wiki account activation

[Ryan Pallas]

On Nov 19, 2016 9:16 AM, "Joe Watkins"  wrote:
>
> Afternoon internals,
>
> Wes already registered for a wiki account, but "it doesn't work".
>
> Can someone fix it, please.
>
> @Wes we aren't paying for any walls.

Don't worry, we'll make python pay for the wall.

>
> Cheers
> Joe
>
> On Sat, Nov 19, 2016 at 4:10 PM, Net Mo  wrote:
>
> > Hi PHP!
> >
> > I'm willing to write some awesome RFCs to make PHP great again, I'll
build
> > a wall and it'll be tremendous. Very very great. :-P
> >
> > But I'll start with something simple first :-P it is about improving
> > ArrayIterator (you can find a draft here
> > https://gist.github.com/Netmosfera/200c5e923f34cbc00cdb31224d730de8)
> >
> > I'm a Room11 regular and a PHP zealot.
> >
> > My wiki username is: WesNetmo
> >
> > Thank you!
> >

Re: [PHP-DEV] Immutability RFC

[Ryan Pallas]

On Wed, Nov 16, 2016 at 6:57 AM, Silvio Marijić 
wrote:

> Hi,
>
> To anyone who is interested in this RFC. What do you think what behavour we
> should have when you try to compare two immutable objects by identity like
> this:
>
> immutable class A {
>
> public $a;
>
> public function __construct($a) {
>$this->a = $a
> }
>
> }
>
> $a1 = new A(1);
> $a2 = new A(1);
>

I would personally expect that:

var_dump($a1 === $a2); // bool(false)
var_dump($a1 == $a2); // bool(true)


>
> $a1 === $a2
>
> If we treat those objects as values then this should return true. But then
> again there might be some confusion because then two operators are doing
> the same thing. Maybe throw an error ? Suggestions ?
>
> Cheers.
> --
> Silvio Marijić
> Software Engineer
> 2e Systems
>

Re: [PHP-DEV] Feature Request: inline pseudo-instruction

[Ryan Pallas]

On Tue, Oct 4, 2016 at 1:31 PM, Ryan Pallas <derokor...@gmail.com> wrote:

>
>
> On Tue, Oct 4, 2016 at 8:33 AM, Pascal KISSIAN <php-mailing-l...@lool.fr>
> wrote:
>
>> >-Message d'origine-
>> >De : Lauri Kenttä [mailto:lauri.ken...@gmail.com]
>> >Envoyé : mardi 4 octobre 2016 16:21
>> >À : Pascal KISSIAN <php-mailing-l...@lool.fr>
>> >Cc : internals@lists.php.net
>> >Objet : Re: [PHP-DEV] Feature Request: inline pseudo-instruction
>> >
>> >On 2016-10-04 14:33, Pascal KISSIAN wrote:
>> >> I have an application where a small file is included at multiple
>> >> places.
>> >>
>> >> The include is done about an average of 100.000 times .
>> >
>> >I'm just wondering if you have ever heard of functions? You really
>> should write a function, include it only once, and then simply call the
>> function instead of repeatedly >including the file. Calling a function is a
>> lot faster than including a file.
>> >
>> >--
>> >Lauri Kenttä
>>
>> Function is not appropriate when the "inlined code" has to share 20-30
>> local variables ...
>> Having a function with 30 args,  or having to build and access an array
>> is not very efficient nor natural...
>> Local variables include 6 nested "for loop" indices and local
>> variables/arrays needed for the computing.
>>
>
> As many have said this may be a sign of a need to refactor. however, to
> say that building an array and accessing it is not natural, consider that
> you can use compact / extract.
>
> function doLoops($vars) {
> extract($vars);
> // many for loops
> return compact(implode(' ', array_keys($vars)));
> }
>
> // elsewhere set up a bunch of variables
> extract(doLoops(compact('list of variable names goes here')));
>
> Problem solved, now you are not including in a loop, but calling an
> already compiled function, without adding TONS of lines of code to build
> such an array. Its a short solution, to a problem that should probably lead
> to a redesign of the functionality anyway.
>
>

Sorry that should be compact(array_keys($vars)), and same for the list
going in. Too many other languages lately!

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

Re: [PHP-DEV] Feature Request: inline pseudo-instruction

[Ryan Pallas]

On Tue, Oct 4, 2016 at 8:33 AM, Pascal KISSIAN 
wrote:

> >-Message d'origine-
> >De : Lauri Kenttä [mailto:lauri.ken...@gmail.com]
> >Envoyé : mardi 4 octobre 2016 16:21
> >À : Pascal KISSIAN 
> >Cc : internals@lists.php.net
> >Objet : Re: [PHP-DEV] Feature Request: inline pseudo-instruction
> >
> >On 2016-10-04 14:33, Pascal KISSIAN wrote:
> >> I have an application where a small file is included at multiple
> >> places.
> >>
> >> The include is done about an average of 100.000 times .
> >
> >I'm just wondering if you have ever heard of functions? You really should
> write a function, include it only once, and then simply call the function
> instead of repeatedly >including the file. Calling a function is a lot
> faster than including a file.
> >
> >--
> >Lauri Kenttä
>
> Function is not appropriate when the "inlined code" has to share 20-30
> local variables ...
> Having a function with 30 args,  or having to build and access an array is
> not very efficient nor natural...
> Local variables include 6 nested "for loop" indices and local
> variables/arrays needed for the computing.
>

As many have said this may be a sign of a need to refactor. however, to say
that building an array and accessing it is not natural, consider that you
can use compact / extract.

function doLoops($vars) {
extract($vars);
// many for loops
return compact(implode(' ', array_keys($vars)));
}

// elsewhere set up a bunch of variables
extract(doLoops(compact('list of variable names goes here')));

Problem solved, now you are not including in a loop, but calling an already
compiled function, without adding TONS of lines of code to build such an
array. Its a short solution, to a problem that should probably lead to a
redesign of the functionality anyway.


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

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

[Ryan Pallas]

On Wed, Sep 21, 2016 at 12:44 PM, Jakub Zelenka  wrote:

> Hi,
>
> On Wed, Sep 21, 2016 at 7:07 PM, Levi Morrison  wrote:
>
>> On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas
>>  wrote:
>> >> To handle this in code written around current __toString seems pretty
>> > simple
>> >
>> > Yes it is, but that's not what we're talking about:
>> > BC is about having perfectly fine code working in e.g. 7.0 be still
>> working
>> > fine on 7.1 *without any change*.
>> >
>> > Right now, we have red test suites on php7.1rc2.
>> > This is the symptom of a BC break, by definition.
>> > And the issue is not the existing code we have, but the new one that is
>> > changing the behavior of the engine.
>>
>> This was understood when the decision was made. You seem to not be
>> understanding the bigger issue and instead focusing on the BC break
>> for a *single minor release, and a dot zero at that*. If we keep the
>> BC compat this method is redundant and useless forever. If we fix it
>> we break your code for *one single minor release, and a dot zero at
>> that*. Which is the bigger disruption?
>>
>> This is why the decision was made. It is better to have the useful
>> functionality from here on out than to preserve BC with a single minor
>> release, and a dot-zero at that.
>>
>>
> I'm just wondering, how is it possible that this got changed when the only
> RFC mentioning this change got rejected ( https://wiki.php.net/rfc/
> reflectiontypeimprovements )? I don't see any consensus in the later
> discussion so unless I missed something, which is quite possible, this
> change should not be there in the first place, right?
>

The best I can find are these messages [1] where it specifically mentions
that toString should change even though this was rejected, and it had at
least some agreement at the time.

[1] http://php-news.ctrl-f5.net/message/php.internals/94452

>
> Cheers
>
> Jakub
>
>

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

[Ryan Pallas]

On Wed, Sep 21, 2016 at 10:13 AM, Nicolas Grekas 
wrote:

> >
> > See https://github.com/php/php-src/pull/2136
> >>
> >
> > I don't like this.
> >
>
> I understand, really. I do have to deal with BC on Symfony side also and
> it's a really hard constraint. Yet, we stick to it as much as possible, in
> order to not add pain to others.
> Sometime, we have to be pragmatic and accept solutions that are not "pure",
> for the shake of our BC promise.
>
> PHP internals has such a BC policy, it should really stick to it. It's not
> always fun, for sure, but the pain for others it strong. It's not only
> me, nor Symfony: everybody not following internals to adapt
> to latest BC breaks will be hit, potentially. This is bad for the
> reputation of PHP. It makes the PHP platform unstable as far as confidence
> is concerned.
>
> In this case, we should find a technical solution that preserves BC. Being
> this patch or unconditionally returning the type name with nullable info is
> fine, you'll decide what's best.
>
> But please don't consider BC as something that one can bypass when it gets
> annoying.
>
> Thanks from me and from many others for considering :)
>

I'm not so sure its a BC though. Technically nullable types don't exist in
7.0 and as such would be impossible to return said question mark. Its only
adding support for a new feature, not changing how an existing feature
works IMO. If nullable types had been in 7.0 its highly probably, that
__toString would have returned the leading question mark back then.


> Nicolas
>

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

[Ryan Pallas]

On Wed, Sep 21, 2016 at 10:34 AM, Nicolas Grekas 
wrote:

>
>
>> I'm not so sure its a BC though. Technically nullable types don't exist
>> in 7.0 and as such would be impossible to return said question mark. Its
>> only adding support for a new feature, not changing how an existing feature
>> works IMO. If nullable types had been in 7.0 its highly probably, that
>> __toString would have returned the leading question mark back then.
>>
>
> Here is the BC break: https://3v4l.org/VUbIS
>
> As light as it looks to be, the output on PHP7.1RC2 is not the same as in
> PHP7.0.
> Yet, __toString() is the only public interface that is available on PHP
> 7.0,
> so people have already built things on top.
>
>
I get that the output changed, but so did the type definition with the new
feature.

However, I feel this is a problem with the way types are inferred. To me
Type $foo = null is an entirely different definition than ?Type $foo, but
that's not how its implemented in the language. To me Type $foo = null
should say "I have a parameter that is not required, but when its passed it
needs to be an instance of Type", whereas ?Type $foo should say "I require
this parameter, and it needs to be an instance of Type or null". If these
definition were the result of those expressions, then we could have a third
state, namely ?Type $foo = null which would say "I do not require this
parameter, but when its passed it needs to be an instance of Type or null".
I think the reason it works this way is, get this, for BC since previously
Type $foo = null was the only way to make a parameter nullable, while
having the intentional or unintentional side effect of making it optional
(or the only way to make it optional, while having the side effect of
making it nullable).

However, given the current workings, Type $foo = null IS in fact nullable,
therefore the string representation of that type is in fact ?Type. To
handle this in code written around current __toString seems pretty simple:

$type = method_exists($RefType, 'getName') ? $RefType->getName() : (string)
$RefType;

Given how simple that is, I'm not understanding what makes it such a big
deal for you (or anyone else) either?


>
> Nicolas
> p.s. to Nikita: my bad for the too short quote...
>

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Ryan Pallas]

On Fri, Sep 2, 2016 at 1:32 PM, Davey Shafik  wrote:

> Hi internals,
>
> I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove
> in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+)
> in their place.
>
> https://wiki.php.net/rfc/deprecate-pear-include-composer
>
> I highly recommend reading the twitter poll and accompanying thread at
> https://twitter.com/dshafik/status/756337267547832320
>
> I believe that pickle solves the issues with regards to pecl, and have run
> the idea passed Jordi and Pierre. Both are fine with this RFC. :)
>
> I understand that adding in composer/pickle is just setting us up for
> having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
> I've proposed the voting reflect that some people will just want to
> deprecate/remove pear/pecl and not replace them at all.
>
> I'm also proposing voting choices around the optional/default introduction
> of composer/pickle.
>

I like the idea, my only concern is that pickle hasn't been committed to
master in many months and the build is listed as failing.  In fact the last
release (v0.4 from what I can tell) also shows the build as failing?


> - Davey
>

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Argon2 Password Hash

[Ryan Pallas]

On Fri, Aug 5, 2016 at 8:49 AM, Charles R. Portwood II <
charlesportwoo...@erianna.com> wrote:

> On Fri, Aug 5, 2016 at 9:19 AM, Tom Worster  wrote:
>
> > On 8/5/16 8:47 AM, Charles R. Portwood II wrote:
>
> Finally, I wonder if it wouldn't be better if, for the time being, we
> > do not provide default costs constants. Argon2 is new (as crypto algos
> > go) and very early in a gradual introduction in deployments. And it is
> > hard to use because of the three cost factors. Correctly tuning those
> > for different machines is not yet a commonly-understood skill. (You
> > even can find conflicting advice on how to tune Bcrypt's time factor.)
> >
>
>
> If, on the other hand, we omit the constants and require the $options
> > argument then it discourages inexpert users. At the same time it
> > encourages experimentation and understanding of the costs, among those
> > who take an interest, which I think is just what we want.
>
>
> The rationale for providing defaults is to ensure the password_* functions
> remain easy to use. Assuming that at some point PASSWORD_ARGON2I (or any
> new algorithm) would become PASSWORD_DEFAULT, the end user's expectations
> would be that *password_hash($password, PASSWORD_DEFAULT)* just works,
> without needing to specify additional arguments.
>

I think this is the most important part to consider. If you make $options
required for this algo, then making this algo the PASSWORD_DEFAULT would
mean that its a backwards incompatible change, because now all calls to
password_hash($password, PASSWORD_DEFAULT) would need to be updated to use
an older constant or pass in $options which I think totally defeats the
purpose of the password_hash API.

Please keep it so that defaults will work, but $options is available for
tuning as that's how the feature currently works.

Re: [PHP-DEV] optionally return class name from gettype

[Ryan Pallas]

I love this idea (as I've written much the same code before), I do think it
will require a full RFC though.

On Fri, Jul 29, 2016 at 7:53 AM, Timothy Younger 
wrote:

> hi Internals Team,
>
> i find myself writing this line frequently in projects:
>
> is_object($value) ? get_class($value) : gettype($value);
>
> it seems i'm not the only one:
>
>
> https://github.com/search?l=php=get_class+gettype=searchresults=Code=%E2%9C%93
>
> although it is small, it amounts to a lot of duplicated logic in need of
> testing. i'm looking to write that line, and its tests, one last time.
>
> i think it's a bit trivial to warrant a standalone lib, but might already
> exist or fit in some helper package.
>
> instead, what do you think about an optional param for the gettype method
> to provide this functionality? here's the new (hopefully
> backwards-compatible) behavior:
>
> var_dump(gettype(new \stdClass(), true));
> string(8) "stdClass"
>
> var_dump(gettype(new \stdClass()));
> string(6) "object"
>
> here's my commit, proposed for php/php-src:
>
>
> https://github.com/abacaphiliac/php-src/commit/f4e2fae9145cec5af94f197acf71dae02cd61b08
>
> and my commit's build on travis:
>
> https://travis-ci.org/abacaphiliac/php-src/builds/148218512
>
> any interest? if gettype isn't the right home for this logic, then perhaps
> someplace else?
>
> thank you.
> Tim Younger
>

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

[Ryan Pallas]

On Fri, Jul 22, 2016 at 1:31 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:

>
> > The trick with the magic class name and namespace aliasing is neat, but
> feels likely to confuse a lot of users
>
> Yes, I have to agree. Maybe more better way is to make it similar to
> set_error_handler() - not for context as it is in RFC, but for 'escape'
> callable.
>
> 
> // somewhere in application
>
> set_escape_handler(function($string, $context = 'html'){
> ...
> });
>
> // or
>
> set_escape_handler([$this, 'escape']);
> ?>
>
> 
>

Which begs the question, if you can verify that the call to
set_escape_handler comes before the template, then can you also be sure
that a function definition will come before it, and just call a function
directly?

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

[Ryan Pallas]

On Wed, Jul 20, 2016 at 12:17 PM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:

> > Personally I don't know any developer who is using raw php in project
> without template engine
>
> Zend, Yii, various CMS like Wordperss, internal business-applications - in
> many cases such projects don't have a template engine.
> I usually work with Yii and internal applications on custom engines. This
> is the reason why I raised this question.
> By the way, the syntax is not weird. It is just . How to
> use $var2 is fully up to application.
>

I guess the question here then is, if people aren't using templating and
haven't written any of their own wrappers to sanitize the output. Then what
is going to drive them to use this new syntax, especially if some aspect is
still up to them? We see lots of projects not updated to use new features,
so if projects are already allowing bad practices what's going to drive
them to change?

Re: [PHP-DEV] New escaped output operator

[Ryan Pallas]

On Thu, Jun 30, 2016 at 1:35 PM, Михаил Востриков <
michael.vostri...@gmail.com> wrote:

>
>
> - Other people will ask about operator for another context
> And you can say: We already added an operator for the main web context,
> because it is the most frequently used context. If you have a lot of work
> with other contexts, please use template engine.
>
>
If you're answer for the other contexts is to use a template engine, why is
the answer for this not to use a template engine? You want to add this
because people don't use template engine, so what makes you think they will
use this when there is a valid solution already available?

Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

[Ryan Pallas]

On Sun, Jun 5, 2016 at 6:09 AM, Robert Stoll  wrote:

> Hi Andrea, Bob
>
> > -Ursprüngliche Nachricht-
> > Von: Bob Weinand [mailto:bobw...@hotmail.com]
> > Gesendet: Sonntag, 5. Juni 2016 01:00
> > An: Andrea Faulds
> > Cc: internals@lists.php.net
> > Betreff: Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types
> >
> >
> > > Am 05.06.2016 um 00:55 schrieb Andrea Faulds :
> > >
> > > Hi again,
> > >
> > > In an attempt to be constructive, I have implemented an alternative
> approach to weak scalar type selection here:
> > >
> > >
> https://github.com/krakjoe/php-src/compare/multi-types...TazeTSchnitzel:multi-types-roulette
> > >
> > > Where there is no exact scalar type match, this patch uses an
> algorithm originally suggested by Nikita, wherein we
> use
> > rand() to pick which type to cast to.
> > >
> > > This is much simpler than having a type precedence matrix, and thus is
> easier to remember and reason about. The
> choice
> > of selection function means that no particular use-case is privileged.
> Given PHP's scalar types are roughly equivalent
> (after
> > all, PHP juggles them freely), this apparently unorthodox selection
> process should nonetheless produce sensible
> results in
> > most cases.
> > >
> > > Please tell me your thoughts!
> > >
> > > --
> > > Andrea Faulds
> > > https://ajf.me/ 
> > This is the holy grail I was hunting for so long!
> >
> > All my computational problems can be solved by a simple rand()!
> >
> > In case nobody objects I'm going to merge that straight ahead into
> php-src 7.0 (no need for master-only, after all
> it's no real
> > BC break!).
> >
> > Thanks a very much!!!
> >
> > Bob
>
> Not sure if this is a clever idea. I haven't read all emails so bear with
> me if this is more than clear. What happens
> with the following?
>
> function foo(int | string $a) {
>   if ($a == "") {
> //a
>   } else {
> //b
>   }
> }
>
> foo(false);
>
> What branch is taken? Is it taken randomly?
>

In this case, A will always be taken, because of the loose comparison (==).
Basically:

var_dump("" == ""); // bool(true)
var_dump(0 == ""); // bool(true)
var_dump(false == ""); // bool(true)

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

Re: [PHP-DEV] Set object properties inline

[Ryan Pallas]

On Wed, Jun 1, 2016 at 9:37 AM, Matt Fonda  wrote:
>
>
> Hi Jesse,
>
> It's fairly straightforward to implement a function that does this in
> userland, for example something like the following:
>
> function f($fqcn, $args) {
> $instance = new $fqcn;
> foreach ($args as $key => $value) {
> $instance->$key = $value;
> }
> return $instance;
> }
> ...
> $this->fooMethod(
> $arg1,
> $arg2,
> f('FooParams', [
> 'prop1' => ...,
> 'prop2' => ...,
> 'prop3' => f('Obj1', [
> 'prop1' => ...,
> 'prop2' => ...,
> ],
> ])
> );
>
> You may also use the approach Peter suggested. As such, I don't think
> introducing a new syntax for it is necessary.
>

I disagree here. This lets you add dynamic properties accidentally (by
putting too many entries in the array or misspelling a property as a key),
this method does not let IDEs help you with the construction of the array,
or even what's valid for each value in that array and doesn't provide any
language level protection against misspelled properties. Of course, for the
last point, I'm assuming that this idea works like the following:

class Foo {
   public $prop1;
}

new Foo () {
porp1 = 'foo' // undefined property error of some sort
};


> Best,
> --Matt
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Ryan Pallas]

On Fri, May 27, 2016 at 6:34 AM, Lester Caine  wrote:

> On 27/05/16 11:25, Fleshgrinder wrote:
> > On 5/27/2016 11:41 AM, Lester Caine wrote:
> >> Now I am confused, but it's probably because I'm looking at a simple
> >>
> >> $f->d = new DateTime( $initial );
> >>
> >> While you are looking at
> >>
> >> If ( isset($initial) )
> >> then $f->d = new DateTime( $initial );
> >> else $f->d = null;
> >>
> >> While the original code would have simply been
> >>
> >> $f->d = $initial;
> >>
> >> And in an ideal world, because $d has been typed as DateTime this would
> >> magically run 'new DateTime($initial)' which is where I am stumbling
> >> because *I* simply look at '?DateTime $d' as creating a DateTime object
> >> where in fact $d is a different type of object which will then hold the
> >> link to the real one. I am still looking for $d to be an object I can do
> >> all of the checks on that are provided by int or DateTime as appropriate
> >> ... the object needs to exist before the 'new' in order to know if you
> >> need the first or second type of $initial code ... or we make typed
> >> properties only work one way or the other?
> >
> > PHP does not automagically instantiate the DateTime object for you, this
> > is still your responsibility. The type hint on the property only
> > restricts what you are allowed to assign to the property, nothing else.
>
> If you want something to magically happen when setting a property, PHP has
a way to do this called magic methods. Think about this:

class Person {
   protected ?DateTime $death;

   public function setDeath($date) {
  if (!empty($date) && is_string($date)) {
 $this->death = new DateTime($date);
  }
  elseif ($date instanceof DateTime) {
  $this->death = $date;
  }
  // else $date is empty, person has not died
   }

   public function __set($prop, $val) {
  if (method_exists($this, "set_$prop")) {
 $this->{"set_$prop"}($val);
  }
   }

   public function __get($prop) {
   if (property_exists($this, $prop)) {
  return $this->$prop;
   }
   }
}

$p = new Person();
$p->death = "2015-06-01";
var_dump($p->death); // class DateTime#1 (3) { ...

$p2 = new Person();
$p2->death = new DateTime("2016-01-02");
var_dump($p2->death); // class DateTime#1 (3) { ...

$p3 = new Person();
var_dump($p3->death); // NULL, $p3 is not dead

Note, all of this is possible currently except the typing of the property,
you could enforce this right now in exactly this way.

If however, you want an object that will provide a format function (as in
your example) whether or not it was initiated with a value, then you would
need to define your own class for that:

class MyDateTime {
protected $dt;

public function __construct($date) {
if (!empty($date)) {
   $this->dt = new DateTime($date);
}
}

   public function format($format) {
  if (!empty($this->dt)) {
  return $this->dt->format($format);
  }
  return '';
   }
}

Now you can blindly initialize it, and call format on it, whether or not
the date is provided. This is all controllable in userland, there is no
reason to make the language do it for you, as its purely a design decision.

Re: [PHP-DEV] Exception::getLine()

[Ryan Pallas]

On Thu, May 19, 2016 at 1:47 PM, Rowan Collins 
wrote:

> On 19/05/2016 19:35, Rasmus Schultz wrote:
>
>> Technically, every throw is a new exception "flow" - even if you're >
>> recycling the Exception instance, it's the throw statement that >
>>
> starts the unique stack unwind from the throw site; it's where the >
> action happens.
>
> That's one interpretation, but it doesn't really hold up in all cases.
> Consider a catch statement that needs to filter more granularly than the
> class name; since you already mentioned PDO, I'll make an example with that:
>
> catch ( PDOException $e ) {
> if ( substr($e->getCode(), 0, 2) === '08' ) {
> $this->reconnect();
> } else {
> throw $e;
> }
> }
>
> Of what value to a subsequent catch statement is the trace of that throw
> statement? And why does that "start a new exception flow", but if PDO threw
> different sub-classes, you could let one flow through unmodified by
> tightening the catch statement?
>

True, but if you instead of throwing the same exception, threw a new one,
you could capture both stacks. But you can never get the stack from the
throw point of something created elsewhere.

catch ( PDOException $e ) {
if ( substr($e->getCode(), 0, 2) === '08' ) {
$this->reconnect();
} else {
throw new PDOException($e->getMessage(), $e->getCode(), $e);
}
}



> Regards,
> --
> Rowan Collins
> [IMSoP]
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Pipe Operator

[Ryan Pallas]

On Tue, May 17, 2016 at 6:15 AM, François Laupretre 
wrote:
>
>
>
>> The question of function aliases is not so serious because we'll need very
>>> few. Almost every functions have only one 'natural' argument to
>>> substitute
>>> as lhs. I'm not sure I understand what you mean with 'but only in certain
>>> situations'.
>>>
>>> If it were so natural, wouldn't the original version of these
>> functions have been made "right" in the first place?  I fear that the
>> only thing we'd gain by adding all these aliases is more functions,
>> but without the benefit of any improvement in the argument ordering
>> problem because now, instead of remembering which order the argument
>> is in, users have to remember which alias to call.
>>
>
> Right. That's why I propose we start without creating any function alias.
> We're not supposed to allow writing anything in a pipeline. For every
> functions, the substituted argument will always be the
> haystack|subject|source|input argument. That's easy to remember.
>

Which I don't think covers many use cases that the Pipe Operator would
currently solve. Doing this would lessen its usefulness IMO. Think about
common string nesting like:

$var = substr($var, 0, strpos($var, $othervar));

With current Pipe it would be:

$var = strpos($var, $othervar)
   |> substr($var, 0, $$);

but your suggestion requires this be kept nested as only haystack is
allowed? That totally weakens the proposal in my book.

@Sara: Can the place holder be used twice? If its numeric, can I make it
negative or perform other math? I don't see anything in the RFC allowing or
disallowing such things. Such as:

$var = strlen($str)
|> substr($var, -$$, $$/2)

Re: [PHP-DEV] [RFC] Pipe Operator

[Ryan Pallas]

On Tue, May 3, 2016 at 2:35 PM, Fleshgrinder <p...@fleshgrinder.com> wrote:

> On 5/3/2016 10:22 PM, Ryan Pallas wrote:
> > I have to disagree, I haven't seen an example of rewriting the original
> > example from the RFC in a more expressive AND readable way. Yes, you can
> > use lots of intermediate variables, but this makes the code HARDER to
> read
> > QUICKLY which is entirely the point of a syntatic sugar addition like
> this.
> > Syntactic sugar makes a language sweeter, and more palatable. Like cane
> > sugar makes your cookies taste good, but doesn't make them more
> nutritious.
> >
>
> Opinions you know but I am still waiting for that example.
>

Waiting for what example? There's been plenty of examples showing how
existing options, rewritten with |> are easier. If you disagree, that's an
opinion, other's agree. If people think its better, why not add it for
them? Like every other feature discussed on this list, nothing is forcing
you to use it.


On Sat, Apr 30, 2016 at 4:00 AM, Thomas Punt <tp...@hotmail.co.uk> wrote:
>
> > From: ocram...@gmail.com
>
> $response = loadConfig()
>  |> buildDic($$)
>  |> getApp($$)
>  |> getRouter($app)
>  |> getDispatcher($$, $request)
>  |> dispatchBusinessLogic($$, $request, new Response())
>  |> renderResponse($$)
>  |> buildPsr7Response($$)
>  |> emit($$);
>
> Without the pipe operator, it could look like the following:
>
> $config = loadConfig();
> $dic = buildDic(config);
> $app = getApp($dic);
> $router getRouter($app);
> $dispatcher = getDispatcher($router, $request);
> $businessResponse = dispatchBusinessLogic($dispatcher, $request, new
> Response());
> $renderedResponse = renderResponse($businessResponse);
> $psr7Response = buildPsr7Response($renderedResponse);
> $response = emit($psr7Response);
>
> That's a lot of unnecessary assignments, however, and the variable names
> don't even provide any additional readability benefits because the function
> names are already self-documenting.
>
>
The first example, with |> is much easier to QUICKLY see what's happening,
because all the function calls are aligned, so I can read quickly top to
bottom knowing what's happening. The second requires much more cognitive
interaction to understand what's going on. Sure you could reformat it to
align all the =, now you have lots of white-space between your variables
and what you're assigning to them... equally as bad in my book.



>
> On 5/3/2016 10:22 PM, Ryan Pallas wrote:
> > This breaks dependency injection, and makes testing harder.  You now
> depend
> > on an array of data which is accessed internally, and can only minimally
> > control it's contents in a testing environment.
> >
>
> Why do you need dependency injection in the most outer point of your
> application? This should be tested with your acceptance/integration
> tests and nothing else. How many unit tests have you written for your
> Symfony app kernel lately?
>

None, I don't write Symfony apps, however they wrote quite a few [1].


> A rather extreme example of such a /most outer/ but you know how it is
> with constructed examples:
>
>
> http://www.yegor256.com/2014/10/03/di-containers-are-evil.html#the-right-way


GROSS. This would not be allowed any where I do code reviews.


>
>
> On 5/3/2016 10:22 PM, Ryan Pallas wrote:
> > Again, how do I dependency inject a config during testing to make sure I
> > build the dic correctly? I'm assuming you're using a bunch of temporary
> > properties? Also you just made adding a step significantly harder, what
> if
> > from building the app, I need to build another layer build for the
> router,
> > for |> I add ONE line of code, for yours I edit the build function in the
> > right location, and change the build router function to load from a
> > different property, and build another boilerplate function to build this
> > new thing, and add another property to hold this new thing... WHOA
> that's a
> > lot more steps, and a MUCH higher risk of a mistake!
> >
>
> Again, this is the most outer place of everything. I mean, all
> frameworks and applications were and are able to solve these issues
> easily, nicely, and testable. Just because my /proposed/ solution to an
> example that is constructed in the first place is not as nice as those
> solutions does not make the examples better. :P
>

You didn't address the fact that your "solution" makes it much harder to
modify the steps in place.

$ret = getConfig()
  |> buildApp($$)
  |> buildRouter($$)
  |> parseResponse($$);

Shoot, I forgot to build Dispatcher; Let me add that

$ret = getConfig()
  |> buildApp($$)
 

Re: [PHP-DEV] [RFC] Pipe Operator

[Ryan Pallas]

On Tue, May 3, 2016 at 1:28 PM, Fleshgrinder  wrote:

> On 5/3/2016 8:57 PM, Sara Golemon wrote:
> > Ooops, missed a negation when I typed it out.
> >
> > "Pretending that poorly designed libraries DON'T exist is naîve."
> >
>
> I am not pretending that they do not exist, quite the contrary, I
> explicitly stated that they exist and that I fear that this syntactic
> sugar yields more of them in the future.
>
> On 5/3/2016 8:57 PM, Sara Golemon wrote:
> > As I've said already.  Yes, intermediate variables do address this
> > style of coding.  Yes, this proposal is syntactic sugar.
> >
> > Intermediate variables also add cognitive overhead of their own in
> > cataloging all the various intermediates used in a large function.  By
> > removing the explicit intermediate variables and replacing them with
> > unnamed temporaries, the code becomes easier to read because there's
> > less unnecessary assignments cluttering up the space.
> >
>
> Still waiting for a real life example that illustrates exactly that. All
> examples and code I have seen so far is either extremely constructed
> (the request-application-response thingy that is now part of the RFC) or
> can be trivially rewritten to be super expressive and readable (the
> original from the RFC and most in this thread).
>

I have to disagree, I haven't seen an example of rewriting the original
example from the RFC in a more expressive AND readable way. Yes, you can
use lots of intermediate variables, but this makes the code HARDER to read
QUICKLY which is entirely the point of a syntatic sugar addition like this.
Syntactic sugar makes a language sweeter, and more palatable. Like cane
sugar makes your cookies taste good, but doesn't make them more nutritious.


>
>   $request = getGlobals()
>|> parseRequest($$)
>|> buildPsr7Request($$);
>
> Ask, don't tell!


>   final class RequestBuilder {
>
> public static function fromGlobals() {
>   return new static($_GLOBALS);
> }
>
> public function buildPsr7Request() {
>   $parsed_request = $this->parseRequest();
>   return new Psr7Request($parsed_request);
> }
>
>   }
>
>   $request = RequestBuilder::fromGlobals()->buildPsr7Request();
>

This breaks dependency injection, and makes testing harder.  You now depend
on an array of data which is accessed internally, and can only minimally
control it's contents in a testing environment.


>
>   $response = loadConfig()
>|> buildDic($$)
>|> getApp($$)
>|> getRouter($app)
>|> getDispatcher($$, $request)
>|> dispatchBusinessLogic($$, $request, new Response())
>|> renderResponse($$)
>|> buildPsr7Response($$)
>|> emit($$);
>
> Ask, don't tell!
>
>   final class ResponseBuilder {
>
> public static function fromGlobals() {
>   return new static($_GLOBALS);
> }
>
> public function build() {
>   $this->loadConfig();
>   $this->buildDic();
>   $this->buildApp();
>   $this->buildRouter();
>   $this->buildDispatcher();
>   $this->dispatchBusinessLogic();
>   $this->parseResponse();
>
>   return $this->response;
> }
>
>   }
>
>   $response = ResponseBuilder::fromGlobals()->build();
>

Again, how do I dependency inject a config during testing to make sure I
build the dic correctly? I'm assuming you're using a bunch of temporary
properties? Also you just made adding a step significantly harder, what if
from building the app, I need to build another layer build for the router,
for |> I add ONE line of code, for yours I edit the build function in the
right location, and change the build router function to load from a
different property, and build another boilerplate function to build this
new thing, and add another property to hold this new thing... WHOA that's a
lot more steps, and a MUCH higher risk of a mistake!


>
> The third is exactly the same ...
>
> Now my favorite:
>
>   $ret =
> array_merge(
>   $ret,
>   getFileArg(
> array_map(
>   function ($x) use ($arg) { return $arg . '/' . $x; },
>   array_filter(
> scandir($arg),
> function ($x) { return $x !== '.' && $x !== '..'); }
>   )
> )
>   )
> );
>
> I already rewrote it in another message but once more with the most
> relevant parts of my original message:
>
> array_filter with O(n)
>
> array_map with O(n)
>
> array_merge with O(∑ array_i, i != 1) and in our case O(n) where n
> equals the total count of elements in $files/$$.
>
> In my universe `getFileArg` (note the absence of a plural form) would
> operate on a single path and not on an array of paths:
>
>   foreach (new DirectoryIterator($arg) as $path) {
> if ($path->isDot() === false) {
>   $ret[] = getFileArg($arg . DIRECTORY_SEPARATOR . $path);
> }
>   }
>

Again, you're solution is to use OOP, but the pipe operator's purpose is to
make procedural code cleaner. Not one of your solutions maintained a
procedural interface, and therefore 

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

[Ryan Pallas]

On Fri, Apr 29, 2016 at 10:50 AM, Lester Caine  wrote:

> On 29/04/16 16:42, Rowan Collins wrote:
> > function foo($a) {
> > if ( $a < 42 ) { throw new Exception; } // Must not reach The Answer
> > ...
> > }
> >
> > vs
> >
> > <> // Must not reach The Answer
> > function foo($a) { ... }
>
> The first version is my current code base, although it's unlikely to
> throw an exception, more likely to have already validated the data
> before using it so the check is redundant as it is already in the code
> to handle the problem data. But in the second example just where does
> the error redirect traffic? At least with in-line checks you control
> flow ... but just how do you add a range? Does that need different
> 'test' elements?
>
> My main target here IS to add a reliable mechanism to allow every
> variable to have it's own validation attributes. The only current route
> is as php-annotations nicely provided and which dovetails nicely into
> the existing documentation process. Simply adding comments in line is
> useless for the on-line documentation, and it's adding these annotations
> to the documentation in parallel with making the data available in the
> code which I'm trying to address. TRYING to find this even if it is
> commented in the code on 15 year old code is a problem, and being able
> to ADD docBloc annotation which can then be used later provides a
> practical way forward.
>
> I've no problem with an alternate annotation method ... as long as in
> PHP7 it is optional ... but I don't think this 'in-line' approach is
> ACTUALLY the right long term solution to data validation.
>

But his RFC is about adding meta-data, which can be used up to the USER.
The language here is providing no validation, just a means of defining
metadata,
which may in the future be expanded to some built in annotations. Validation
is not specifically the point of this RFC, and the fact that a system could
be built to provide this validation using the meta-data this RFC provides,
does not
limit it to that scope.


>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

[Ryan Pallas]

On Fri, Apr 29, 2016 at 9:18 AM, Lester Caine  wrote:

> On 29/04/16 14:51, Rowan Collins wrote:
> > Lester Caine wrote on 29/04/2016 14:18:
> >> But where will annotations like @range(0,110) fit in the new model?
> >> Along with the likes of '@notnull' and similar annotations that are also
> >> currently being planned to be spread around the rest of the code? If a
> >> variable is defined via the metadata as 'not null', then assigning null
> >> to it is an error
> >
> > Hi Lester,
> >
> > Do you mean you are currently using these attributes / annotations with
> > a reflection library to generate assertions in the code and throw errors
> > at runtime? If so, yes, the native syntax will be used for that going
> > forward, once the tools catch up (though they're likely to provide
> > backwards compatibility modes for a fairly long time).
>
> I think that is part of the problem here. IDE's are currently making
> quite good use of existing annotation text, but if they have to be
> switched to modes where some other option takes priority then once again
> all the code has to be reworked ... which is where I'm stuck at the moment.
>

For what reason would you have to rework all the code? Nothing about this
RFC
makes the currently used and working implementations invalid. In fact, I
have a project
written originally in 5.2 that's currently running on 7.0. IIRC, it uses
none of the new
features from 5.4+. I'm still using long hand array syntax (array() vs []),
I'm still using
isset based ternaries (isset($foo)?$foo:'default' vs $foo ?? 'default') and
such things.
However, new code written into this project, since it now runs on 7.0 has
the OPTION
to take advantage of these new features.



>
> > However, there's no support built into the core for doing the actual
> > checks now, and there's no plan (that I know of) to build one in in
> > future. All that's proposed is to add more support in the language for a
> > general syntax which can be used by such tools, to avoid them doing so
> > much string parsing.
> >
> > If you're just using these annotations for documentation (as your
> > references to phpDocumentor imply), then nothing will change: you'll
> > still be able to use them for that, and they still won't be enforced.
> > This is exactly the same as has been true since PHP 5.0 for argument
> > types; the engine never validates anything in the docblock, and it might
> > be completely wrong, and we have separate syntax for actually enforcing
> > checks:
>
> I was looking at php-annotations having realised that it already had
> @range which is the bit I'm trying to automate more. Except it doesn’t
> ... it has stripped the data validation annotations 'because
> phpdocumentor2 does not support them'. HENCE asking the question about
> this important area here ...
>

I'm not sure I follow, the RFC is suggesting adding annotations that CAN
affect
code if a tool or future RFC is written to provide that feature. Currently,
it only
adds meta-data that can be read more efficiently than using
Refelction*::getDocBlock()
and then string parsing this yourself.


>
> > /**
> >  * @param Foo $foo
> >  */
> >  function test(Bar $bar) {}
> >
> > Even if there were no other downsides to the syntax, it would probably
> > be a bad idea for the core to start enforcing things based on docblocks,
> > because it would potentially break a lot of code that had them written
> > wrong. Indeed, it is for precisely this reason that a new syntax is
> > being proposed for general machine-readable attributes (rather than just
> > functions for parsing the docblock), so that we can return to seeing
> > docblocks as just comments, with no meaning for the code.
>
> To repeat ... what happens where an IDE has code with both styles of
> working? You are exactly right but does adding something extra ACTUALLY
> make life easy where we have well documented code and IDE's which
> support it.
>

Currently, my IDE supports every feature that has multiple pathways (both
long
form and short form array works is recognized, mysql_* is still recognized,
even
though its completely removed from php7).


> > In short:
> > - if you're generating documentation from docblocks, it's up to the
> > program doing the generating what to interpret, and nothing is going to
> > change that
> > - if you're generating behaviour from docblocks, it's up to the library
> > doing the generating what to interpret, and what will change is them
> > recommending the new dedicated syntax if it's implemented, because it
> > will be more efficient to process
>
> As with 'strict typing' we add different styles of working which in some
> longer term world may be an elegant solution but short term just creates
> an annoying different way of doing a bit of the job? The current
> proposal is offering a fix for a style of working which I still don't
> understand, because I can't 'read' easily the examples being given.
>
> < 0")>>
> function foo($a, $b) {

Re: [PHP-DEV] [RFC] PHP Attributes

[Ryan Pallas]

On Thu, Apr 21, 2016 at 4:51 PM, Dmitry Stogov  wrote:
>
>
>> About expressions, isn't there an ambigoutiy? <> is a "plain"
>> name, value based attribute. But it could also be an ast\node of a function
>> call to "test(1)"
>>
> even in AST scalars are scalars.
> so <> would return: ast\node "+" with two children int(1) and
> int(2).
>
> I am wondering if they shouldn't get their own start/end signs to clear
>> that up, <<> vs <>.
>>
>
> no need for extra complication.
>
> Since the encapsulated meta-data is an AST, and as you say any valid php
expression will be valid here, what about bit shifting?

<> BAR)>>

Are there concerns about finding the T_SR token, which is also the end
annotation symbol? I've not done any work in the parser, so excuse me if
that is an insanely stupid question :)

Otherwise, I think this RFC looks great, and appreciate your work on this :)

Ryan

Re: [PHP-DEV] Quick sanity check ...

[Ryan Pallas]

On Wed, Apr 20, 2016 at 2:01 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > The outcome is easy to grasp. Because it did not crash by a TypeError
> > (which would also require the file to be declared as strict), and we lost
> > 100k in sales. But PHP does not need more strictness...
>
> In other words, somebody wrote code that is supposed to only accept ints
> but does no checks. Somebody wrote tests that actually don't test
> anything. Somebody signed off on code that was not properly designed or
> tested to go into production. And the language is to blame. Right.
>

+1

>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC:generics]

[Ryan Pallas]

On Wed, Apr 20, 2016 at 1:17 PM, Dominic Grostate <
codekest...@googlemail.com> wrote:

> Thanks for you're input everyone.
>
> So far, we have read some ideas for handling upper bounds, or multiple
> there of.
> The preferred keywords appear to be either "as" or "instanceof".
>
> class Foo {}
> class Foo {}
>
> We would like to know for sure then if everyone is largely against the
> addition of an "is" keyword, in favour of one of the other two.
>

I like instanceof the most, as I feel its more obvious. "is" is good IMO
from a user perspective, tho its a new keyword, its pretty obvious what's
happening (my T IS something, and will not be anything else). "as" makes me
feel like its going to either type-cast or T is going to be aliased as Bar
for later use in the class definition.


> 
>
> There is also a desire to include unions and intersections.
> Presently though, this feature feels tied in with
> https://wiki.php.net/rfc/union_types meaning if union types are approved,
> then generics would have to support them as well.  Likewise if this feature
> becomes approved in generics, it would make sense to support them in
> regular type hints as well.
>

Agreed, I think this should be left until after both RFCs have been decided
on.


>
> 
>
> The RFC makes a reference to generic closures, which may look something
> like this:
>
> function my_function(callable $func) {
>
> }
>
> However, an RFC already exists which is very similar to this feature at
> https://wiki.php.net/rfc/callable-types
> As it currently standards these RFCs appear incompatible with each other
> (please correct me if I am wrong).
>
> My question about this is would you prefer the generics RFC exclude this
> part in favour of a separate or later RFC.
> Initially the proposal included generic arrays "array".  However to
> ease the implementation it was decided that should be a separate feature.
> So we'd like to find out if everyone else feels the same way about callable
> types.
>

This makes sense to me to leave it separate. Lets get generic classes first.


>
> 
>
> This RFC currently doesn't specify in detail how reflection would work.  We
> have attempted a few API designs, but due to generic classes being ...
> generic, it is difficult to find a suitable way to glean information about
> a class in a backwards compatible manner.  So we will need some help on
> this one.
>
> -
>
> Aside from these top issues on our own list, however does everyone feel
> about the proposal in general?
> As the RFC is still in draft, we will continue to make changes to it as
> more popular idea pop up, so please continue.
>

I think the RFC looks pretty great. I think you guys have put in a lot of
very good work speccing it out, thanks for that. As generics are the
biggest thing I feel missing that I use elsewhere, I really hope this
change gets accepted and fully working implementation!


>
> Thanks.
>
> PS: I wasn't properly subscribed to the mailing list, so I missed a few
> important messages that were mailed directly to internals, but hopefully
> I've managed to fix that now.
>

Re: [PHP-DEV] Re: Improving PHP's type system

[Ryan Pallas]

On Sat, Apr 16, 2016 at 4:10 AM, Bastian Schneider <
bastian.schnei...@commerce-plus.com> wrote:

>
> Just a quick thought. I would prefer something like
>
> union Iterable {
> use array;
> use ArrayAccess;
> use Traversable;
> }
>
> function bla(Iterable $iterable) {
> foreach($iterable as $element) {}
> }
>
> Primitives like string, float, bool or int are not allowed in union. Only
> classes, interfaces and array. I doesn't see any benefit in combining
> string with int or int with float in one union.
>

Here's an example that shows combining scalar maybe useful:

union Numeric {
use int;
use float;
}

Something I would very much like to use where types are allowed.


>
> Do I overlook or missed anything?
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC Discussion] Typed Properties

[Ryan Pallas]

On Tue, Mar 29, 2016 at 5:16 PM, Levi Morrison  wrote:

> > 2) The handling of multiple properties in the same declaration statement
> is inconsistent.
> >
> > public int $bar, string $qux; // this works
> >
> > public int $bar, $qux; //this emits error: Untyped property
> A::$qux must not be mixed with typed properties
> >
> > It's better to allow type only before first property in the list and
> apply them to all of them (like C, Java and others).
> > Is this just an implementation issue?
>
> I'm actually glad this is prevented because it's confusing. Is `$qux`
> typed or untyped?
>

I think its very obviously typed int. This would allow you to list a bunch
of things of the same type in a single declaration, meaning only a single
visibility and type for the line, instead of having to repeat the type for
each property (whilst not having to repeat the visibility, this feels
inconsistent).

public string $firstName, $middleInitial, $lastName, $nickName;

vs

public string $firstName, string $middleInitial, string $lastName, string
$nickName;

I like the first much better personally. The second feels inconsistent, why
would the visibility carry to all properties but not the type?


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

Re: [PHP-DEV] Why is 0x7F permitted in PHP identifiers?

[Ryan Pallas]

On Fri, Mar 25, 2016 at 1:25 PM, Scott Arciszewski 
wrote:

> On Fri, Mar 25, 2016 at 10:20 AM, Andrea Faulds  wrote:
>
> > Hi everyone,
> >
> > Identifiers in PHP source code (including variables names with $) conform
> > to the regex /[_a-zA-Z\x7F-\xFF][_0-9a-zA-Z\x7F-\xFF]*/. Most of this
> regex
> > is pretty standard: it allows alphanumeric ASCII characters and
> > underscores, plus any character with the 8th bit set (presumably to allow
> > any extension of ASCII, such as Latin-1 or UTF-8, to be used).
> >
> > But there's one part of this I find rather curious: why is \x7F included?
> > It's not a high-byte/8-bit character, it's a 7-bit ASCII character, and a
> > control character at that. Unless there's some ASCII extension which
> reuses
> > that value as a printing character, I assume it must have been a mistake
> to
> > include this character. As a control character, it is invisible and
> > difficult to type, and it might do weird things in some terminal
> emulators.
> > I can't see the value in permitting it within an identifier.
> >
> > I've done a little bit of looking around, and I can't find an important
> > ASCII extension which changes what 0x7F does. Given that, I assume it was
> > simply a mistake. But one of you might be able to enlighten me otherwise.
> >
> > I've filed a bug report, and made a patch to fix this in php-src and
> > php-langspec master:
> >
> > https://bugs.php.net/bug.php?id=71897
> >
> > Thanks!
> > --
> > Andrea Faulds
> > https://ajf.me/
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> ​Interestingly, extract() skips keys with \x7F: https://3v4l.org/ZC9ZA\
>

Also the keys after the \x7F were not present in HHVM, PHP7, however in
5.5-5.6 you get
[9]=>string(1) ""
along with they key that came after it. That's very strange indeed!


> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises ​
>

Re: [PHP-DEV] Add spaceship assignment operator

[Ryan Pallas]

Hi Nikita,

On Thu, Mar 24, 2016 at 11:50 AM, Nikita Popov  wrote:

> Hi internals!
>
> For consistency, we should add a spaceship assignment operator:
>
> $a <=>= $b;
> // same as
> $a = ($a <=> $b);
>

I'm not sure I see a use case for this, when do you compare 2 values and
replace one of those values with the result of the comparison? I've
literally never done that.


>
> Additionally, we should add an is-identical assignment operator:
>
> $a  $b;
> // same as
> $a = ($a === $b);
>

Again, why would you do this? How often are you replacing the contents of a
variable with the results of comparing it with something else?

$c = $a === $b;
$c = $a <=> $b;

That seems to be far more common if assigning the results to a variable at
all (which is itself not that common for comparisons in my experience).


>
> Thank you for taking this proposal under consideration.
>
> Regards,
> Nikita
>

Thanks for bringing this up, but I don't see the consistency argument, and
I don't feel like its normal use cases at all.

Re: [PHP-DEV] [RFC] [Vote] Short Ternary Assignment Operator

[Ryan Pallas]

On Thu, Mar 24, 2016 at 9:51 AM, Sara Golemon  wrote:

> Following on from Midori, I've moved the short-ternary assignment
> operator RFC into voting phase.
> The implementation for which will be her patch with appropriately
> different symbols and tests.
> https://wiki.php.net/rfc/short_ternary_equal_operator


I like this as well, +1 for me :) Good luck, hope to see it in 7.1!


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

Re: [PHP-DEV] [RFC][Voting] Null Coalesce Equal Operator

[Ryan Pallas]

On Thu, Mar 24, 2016 at 9:02 AM, Midori Kocak  wrote:

> Hi,
>
> Remember Null coalesce Equal Operator ??= She is in voting phase now. :)
>
> https://wiki.php.net/rfc/null_coalesce_equal_operator <
> https://wiki.php.net/rfc/null_coalesce_equal_operator>


I don't get to vote, but I'm very much +1 on this. Good luck!



>
> Thank you so much,
> Midori
> http://www.mynameismidori.com 

Re: [PHP-DEV] [RFC Discussion] Typed Properties

[Ryan Pallas]

On Wed, Mar 16, 2016 at 12:50 PM, Larry Garfield 
wrote:

> On 3/16/16 11:36 AM, Phil Sturgeon wrote:
>
>>
>> 2. This whole temporary nullability situation, where unset properties
>> will error on attempted usage if not set. Should they instead error
>> after the constructor has been called if they are still not holding a
>> value?
>>
>
> I fall back to a statement I made in a blog post a while back:
>
> http://www.garfieldtech.com/blog/empty-return-values
>
> " But consider what you could do instead that would not force me to throw
> is_null() around my code, because throwing is_null() around my code makes
> me sad. NULL should be the return value of last resort, because it means
> nothing. (Literally.)"
>
> Allowing default-null on properties means that as someone using that
> property, I have two options:
>
> 1) Throw a lot of is_null() calls around my code.
> 2) Assume that whoever initialized the code provided a value by the time
> initialization is done and skip those extra checks.
>
> Insert that old adage about what happens when you assume.
>
> End-of-constructor checks seem like a good approach; they have to be
> uninitialized at some point when new is called initially, but they should
> be guaranteed set as soon as possible.  End of the constructor is "as soon
> as possible", and I think reasonably static-analysis-catchable.  (Meaning
> my IDE can yell at me appropriately.)
>
> That removes is_null() calls from the rest of my codebase, which is a good
> thing.
>
>
I'm not sure I like the "after contructor" because that's not necessarily
when the object is finished being initialized. Consider this:

abstract class Contract
{
private function __construct() {}

public static function fromArray(array $aProps) : Contract
{
$s = new static();
foreach ($aProps as $k => $v) {
if (property_exists(static::class, $k)) {
$s->$k = $v;
}
}

return $s;
}
}

class User extends Contract {
   public int $id;
   public string $name;
}

$user = User::fromArray(['id' => 123, 'name' => 'derokorian']);

In this example, the constructor finishes but the properties still are not
initialized at time of finishing. This is a pretty common pattern as well.

Re: [PHP-DEV] [RFC Proposal] Null Coalesce Equal Operator

[Ryan Pallas]

On Wed, Mar 9, 2016 at 11:14 AM, Midori Kocak  wrote:

> Hi all,
>
> Remember my question about ??= operator?
>
> Forgive my rookieness and let me introduce my first RFC here:
> https://wiki.php.net/rfc/null_coalesce_equal_operator <
> https://wiki.php.net/rfc/null_coalesce_equal_operator>
>

This looks great! I hope it makes it into the language for sure.

One comment though, voting section should not be opened until after the
required discussion period.

Re: [PHP-DEV] [RFC] Callable constructors

[Ryan Pallas]

On Thu, Feb 25, 2016 at 11:31 AM, Ryan Pallas <derokor...@gmail.com> wrote:

>
>
> On Thu, Feb 25, 2016 at 11:20 AM, Marco Pivetta <ocram...@gmail.com>
> wrote:
>
>> Just adding to the use-cases: I really could've needed this the other day:
>>
>>
>> $records = array_map([MyRecord::class, '__construct'],
>> $db->someQuery()->fetchAll());
>>
>> I used a named constructor instead, but this results with more internal
>> method calls:
>>
>> $records = array_map([MyRecord::class, 'fromResultSetRow'],
>> $db->someQuery()->fetchAll());
>>
>
> If fetchAll is coming from PDO. then you could have simply done this:
>
> $records = $db->someQuery()->fetchAll(MyRecord::class);
>

Sorry, that should have been

$records = $db->someQuery()->fetchAll(PDO::FETCH_CLASS, $MyRecord::class);

Re: [PHP-DEV] [RFC] Callable constructors

[Ryan Pallas]

On Thu, Feb 25, 2016 at 11:20 AM, Marco Pivetta  wrote:

> Just adding to the use-cases: I really could've needed this the other day:
>
>
> $records = array_map([MyRecord::class, '__construct'],
> $db->someQuery()->fetchAll());
>
> I used a named constructor instead, but this results with more internal
> method calls:
>
> $records = array_map([MyRecord::class, 'fromResultSetRow'],
> $db->someQuery()->fetchAll());
>

If fetchAll is coming from PDO. then you could have simply done this:

$records = $db->someQuery()->fetchAll(MyRecord::class);

Re: [PHP-DEV] [RFC] Callable constructors

[Ryan Pallas]

On Thu, Feb 25, 2016 at 9:44 AM, Dan Ackroyd  wrote:

> Hello internals,
>
> I've written a small RFC to make it possible to call constructors of
> objects as a callable, rather than only being able to call them
> through the 'new' language construct.
>
> https://wiki.php.net/rfc/callableconstructors
>
> After gathering informal feedback for the RFC, one person said that
> they felt it needed more of an emphasis on why it should be
> implemented. I wanted to keep the actual RFC short, in the hope that
> more people would read it in it's entirety, and also wanted to leave
> library specific code out of the RFC. So, as an addendum to the RFC
> text:
>
> I use the Auryn* DIC library. What I've wanted to do, and should be
> able to do in my opinion, is this:
>
> $injector->delegate('FooInterface', 'FooImplementation::__construct');


> Which tells the injector "Whenever something requests an object that
> implements FooInterface as a dependency, just execute the
> FooImplementation constructor to make that object".
>

How is this any better, or what benefit would it provide over the current
implementation, which takes a class name and then calls new on it
when the Interface is asked for?

Moreover, if you want to pass in a callable that creates the class, why not
just create a method on that class called create (or whatever) much the
same way that singletons often work.

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

[Ryan Pallas]

On Wed, Jan 13, 2016 at 7:55 AM, Rouven Weßling 
wrote:

>
> > On 13 Jan 2016, at 14:57, Zeev Suraski  wrote:
> >
> > I don't see it that way. I think I provided very relevant feedback -
> that yes, called for a very substantial revision of the proposal and a
> removal of a substantial part of it - but I still marked the concept of
> having a CoC as a good idea from the get go.  Separately, I think that if
> people think that a given proposal is a bad idea and cannot be improved -
> it's perfectly fine that they would voice their opinion.  Some ideas are
> just bad, and RFCs are often withdrawn or fail to pass.  Personally I don't
> think the CoC proposal is inherently bad - quite the opposite - but I think
> its implementation the way it's currently phrased is quite negative.  To be
> perfectly honest, I'm offended that despite spending literally hours on
> providing feedback and making my case for why even the latest draft is
> problematic (and how I think it can be improved to reach consensus) -
> feedback that were completely respectful - I received no response from any
> proponent of the RFC.  The same holds true for several other people - who
> provided relevant feedback which went ignored.  In fact, the response came
> as saying 'No more feedback please.  My next email will be presenting a
> final draft, after which I'll go to a vote after the minimum allotted time'.
>
> As someone who is only occasionally participating on internals, maybe my
> 2ct are worthwhile here. Note that I’ve only read the first ~150 emails
> (out of currently 323 mails) on the CoC thread - at some point it just took
> up too much time - so my opinion is based on that sample.
>
> What happened in that thread (in other bigger discussions before) is that
> people feel the urge to reply to every point individually as soon as they
> see the mail. In my experience it’s much better to make a point, stand back
> while feedback comes in (also helps calm you if a topic agitates someone -
> it’s ok to have strong feeling, but getting angry isn’t helpful) and then
> respond to accumulated feedback in one email. Yes that’s more work than
> just firing off a quick reply, but quick replies aren’t what’s needed in a
> discussion of (hopefully) well considered arguments.
>
> Instead what we have is people writing 6 emails in 15 minutes (admittedly
> an extreme example), someone writing a reply to the first message before
> the last message is even written, which then also gets an email and so.
> Also people seem to repeat themselves quite a bit. This makes it
> *incredibly* time consuming to follow just one issue, let alone the entire
> mailing lists.
>
> TL;DR: If you find yourself replying more than once an hour to a thread,
> something is wrong.
>
>
>
Yup, this is explicitly part of "mailing list rules"

Do not post when you are angry. Any post can wait a few hours. Review
  your post after a good breather or a good nights sleep.

Try to wait a bit longer before
  sending your replies to give other people more time to digest your answers
  and more importantly give you the opportunity to make sure that you
  aggregate your current position into a single mail instead of multiple
  ones. [1]


Of course, it also says things like "Do not top post" and we see how often
that happens...

[1]
http://git.php.net/?p=php-src.git;a=blob_plain;f=README.MAILINGLIST_RULES;hb=HEAD

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Ryan Pallas]

On Fri, Jan 8, 2016 at 10:28 AM, Paul M. Jones  wrote:

>
> > On Jan 7, 2016, at 23:52, Larry Garfield  wrote:
> >
> > Do you think we can find 5 people in the PHP community that we can trust
> to make fair decisions (NOT that we would always agree with, but that are
> fair) that don't fall too far into "thought policing", in *any* direction?
> If not, then the community is already lost beyond all hope and we should
> all just give up now.  I do not believe that to be the case, at all.
>
> Too long spent in a position of power, and even the most fair can become
> unfair.
>
> As I have suggested before: *if* there is to be a response team, let it be
> randomly selected on per-reported-incident basis from the pool of voters.
> Then there is no possibility of a charge of continuing bias, and it
> distributes power among the pool, instead of concentrating it into a few
> members.
>
> Proponents of the response team: thoughts?
>

I would prefer to see the team picked for the next occurence immediately
after one happens. This way, if the resolution can be handled by just
having a calm conversation with the interested parties, then there is no
need to make it public. Instead, the mediators would say "A conflict has
occurred and a new team needs to be in place".

Or maybe something like 1 month duty at a time, but team membership may
last beyond a month, if no conflicts were had during that month. IE, you
get put on the team, you may "serve" for a year if no conflicts arise. Or
you may only server for a month, if a conflict does arrive (I think an
upper bounds when no conflicts may not be required, but should be
considered if this suggestion is taken to heart at all).


>
>
> --
> Paul M. Jones
> pmjone...@gmail.com
> 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] Deprecation of the Error Control Operator (@ symbol)

[Ryan Pallas]

On Fri, Jan 8, 2016 at 11:21 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > $counts[$item] ?? $counts[$item] = 1 ?? $counts[$item]++;
>
> This looks completely unreadable and I do not think it works:
> https://3v4l.org/PlAHH
> Seems to leave $counts as 1 always. But even if it didn't, I would never
> pass that on code review - it is very hard to understand what's going on
> and it is incredibly easy to break it. Doing such stuff is definitely
> not the solution, if you hate @, then if() is way better, at least it's
> clear.
>
> > $item = new StdClass;
> > @$counts[$item] = "This is a bad use of error suppression.";
> >
> > There is no insertion, because arrays don't support object keys. The
> > operation completly failed and so there should be an exception.
>
> No, there should not. If somebody tries to count garbage, I just don't
> want to count it. I don't care about it, it's garbage.


I agree with Dan on this one. Trying to use an invalid type as a key should
produce something. Your argument that its garbage and you don't care may be
valid for a specific use case, but it may also be a bug in another case.
IE: it wasn't supposed to be an object, and the wrong variable was used,
but tracking down that error if nothing is produced when doing something
defined as invalid will be hard. If you don't want to count garbage, then
you should use if()

if (!is_garbage($key)) @$count[$key]++;


>
> > Currently that code fails silently.
>
> And that is exactly what I want it to do. Sometimes silent failure is
> *good*, I don't want to know about every little thing that could go
> wrong, I just want what's right to be done.
> Of course, your intent may be the opposite - but that's exactly the
> point, there's more than one use case.
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Ryan Pallas]

On Fri, Jan 8, 2016 at 10:58 AM, Paul M. Jones <pmjone...@gmail.com> wrote:

>
> > On Jan 8, 2016, at 11:51, Ryan Pallas <derokor...@gmail.com> wrote:
> >
> > I would prefer to see the team picked for the next occurence immediately
> after one happens.
>
> (/me ponders)
>
> That leads to an interesting hypothetical situation: if you know in
> advance that there's a particular team in place, you can (if a malfeasor)
> send bogus reports until a team you like is in place, then send your
> intended report.
>
>
> > Or maybe something like 1 month duty at a time, but team membership may
> last beyond a month, if no conflicts were had during that month. IE, you
> get put on the team, you may "serve" for a year if no conflicts arise. Or
> you may only server for a month, if a conflict does arrive (I think an
> upper bounds when no conflicts may not be required, but should be
> considered if this suggestion is taken to heart at all).
>
> (/me nods)
>
> I think it leads to a similar situation: if you know the team that's in
> place, and you are a malfeasor, you can time your false-accusation to a
> team that is friendly.
>
> Granted, I am paying attention to ways to game the system, but since we
> can be sure it will be gamed, I think it's prudent to do so.
>
> Overall, I still assert that a reporter should not know in advance who
> will handle their report, other than "5 randomly chosen voting members"
> (similar to a jury pool).
>
>
These are good points, and I fully agree - which brings back the idea of a
dispatcher. Someone who receives a request, and press a button that
forwards it to 5 random people (preferably with mixed powers as mentioned
before).

OTOH, I don't really want to ever be randomly selected (but would fulfill
the duties required if selected, as I hope anyone on this list would).

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Ryan Pallas]

On Fri, Jan 8, 2016 at 1:06 PM, Paul M. Jones  wrote:

>
> > On Jan 8, 2016, at 13:50, Larry Garfield  wrote:
> >
> > On 1/8/16 12:31 PM, Paul M. Jones wrote:
> >>> On Jan 8, 2016, at 12:16, Larry Garfield 
> wrote:
> >>>
> >>> On 1/8/16 11:28 AM, Paul M. Jones wrote:
> > On Jan 7, 2016, at 23:52, Larry Garfield 
> wrote:
> >
> > Do you think we can find 5 people in the PHP community that we can
> trust to make fair decisions (NOT that we would always agree with, but that
> are fair) that don't fall too far into "thought policing", in *any*
> direction?  If not, then the community is already lost beyond all hope and
> we should all just give up now.  I do not believe that to be the case, at
> all.
>  Too long spent in a position of power, and even the most fair can
> become unfair.
> 
>  As I have suggested before: *if* there is to be a response team, let
> it be randomly selected on per-reported-incident basis from the pool of
> voters. Then there is no possibility of a charge of continuing bias, and it
> distributes power among the pool, instead of concentrating it into a few
> members.
> 
>  Proponents of the response team: thoughts?
> >>> Randomly selected: Absolutely not.  I wouldn't randomly select someone
> to make Ultimate Decision(tm) on a technical RFC, either. But if a question
> about, say, a parser bug came up there are absolutely certain people that I
> would trust with that question more than others, and defer to their
> analysis/opinion more readily.
> >> Certain people *you* would trust more than others, but that *others*
> would not trust more.
> >>
> >> Also, this is a social/political realm, and not a technical realm;
> would you not trust, say, a randomly-selected jury to hear and decide on a
> case? If not, why not?
> >
> > As many people, including both you and I, have said, we don't want to
> focus on the "jury" aspect.
>
> (/me nods)
>
> If there must be a response team, I would prefer the "mediator" approach,
> as you note.
>
> However, the RFC as I last saw it is not a "mediator" approach, but a
> "judicial" one. If it is to be a "judicial" approach, my suggestion stands.
> If/when the RFC changes to a "mediator" approach, I will change my
> suggestions to fit the modified RFC.
>

Agreed, I think a mediator approach works best.  I also agree with Zeev,
that said mediator(s) should be picked not at random but for their ability
to diffuse a situation. If a situation requires a "judicial" process, then
I think at that point it should be a community decision.

Re: [PHP-DEV] Implementing Generics, and none scalar default properties.

[Ryan Pallas]

Hi Ben and Rasmus,

On Thu, Jan 7, 2016 at 6:24 PM, Ben Scholzen 'DASPRiD' 
wrote:

> By the way, Rasmus updated the RFC quite a bit, you guys may want to take
> a look at it again.
>
>
I just have a couple questions about the rfc, but overall I think its great
and I really hope it makes it into PHP!

Note that the choice of the keyword is to indicate upper bounds is based on
> the rejection of perhaps more obvious alternatives - repurposing the
> extends or implements keywords would be misleading, since they would work
> precisely the same way; worse, permitting both keywords would render
> consumer code invalid if an upper bound type provided by a library is
> refactored between class and interface. Repurposing instanceof would also
> be misleading, since the upper bound is checking the type-hint, not an
> instance.
>

Why not use "as" which is already the keyword used to define aliases?
Probably of the form class foo I think this
feels more natural, as its how we do aliasing with a use statement. Also,
this way it follows the same style as other aliases "RealName as Alias".
I'm not saying is doesn't work, but I wonder if you'd considered as and if
so, why you decided against it.

When autoloading is triggered e.g. by a new statement with a generic type,
> autoloading is triggered as normal, with only the class-name (without type
> parameters) being supplied.
>


In other words, a statement like new Map() will trigger
> auto-loading of class Map.


What order are things autoloaded (or does it even matter)? For example,
given the following - does it matter what order things are autoloaded? It
feels like it would but I'm not sure what would get resolved first:

class Gen {}
class ListGenerator implements HtmlGenerator {}
class FtpWriter extends FileIO {}
new Gen(123, new ListGenerator(), new
FtpWriter());

Again, I'm not sure if it matters but would there be any problems (and this
goes to the whole list, since your RFC says you're not a C coder) with the
order of autoloading with relation to resolving validity of types?

In your second example in the Trait section you have:

> class Box
> {
> use Box;
> }

I think you meant to say "use Container;" as that is the name of your
trait.

Again, really awesome RFC and I hope it can be implemented and accepted!

~Ryan

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Ryan Pallas]

Hi Dan,

On Wed, Jan 6, 2016 at 10:12 AM, Dan Ackroyd  wrote:
>
>
> // If FileException, NetworkException are thrown inside 'foo',
> // they are automatically
> // caught and execution continues to call bar()
> foo() suppress FileException, NetworkException;
> bar();
>
>

> That would allow people to ignore specific exceptions without having a
> huge amount of boilerplate code that makes the actual code illegible.
>

I like this suggestion a lot, it keeps the expected suppressions with the
call that will be suppressing.


> Possibly a more powerful technique would be needed, e.g.being able to
> specific an exception handler on a line by line basis.*
>
>
> // Execute function foo and if any exception is
> // raised, call the callable 'fooCallException'
> foo() raise 'fooRaiseException';
> bar();
>
> public function fooRaiseException(\Throwable $t)
> {
> if ($t instanceof FileException ||
> $t instanceof NetworkException) {
> // This is not an error in this situation, execution can continue.
> return;
> }
>
> // Other exceptions are not acceptable.
> // Propagation of the exception should continue as normal.
> throw $t
> }
>
>
I'm not sure I like this, because of a few things, it puts the suppressed
exceptions in a separate location from the call getting suppressed. Also,
having the function name as a string will make it harder to find in an IDE
since go to definition won't work (and since functions aren't first class
citizens as in javascript, we can't pass a raw name AFAIK) and admittedly
this reasoning doesn't count, IDE makers can update their IDE to have go to
definition work on strings after a raise keyword (however, this will get
complicated if ANY callable works, IE ['class','method'] and
'class::method'). Its basically moving the boilerplate you didn't like into
a function not connected to the call and allows accidental control flow
changes. Think if I do "foo() raises 'fooRaiseException'" everywhere I call
foo, but then in one place I need to suppress FileException and somewhere
else I don't want to. Someone comes along and changes the fooRaiseException
function and now the place where we need to know about FileException we no
longer do. This is caused by 2 things: the "handler" for the exceptions
isn't tied to the location where the exceptions happen, and "Find Usages"
in an IDE will not find strings referencing the function (especially if
built programmatically), again this second one is not valid because we
shouldn't make decisions based on what IDEs support but what's best for the
language. However I think its important to know the number of changes which
will be required in IDEs to make the feature usable for the average
developer (especially if someone from PHPStorm, NetBeans or ZendStudio came
along and said it would be impossible to support a specific new feature in
a usable way).

The benefits of doing it like this are:
>
>  * Any unexpected exceptions are not silenced. This avoids the problem
> of all errors being silenced when the programmer thought only a single
> one would be suppressed.
>
>  * It would allow users to debug their code. Even if an error is
> suppressed by the raise callable for a line of code, it would still be
> userland code that can be stepped through with a debugger, and so you
> can see the exception inside the 'raise' function.
>
>  * It leaves the code in a readable state, which having lots of
> try/catch blocks does not.
>
>  * It allows separate modules to have their own way of handling
> errors, whereas set_error_handler is a per application setting.
>

And what is the benefit of having either of these options being part of the
language (IIUC, this would mean changes to the parser, lexer, compiler and
run time) when it could be implemented in userland?

function tryAndSuppress(callable $func, array $args = [], array $suppress =
[])
{
   try {
   $ret = call_user_func_array($func, $args);
   } catch (Throwable $e) {
   foreach ($suppress as $type) {
  if ($e instanceof $type) {
 return;
  }
   }
   throw $e;
   }
   return $ret;
}

$fh = tryAndSuppress('fopen', ['/path/to/some/file.ext', 'r'],
['FileNotFoundException']);


>
> As I said at the start, I think we need to have more powerful error
> handling in place before deprecating the silence operator. If anyone
> wants to progress this RFC, what I think needs to happen is:
>
> * Work on something like the above 'raise' or 'suppress' exceptions so
> that there is an alternative to the internal warnings.
>
> * Work on a plan on how to migrate all internal errors/warnings to
> individual exceptions. The current way of using set_error_handler to
> convert warnings/errors into generic exceptions isn't good enough.
> People need file operations to raise a more specific 'FileException',
> to allow catching of individual types of error. I don't think it would
> be feasible to just have a massive BC break 

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Ryan Pallas]

On Wed, Jan 6, 2016 at 12:28 PM, Paul M. Jones  wrote:

>
> > On Jan 6, 2016, at 13:13, Andrea Faulds  wrote:
> >
> > Furthermore, if people think the CoC enforcement team have been too
> heavy-handed with their application of the code, the team can be replaced.
>
> Easiest way to avoid that is not to have a continuing team. Instead,
> randomly select of a response group on a per-incident basis should be
> sufficient. Nobody gets selected for a second incident until everyone has
> been selected once.
>

How would I bring to attention of someone a situation, if there is no one
picked to take those requests until after its been made? This goes back to,
if I had a problem because someone is being belligerent, I don't want to
share those belligerent comments publicly, but if there is no one
responsible for that there is no way to do that. OTOH, if we select 5
people and one of them resolve an incident, they could then immediately be
replaced. Similarly, if it requires more than one to handle the situation
whoever is involved may be replaced (including the whole team if need be).
I expect, 99% of complaints will only require a conversation with the
accused and accuser (possibly separately) getting tempers and words calmed
down.


>
> Of course, even better than that is not to have a COC in the first place.
> The conflict-resolution document is an infinitely better starting place.
>

I agree, a conflict resolution document *and team* seems infinitely better.
This team's job is to resolve things quietly and without further incident,
however if action may be required - its an open vote (as previously
suggested).

>
>
> --
> Paul M. Jones
> pmjone...@gmail.com
> 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] [Draft] Adopt Code of Conduct

[Ryan Pallas]

On Jan 5, 2016 7:32 AM, "Peter Lind"  wrote:
>
> >
> > +1. The proposed CoC is too vague for a multi-cultural environment like
> > ours. Reference to ethics, for example, is subjective by nature. But
I'm OK
> > for a more precise text that everybody must explicitely approve before
> > getting any karma.
> >
> > But I am opposed to any form of law enforcement board. I understand it
> > ensures privacy but my feeling is that we don't need privacy here, and
we
> > never needed such a mechanism during 20 years. Most questionable
messages
> > are published on the mailing list. If someone receives an offending
private
> > mail or is victim of harassment in any other way, he can just publish
it on
> > the list and everyone will judge if it is offending or not. Then, if we
> > need to consider banning someone, anybody can create a specific RFC for
> > this, but it is an extreme case that, fortunately, has a very low
> > probability..
> >
>
> A quick question: suppose you're from a minority group, and you've been
the
> target of abuse previously your life. You now join the PHP community and
> for whatever reason, someone takes a dislike to you and starts harassing
> you in private. The abuse makes use of the same stuff you've been through
> before, and because this is a real douchebag, some very humiliating things
> are thrown in for good measure.
>
> How exactly would you feel about having all of this made explicit to all
> the other PHP devs? Presumably you look up to some of these people - would
> your first thought be "Oh I know! I'll post all this nasty stuff to a
> public mailing list, that is archived on the web where EVERYONE can see
all
> the humiliation coming my way - and where google is sure to pick up all
> these things about me!"?
>
> If you happen to belong to a minority group that often is at the receiving
> end of abuse, what would you think if this was the message being sent?
> Would you expect to be understood by your peers, or would their concern
> about being possibly accused of something seem like an out-of-hand
> rejection?
>
> Regards
> Peter
>
I completely agree with Peter on this one. If my only source for recompense
is to post publicly, I'm far more likely to leave the community than post
anything I find harassing publicly.
> --
> 
> WWW: plphp.dk / plind.dk
> CV: careers.stackoverflow.com/peterlind
> LinkedIn: plind
> Twitter: kafe15
> 

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

[Ryan Pallas]

On Fri, Dec 4, 2015 at 11:01 AM, Sebastian Bergmann 
wrote:

> Am 04.12.2015 um 18:53 schrieb Florian Anderiasch:
> > I hate to say it, but not providing an official Windows build is kind of
> > sticking the finger to everyone using Windows for PHP (not the language)
> > development.
>
>  Sorry, but that does not explain the special treatment of Windows.
>  Red Hat provides official PHP binaries for RHEL and Fedora. Ubuntu
>  provides official PHP binaries for Ubuntu. etc. Why should Microsoft
>  not provide the official PHP binaries for Windows?
>
>
Because you're asking PHP to somehow influence Microsoft to change how they
operate. That's simply not something they do or have ever done AFAIK. I
don't know of a single piece of OSS that Microsoft builds and supplies
binaries for, what makes you think they will start doing it just for PHP?
Python, Mozilla, Pidgin, VLC and I'm sure many others provide their own
binaries for Windows, they are not supplied by Microsoft. Why would PHP be
any different?

Re: [PHP-DEV] Re: PHP 7.0.0 final has been released!

[Ryan Pallas]

On Thu, Dec 3, 2015 at 1:59 PM, Jan Ehrhardt  wrote:

> a...@php.net in php.internals (Thu, 3 Dec 2015 21:46:00 +0100):
> >Congratulations everyone to this spectacular day for the PHP world!
> >Grateful thanks to all the contributors and supporters!
>
>
I want to congratulate everyone for this and also to thank everyone
involved for such a great improvement to the language. Everyone in
internals should be proud of what they have achieved, as we the end user
are going to reap great benefits! I and many others are very grateful for
all your hard work!

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Ryan Pallas]

On Tue, Nov 24, 2015 at 8:10 AM, Sebastian Bergmann 
wrote:

>  The following is currently valid PHP 7 code
>
>function a(\int $i) {}
>
>  Is it intentional that the \ in front of the "int" is allowed? IMHO, this
>  confusing notation must not be allowed.
>
>
> Why not? Its a root level type, you can prefix a \ on any other root level
type that's valid for use in type hinting.

function a(\DateTime $d) {}
function b(\SplFileObject $f) {}

Also, this is the only way to get some IDEs to recognize the type when in a
namespace (at least currently).

Re: [PHP-DEV] PHP7 Coalesce operator

[Ryan Pallas]

Well use null coalesce + elvis together then?

// Coalesce possible null values, and use truthy comparison in elvis to
"coalesce" to a default
$var = ($_GET['possible_value'] ?? $_COOKIE['secondary'] ?? false) ?:
DEFAULTS['var'];

On Mon, Nov 23, 2015 at 1:16 PM, shadda  wrote:

> It’s not hate, I happen to like that ?? was added. I’m not raising a
> concern nor asking for a change in its behavior. Rather, I’m asking for
> another, similar operator that’s based on truth-evaluation (with PHP’s
> tender, loving conversion rules baked in), in *addition* to ?? which tests
> for null/undefined exclusively.
>
>
> > On Nov 23, 2015, at 12:08 PM, Phil Sturgeon 
> wrote:
> >
> > On Mon, Nov 23, 2015 at 9:52 AM, shadda  wrote:
> >> Er, that should read, “anything non (null, false, undefined) is true”
> >>
> >>> On Nov 23, 2015, at 11:51 AM, shadda  wrote:
> >>>
> >>> Hey, thanks for responding.
> >>>
> >>> However, I still think that misses the point, or at least the true
> utility of what I’m proposing.
> >>>
> >>> In practice, you can ignore E_NOTICE and php will happily treat null
> and !isset() as the same thing in *most* cases, so that’s not a good
> indicator of truthiness.
> >>>
> >>> Basically in ECMA, anything non-null, false, or undefined is true. PHP
> is very similar in that regard, but our reliance on E_NOTICE to (ahem)
> enforce isset() checks is why, I assume, we’re introducing the ?? operator
> to begin with.
> >>>
> >>> I just think it’d be nice to have a small variation on this feature
> that was less concerned with a (defined|null) semantic and more in keeping
> with PHP’s overall handling of implicit type conversion in expressions.
> >>>
> >>> Does that make more sense?
> >>>
>  On Nov 22, 2015, at 12:41 PM, Andrea Faulds  wrote:
> 
>  Hi,
> 
>  shadda wrote:
> > I had a question-suggestion based around the cool new operator we’re
> getting in PHP7, the ?? operator, which as I understand it is the
> functional equivalent to perl’s // operator; in that they both test for
> whether or not a variable is defined, rather than it’s truthiness.
> 
>  This is not strictly correct. Though something of a misnomer, the
> 'null coalesce operator' checks if a variable doesn't exist, but also that
> it is not null, i.e. it functions like isset().
> 
>  Thanks.
> 
>  --
>  Andrea Faulds
>  http://ajf.me/
> 
>  --
>  PHP Internals - PHP Runtime Development Mailing List
>  To unsubscribe, visit: http://www.php.net/unsub.php
> 
> >>>
> >>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
> > Ignoring E_NOTICE is generally considered bad practice by many, and
> > turning them off just to use ternaries instead of null coalesce (a
> > feature we already have) doesn't seem like a benefit.
> >
> > The ?? is used the same as "a = b || c" in Ruby or JS. Doing that in
> > PHP wouldn't work well as || works a bit differently, so ?? is used
> > instead, just like C and Swift.
> >
> > Basically... it's all good. And even if you hate it you're months too
> > late to raise a concern. :)
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

[Ryan Pallas]

On Thu, Oct 15, 2015 at 1:46 PM, Sara Golemon <poll...@php.net> wrote:

> On Thu, Oct 15, 2015 at 12:16 PM, Ryan Pallas <derokor...@gmail.com>
> wrote:
> > But its an entirely stylistic choice to use trailing commas for cleaner
> > diffs. You could also use leading  commas as well. If you made that a
> coding
> > standard for the organization, you would not have needed to implement
> > trailing am I right?
> >
> > Wouldn't this give the same benefit as trailing commas when it comes to
> > adding removing arguments - a single line diff?
> >
> IMO, that would solve the one small problem in exchange for a new
> small problem.  That of the cognitive overhead of parsing leading
> commas where standard practice calls for trailing commas.
>
> And before you counter than the final optional comma also comes with
> overhead, let me point out that the array consistency argument.  We
> have trailing commas there already, so no new mental overhead.
>
> Wasn't planning on countering, just trying to show that Hack made a
conscious choice to go this way. I personally don't see a benefit, as its
not hard to read a diff that has a new comma on a previous line following
by a new var/value on the next - but if people do then by all means add it
in :)

I do h ave one question I just thought of though... how does the allowance
of trailing comma work with the splat operator (...)? I'm assuming a
function call/definition may only have one or the other, is that correct?

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

[Ryan Pallas]

On Thu, Oct 15, 2015 at 1:32 PM, Pedro Cordeiro 
wrote:

> > Wouldn't this give the same benefit as trailing commas when it comes to
> > adding removing arguments - a single line diff?
>
> It would.
>
> However, I see some merit in someone wanting trailing commas for diffs.
> Leading commas would break away from PSRs and one should not have to choose
> between a standard or clean reading.
>
> If someone chooses to lose their precious time implementing this, it would
> actually give some people a new feature (clean diffs while keeping PSR2
> compliance) without taking anything away from people who oppose this. This
> is not objectively bad, it just adds an option to the pool, which I think
> is good.
>
> I see no reason to allocate resources to make this happen, but if someone
> does allocate their personal time into coding this, I wouldn't oppose a
> merge.
>
> But again, I have no vote.
>
> I want to clarify, I have no objection to this - was just asking if making
the decision that way back then at FB would have merited the same result.
I'm in your boat, whether its added or not does not matter to me.

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

[Ryan Pallas]

On Thu, Oct 15, 2015 at 11:14 AM, Sara Golemon  wrote:

> On Wed, Oct 14, 2015 at 11:59 PM, Björn Larsson
>  wrote:
> > Given the reason against this RFC in the thread it would be interesting
> > to know why HHVM decided to implement it?
> >
>
> Happy to answer, but I need to state a couple things first:
> * I don't really care if this change lands.  I'd kinda like it, but
> it's not solving a massive problem for me.
> * There aren't any compelling reasons against this.  The only reason
> given of any note that I've seen is: "There are no compelling reasons
> in favor of it."  And I'll agree with that.  Like I just said, it's
> not solving any major problems, and it's not going to cause any major
> problems.  It's just a tiny, vanishingly insignificant piece of
> syntactic sugar which disappears before we even get to the AST.
>
> So again, could scarcely care less, so don't expect me to champion
> either side, but you asked "why", so here it is: It makes code reviews
> marginally less ugly.
>
> That's it.  It's a tiny problem to solve, and likely saves less than
> 100ms during diff reviews, but it's a solution to a problem.
>
> Yes, it's a problem which countless developers live with to no
> significant negative consequence.  Solo developers and small shops
> won't care about this since they tend to not bother with code reviews.
> FB has enough engineers working on its very large codebase though,
> that nobody has it all paged in, so code reviews are mandatory, and if
> we can spend five minutes of effort to loosen the parser rules in
> exchange for saving 1/10th of a second on every diff review that
> extends/shrinks a function call/signature with no overhead, then of
> course we would.  That's a fair exchange.
>
> Apologies if you were hoping for a compelling reason.
>
> But its an entirely stylistic choice to use trailing commas for cleaner
diffs. You could also use leading  commas as well. If you made that a
coding standard for the organization, you would not have needed to
implement trailing am I right?

function foo(
   $bar
  ,$baz
  ,$boo
) { ... }

too_many_args(
   $this->id
  ,'some constant string'
  , 123
);

Wouldn't this give the same benefit as trailing commas when it comes to
adding removing arguments - a single line diff?

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Ryan Pallas]

On Wed, Oct 14, 2015 at 4:46 PM, Levi Morrison  wrote:
>
>
> I agree that `void` doesn't make sense given that we document that
> `return;` will return null[1].  If the union types RFC[2] passes it
> makes sense to allow `Foo | null` which allows something of type `Foo`
> or `null`. To me it makes sense that if you then remove `Foo` you are
> left with `null`, not `void`. My personal recommendation because of
> this would be to use `null` for the return type and instead of `void`.
>
> Also, I do not think this feature is pointless. For instance, it has
> value in interfaces. Declaring that a method does not return a value
> means implementors cannot accidentally return something. This is
> better than just documenting that it should not be done.


+1 these are my thoughts exactly. I would be for it if it was null, and
interfaces is exactly why I would be for it.

Re: [PHP-DEV] Regarding contribution

[Ryan Pallas]

On Sun, Oct 11, 2015 at 3:12 PM, er.atul.jindal 
wrote:

> Hello Dear,
>
> I am php programmer, working on LAMP Stack from couple of years. I am
> interested to work for PHP manual and make contributions to manual.
>
> Kindly suggest, how I could be the part of community.
>
> Regards
> Atul Jindal
>

See http://doc.php.net/tutorial/ on how to contribute to PHP documentation
and https://edit.php.net/ for a browser loaded editing suite specific to
php documentation.

Re: [PHP-DEV] Arrow function expressions in PHP

[Ryan Pallas]

On Thu, Oct 1, 2015 at 8:58 AM, Nikita Nefedov  wrote:
>
> I don't think there was a dozen of different ideas, I could only find
> those about `lambda(arg-list; use-list; expression)` and variations of it
> with different keywords and different return-type syntax.
> I do understand that this is quite subjective, but neither this syntax nor
> `fn(arg-list; use-list) expression` look obvious and easily readable to me.
>

It doesn't look obvious because its new syntax. The first time I saw a
for(var; bool; expr) I was totally confused, because I had only seen for
var in range. But you know what? I looked at the docs and then knew how it
worked, not that hard.


> And one thing that makes auto capture much better choice than explicit
> capture (as it've been said a couple of times already) is partial
> application:
>
> $mul = fn($x) => fn($y) => fn($z) => $x * $y * $z;
>
> Looks simpler than:
>
> $mul = fn($x) => fn($y; $x) => fn($z; $x, $y) => $x * $y * $z;
>
>
Yes it looks simpler, but if this is going to continue being the argument
for auto-capturing can we at least get a real world example? I have never
once in the wild seen a lambda that returns a lambda that returns a lambda,
all using variables from the previous lamba(s). I'm fairly certain no one
will invoke the overhead of a function call 3 times just to multiply 3
numbers together. Please give me a valid example if you want me to believe
this to be a valid argument.

There is no way in php that I know of to get access to a parent's scope,
unless explicitly used which is only available on lambda/closures.
Therefore, automatic closing of the variables is very much against the
scoping rules of the language. It is totally unexpected for someone who has
been using the language for many years.

Re: [PHP-DEV] [RFC] [DISCUSSION]: Closure from callable

[Ryan Pallas]

On Tue, Sep 29, 2015 at 8:23 AM, Dan Ackroyd  wrote:

> Hello internals,
>
> I'd like to start a discussion of a proposal to allow closures to be
> created in user-land without having to use a whole lot of reflection
> code.
>
> https://wiki.php.net/rfc/closurefromcallable
>
> Thanks to Joe and Bob for the assistance in the patch.
>
> +1 I like this a lot

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Ryan Pallas]

On Wed, Sep 23, 2015 at 12:27 PM, Rowan Collins 
wrote:
>
>
> My suggestion (with which I believe Stig was agreeing) is this:
>
> variable_exists('foo'): yes (should be yes)
> unset($foo);
> variable_exists('foo'): no (should be no)
> variable_exists('bar'): no (should be no)
>
> I dislike this because it makes refactoring harder. Just like when we
rename a dynamic property, we have to search for its usage as a string
(which may be stored in a variable), and then analyze if those strings
warrant being changed. Of course, strings in a variable may also be created
dynamically, so simply searching for the name of a property being renamed
may not find you all its usages.

This feels like exactly the type of thing you were trying to avoid when you
suggested hasitem() since you pass it a compound variable expression
($var->prop, $var['key']) which makes refactoring easier.

I would prefer seeing both take actual expressions, much like isset and
empty. Basically, if variable_exists recurses then its an error and if
hasitem doesn't recurse its an error.

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Ryan Pallas]

On Sat, Sep 19, 2015 at 5:29 PM, Lester Caine  wrote:

> On 19/09/15 22:56, Rowan Collins wrote:
> >>> If what you want to do is avoid the notice, then you don't need to
> >>> "find out before calling is_null", you need to call isset *instead
> >>> of* is_null. Again, ignore the name, and concentrate on what it
> >>> actually does.
> >> BUT ISSET RETURNS FALSE FOR A VARIABLE THAT IS SET BUT NULL ... END OF
> >> STORY ...
> >
> > AND SO DOES IS_NULL
> >
> > The notices emitted by is_null are COMPLETELY IRRELEVANT.
>
> ? is_null returns true if the variable exists and is NULL and throws a
> notice if the variable is not set WHY is that fact COMPLETELY
> IRRELEVANT? Just because you don't think people should be coding in the
> way that it causes problems with existing code does not make it
> irrelevant we have to put up with the notices because there is no CLEAN
> way to establish that a variable exists only that it is set.
>

I would also point out that is_null returns true (after the engine produces
a notice) for undefined variables:

$ php -r "var_dump(is_null($a));"

Notice: Undefined variable: a in Command line code on line 1

Call Stack:
 0.0001 111. {main{() Command line code:0

*bool(true)*

So is_null does not help to determine if a plain variable is in fact null.

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Ryan Pallas]

On Fri, Sep 18, 2015 at 9:35 AM, Rowan Collins 
wrote:

>
>
> If what you want to write is "if ( ! exists($foo) || is_null($foo) ) { ...
> }" then that is exactly what "if ( isset($foo) )" will give you, without
> any notices whatsoever.

Conversely, if what you want to write is "if ( exists($foo) &&
is_null($foo) ) { ... }"  then there is no way to do that currently.

I personally agree with you Rowan, that this feels like an unnecessary
addition to the language. On the other hand, I see no reason it shouldn't
exist if its a feature users want, especially considering its impossible to
implement in userland.

Re: [PHP-DEV] Let's discuss enums!

[Ryan Pallas]

I few questions wrt the rfc: https://wiki.php.net/rfc/enum

> An enum value is only equal to itself.
I'm not sure I agree. How then do I store the enum into a DB and compare it
after reading?
switch($db->query('select role from user where user_id = 123')->fetch()[0])
{
  case UserRole::Admin:
  include 'admin.php';
  break;
  case UserRole::User;
  include 'user.php';
  break;
  default:
  include 'login.php';
  break;
}
Would this not ALWAYS include login if UserRole is an enum (instead of a
final class with constants as I use now, which a switch like this will work
for)?  Is this only possible with the magic value method? In which case I'd
have to check the value method, something like case
UserRole::Admin->ordinal() (or name, or value or whatever)?

>  This means that if the name enum is used for a property, function,
method, class, trait or interface there will now be a parse error instead.
Surely, a property can be named enum, since it can be named other reserved
words, for example?
$ php

  string(6) "callMe"
  'trait' =>
  string(5) "useMe"
  'class' =>
  string(13) "instantiateMe"
}


Also, I really like the idea of being able to type hint the enum in the
switch(UserRole) that was mentioned. Not sure I like the idea of an
implicit throw though, consider the UserRole above, I might have 10
different roles, but the current switch is only valid for 5 of those roles.
In this situation, if I add a default: return Auth::NotAuthorized; will
that supress the implicit fall throw? If so, how often will the implicit
throw really be hit? I know we have standards that all case statements must
have default statements, to make sure every case is handled, whether we
foresaw it or not.

Re: [PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE

[Ryan Pallas]

On Mon, Sep 14, 2015 at 3:22 PM, Daniel Persson 
wrote:

> Hi.
>
> I've not been a member for too long so I might have missed if this have
> been discussed earlier.
>
> But I've created a small PR to the basic request handling to support PUT,
> PATCH and DELETE.
>
> https://github.com/php/php-src/pull/1519
>
> Summary:
>
> Added support for request methods with the smallest change possible.
> History:
>
> HTTP 1.0 had only support for GET, POST and HEAD.
> In June of 1999 HTTP 1.1 added the verbs PUT and DELETE and later in 2010
> RFC5789 (https://tools.ietf.org/html/rfc5789) added PATCH.
> Pull request explaination:
>
> In this pull request I try to add put, patch and delete with changing as
> few functions as possible. I simply handle the new verbs as POST. As
> defined in HTTP 1.1 they are similar in input data requirements and differ
> only in usage.
>

+1 from me, would love to see the verbs supported more fully. (though my
approval means quite literally nothing). How does this affect something
like the ini settings for variable order? IE. does GPC change from GET ->
POST -> COOKIE to GET -> PARSED_INPUT -> COOKIE? Since only a single verb
is available for any single request, this makes the most sense for me.


>
> More work I could do is add new globals for $_PUT, $_PATCH and $_DELETE but
> I think this might be more confusing. Or we could move from $_POST to a new
> global not tied to a verb. Example $_PARSED_INPUT


As for having a new $_PARSED_INPUT, I'm not sure I like this for 2 reasons
a) the name is 2 words, all other super globals are single words (unless
there's one I do not know of) and b) It feels like too long a name, sure in
an IDE it will auto-complete for us, but for quick edits in vim for
example, this name would suck. But my only problem with it is on a name
level, about about just $_INPUT or does this seem to conflict with
$_REQUEST which holds multiple super globals worth of data already.

Re: [PHP-DEV] Re: [RFC] [Concept] Class Constant visibility modifiers in PHP 7.1+

[Ryan Pallas]

On Mon, Sep 7, 2015 at 6:24 AM, Ryan Pallas <derokor...@gmail.com> wrote:

>
>
> On Mon, Sep 7, 2015 at 1:02 AM, Stanislav Malyshev <smalys...@gmail.com>
> wrote:
>
>> Hi!
>>
>> > Funny you should propose this now, I was wanting this feature just the
>> > other day. This would be a useful addition, and clean up a strange
>> > inconsistency: why can methods and properties have visibility modifiers,
>> > but not constants?
>>
>> Private and protected methods and properties are private for a reason -
>> they may be radically changed or gone when the code is changing, and
>> thus external code should not rely on them, and the way to ensure it is
>> to deny that code access to them. However, I have hard time seeing how
>> that would apply to constants - they shouldn't really change, and if
>> they do, they either shouldn't be constant, or something in your world
>> changed fundamentally (i.e. scientists discovered that PI actually
>> equals to 4). I wonder if you find in your code constant that you need
>> to hide because you foresee it changing - should it really be a constant
>> at all?
>>
>
>
> For me a common use case is DB abstraction. I have an abstract base class
> that implements a bunch of functionality based on protected static members,
> which are to be set in the implementing class. Now these properties are
> constant for the implementing class (table name, column definition, etc)
>  but I have to put them in a static member to prevent outside access. So
> now I have the problem, where if someone else maintains my code they see a
> static member in the class they may think its acceptable to change it in
> some function at run time, meanwhile if they were constants it would be
> very obvious that they should not be changed. The reason they are in static
> members is A) to provide visibility modifiers and B) to share a single
> value across all instances, however given that C) they are constant through
> meaning and usage, the should instead be protected consts. For an example
> of a base class of this type, you can look at my framework's version (NOTE:
> I'm not advocating my framework, its kinda crap but it works well for my
> purposes) http://bit.ly/1EN59Ty (class) http://bit.ly/1NdkGgL (docs)
>
Looks like I changed to constants because someone did write a function that
modified the value of TABLE_NAME in a project I was working on. So now the
internals of the models are available everywhere (sad).


> I fully support this idea, and would be glad to provide any help I can
> (though that probably just means writing tests since I don't know C)
>

Re: [PHP-DEV] Re: [RFC] [Concept] Class Constant visibility modifiers in PHP 7.1+

[Ryan Pallas]

On Mon, Sep 7, 2015 at 1:02 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > Funny you should propose this now, I was wanting this feature just the
> > other day. This would be a useful addition, and clean up a strange
> > inconsistency: why can methods and properties have visibility modifiers,
> > but not constants?
>
> Private and protected methods and properties are private for a reason -
> they may be radically changed or gone when the code is changing, and
> thus external code should not rely on them, and the way to ensure it is
> to deny that code access to them. However, I have hard time seeing how
> that would apply to constants - they shouldn't really change, and if
> they do, they either shouldn't be constant, or something in your world
> changed fundamentally (i.e. scientists discovered that PI actually
> equals to 4). I wonder if you find in your code constant that you need
> to hide because you foresee it changing - should it really be a constant
> at all?
>


For me a common use case is DB abstraction. I have an abstract base class
that implements a bunch of functionality based on protected static members,
which are to be set in the implementing class. Now these properties are
constant for the implementing class (table name, column definition, etc)
 but I have to put them in a static member to prevent outside access. So
now I have the problem, where if someone else maintains my code they see a
static member in the class they may think its acceptable to change it in
some function at run time, meanwhile if they were constants it would be
very obvious that they should not be changed. The reason they are in static
members is A) to provide visibility modifiers and B) to share a single
value across all instances, however given that C) they are constant through
meaning and usage, the should instead be protected consts. For an example
of a base class of this type, you can look at my framework's version (NOTE:
I'm not advocating my framework, its kinda crap but it works well for my
purposes) http://bit.ly/1EN59Ty (class) http://bit.ly/1NdkGgL (docs)

I fully support this idea, and would be glad to provide any help I can
(though that probably just means writing tests since I don't know C)

Re: [PHP-DEV] Re: [RFC] [Concept] Class Constant visibility modifiersin PHP 7.1+

[Ryan Pallas]

On Mon, Sep 7, 2015 at 7:11 PM, Xinchen Hui  wrote:

>
>
> Sent from my iPhone
>
> > On Sep 8, 2015, at 02:09, Andrea Faulds  wrote:
> >
> > Hi Stas,
> >
> > Stanislav Malyshev wrote:
> >>
> >> Private and protected methods and properties are private for a reason -
> >> they may be radically changed or gone when the code is changing, and
> >> thus external code should not rely on them, and the way to ensure it is
> >> to deny that code access to them. However, I have hard time seeing how
> >> that would apply to constants - they shouldn't really change,
> >
> > Why not? A constant's value doesn't change at runtime, but nothing stops
> you changing the value in a new version. A real-world example for you:
> phpng changed the values of the IS_* constants in the Zend Engine.
> >
> >> and if
> >> they do, they either shouldn't be constant, or something in your world
> >> changed fundamentally (i.e. scientists discovered that PI actually
> >> equals to 4).
> >
> > Constants in code aren't necessarily natural constants.
> >
> > I wonder if you find in your code constant that you need
> >> to hide because you foresee it changing - should it really be a constant
> >> at all?
> >
> > If I have a value specified in the source code which will not change at
> runtime, and which I don't want to expose as part of my public API... what
> exactly do you propose it should be? I don't see why a constant isn't
> fitting.
> >
> public static final as Java does
>
>
https://3v4l.org/KX5jQ
> PHP Fatal error:  Cannot declare property Foo::$Bar final, the final
modifier is allowed only for methods and classes in - on line 4

So there is no way to create an immutable property with a visibility
modifier, unless you're suggesting that's what the RFC should be instead.

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Ryan Pallas]

On Wed, Aug 26, 2015 at 11:08 AM, Craig Francis cr...@craigfrancis.co.uk
wrote:

 On 26 Aug 2015, at 16:44, Stanislav Malyshev smalys...@gmail.com wrote:

  Depending on the website I may then add a key to define the
  'report-uri', or I may set it to NULL to say that I don't want one.
 
  NULL is not the best value to for this, but the function you're looking
  for is array_key_exists().



 What would be the best value?

 And the array_key_exists() function has already been mentioned (and is
 what I'm using... but I cut that bit out to keep the reply shorter, as
 mentioned in my previous email).


What I would do is use false to me I don't want this, and null/not set to
mean do the default, and a value to mean this is what I want. Then you end
up with:

if (!isset($val)) {
   // do the default
} elseif (!empty($val)) {
   // do something with $val
}
// else do nothing because I don't want this thing

On the other hand, if I'm designing something using null as a special case
value, then I would just use array_key_exists and is_null (these calls
exist a few times in my code) but generally speaking I try not to give null
special meaning.

Re: [PHP-DEV] set_exception_handler catches all Throwables

[Ryan Pallas]

On Aug 19, 2015 6:44 AM, Björn Larsson bjorn.x.lars...@telia.com wrote:

 Plan to migrate to PHP 7 later, like the new Exception/Error way
 of working very much. Point is that current set_exception_handler
 only address exceptions, not errors. You are right that on that the
 surface it's the same callback, but could eg be logging in different
 ways and to different recipients. Will look into it more later.

 Regards, //Björn


 Den 2015-08-19 kl. 13:30, skrev Niklas Keller:

 What do you guys do in the set_exception_handler callback? Wouldn't most
code just use the same callback and just log the error / exception?

 Regards, Niklas

 2015-08-19 11:55 GMT+02:00 Björn Larsson bjorn.x.lars...@telia.com
mailto:bjorn.x.lars...@telia.com:


 Den 2015-08-19 kl. 10:52, skrev Peter Cowburn:

 On 17 August 2015 at 15:24, Sebastian Bergmann
 sebast...@php.net wrote:

 Am 17.08.2015 um 16:00 schrieb Derick Rethans:

 Actually, I don't call this intended. This is just as
 much as a BC break
 as the original implementation where Errors where also
 Exceptions. IMO,
 set_exception_handler() should be changed - with my
 preference it not
 capturing Error, and instead have an additional
 set_throwable_handler().

   +1

I agree with this completely. I think the point here is that
catch(Exception $e) remains unchanged while setting a handler actually
catches more things now. Tbh I feel like this is an oversight in
implementing the Error/Throwable rfc and should be addressed now, otherwise
it can't be changed until 8 if I understand correctly.

Re: [PHP-DEV] json_decode/encode should return full precision values by default

[Ryan Pallas]

On Wed, Jul 29, 2015 at 5:25 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi all,

 On Thu, Jul 30, 2015 at 7:44 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

  On Thu, Jul 30, 2015 at 1:13 AM, Nikita Popov nikita@gmail.com
  wrote:
 
  Instead of continuing to use serialize_precision, which will produce
  unnecessarily long outputs for many values, why don't we just switch to
  using the 0 mode of zend_dtoa, i.e. to return the shortest output that
 is
  still accurate if interpreted in round-to-nearest. I think this is what
  everybody else is using when they convert floating point numbers to
  strings. I guess we may not be able to change normal floating point
  printing to use this, but this seems like the best mode for anything
 using
  serialize_precision now and everything that should be using it (like
 JSON,
  and queries, etc).
 
 
  I prefer your proposal!
  Your proposal is a lot better than now.
  Anyone has opinion for this?
 
  I'm writing the RFC and I would like to make this the first option. i.e.
  serialize_precision=0 uses zend_dtoa 0 mode for all data exchange
  functions (json/serialize/var_exrport. Anyone care about WDDX/XML_RPC?)
 

 I wrote draft RFC.

 https://wiki.php.net/rfc/precise_float_value

 Please comment. I would like to start RFC discussion shortly.
 Thank you.


My thought would be why not -1 to make it obvious it has special meaning?
When I see precision=0 I tend to think that means my numbers will be
returned as ints no matter what (there is zero fractional precision)
whereas this takes a valid value for precision and gives it special
meaning. I fully support your end game, but giving a valid value a special
meaning I do not like.



 --
 Yasuo Ohgaki
 yohg...@ohgaki.net