Re: [PHP-DEV] Add interface implementation to class in separate file

[Mike Schinkel]

> On Sep 13, 2020, at 3:49 PM, Olle Härstedt  wrote:
> 
> 2020-09-13 17:58 GMT, Benjamin Eberlei  >:
>> On Sat, Sep 12, 2020 at 10:23 PM Olle Härstedt 
>> wrote:
>> 
>>> Hi internals!
>>> 
>>> Separation of data and behaviour is both a fun and hard discussion,
>>> especially considering:
>>> 
>>> * "It should be possible to add new features without touching old code";
>>> and
>>> * "Principle of Least Privilege" (never expose more than you have to)
>>> (https://en.wikipedia.org/wiki/Principle_of_least_privilege).
>>> 
>>> There should (could) be a way to add new behaviour to old data without
>>> touching the old data (class). Traits won't work in this use-case,
>>> since they assume the same internal structure for all trait-using
>>> classes. Imagine the `stringable` interface and a `toString` trait. A
>>> __toString() method needs knowledge about the internal structure of a
>>> class Foo. Yet if we want to keep adding behaviour to Foo, we'll end
>>> up with either exposing too much of Foo, or expanding the class file
>>> indefinitely. Please note that composition is not a proper solution,
>>> since it requires exposure of Foo; composition leads to lack of proper
>>> encapsulation, or representation exposure.
>>> 
>>> In Haskell it's possible to split instance implementation of
>>> type-classes into separate files. In Rust you can have a struct with
>>> private fields and put impl of behaviour in different files (but same
>>> crate).
>>> 
>>> A similar feature in PHP could look like (using new keyword `expand`
>>> but could be anything, or even `extend` in new context):
>>> 
>>> ```
>>> // File FooStringable.php
>>> expand Foo implements stringable {
>>>  public function __toString() {
>>>// Full access to Foo's all private fields here.
>>>// Assumes you can autoload Foo.
>>>// Assumes usage of $foo->__toString(); will be configured with
>>> autoload to dynamically find the correct behaviour of Foo.
>>>  }
>>> }
>>> ```
>>> 
>>> If you'd use composition instead, you'd maybe have a formatter class
>>> with a method `$formatter->toString(stringable $foo)`. This has the
>>> problem I mentioned with exposing too much of $foo; it breaks
>>> encapsulation. It has the benefit of being able to provide multiple
>>> toString methods with different formats, but would have to assume
>>> similar structure of the objects passed to it (defined with an
>>> interface), which is not always possible or desirable.
>>> 
>>> The other way is inheritance, which doesn't scale over multiple
>>> behaviours. `FooWithStringable extends Foo`? No.
>>> 
>>> Was I clear here? Do you understand the issues that this design
>>> pattern is trying to solve? Its purpose is to solve "keep adding new
>>> feature to old data" in a clean and proper way, while keeping
>>> information encapsulation.
>>> 
>> 
>> Do I understand you correctly, it would be somewhat like "opening" up a
>> class and making changes to it in another file?
>> 
>> Certainly a powerful concept, but I would be very interested in the details
>> how that would interact with autoloading. If I have a class Foo loaded, and
>> its "extension" FooString with toString method not, then it would lead to
>> the "toString" code missing.
> 
> Yes, a little like opening up, *but* with clear restrictions. It was
> explained to me that this won't work without either:
> 
> 1) A module system to define which files are part of a class
> 2) Manually write in the "main" class file which other extensions to
> this class should be loaded.
> 
> The reason is again encapsulation - it should not be possible for any
> file to just get access to private fields by adding a new interface
> implementation.
> 
> Option (2) can be achieved if we allow "include ;" in PHP
> *inside* a class definition. Again note that this is different from a
> trait, since it gives access to private properties that are
> *different* between the classes using it, like toString() or
> toQuery().
> 
> Option (2) does not need configured autoloading. Option (1) is more
> elaborate, maybe composer.json would need to configure something, *or*
> it is assumed that a class is defined in a single folder instead of a
> single file. Which already is kind of like a module system.

Doesn't option 2 fail the very first criteria you argued for in your initial 
email?  Doesn't it fail the criteria "It should be possible to add new features 
without touching old code?" 

IOW, we should not have to modify any source code in Symfony to be able to 
expand one of its classes, for example. If modifying the original source is 
required, you really don't need a new syntax, just modify the class and add 
your toString method.

(BTW, your first criteria sounds like it would be enabling the Open/closed 
principle of S.O.L.I.D. for PHP classes.)

Also, I expect requiring a module system would eliminate this idea from even 
being considered given past discussions of "modules."

So, back to what Benjamin implied, f

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Andreas Hennings]

On Wed, 16 Sep 2020 at 04:00, Josh Bruce  wrote:

>
> > * If PHP had either convention or special handling for _ or $_ as a
> “ignore this” destination, I wouldn’t have made the proposal.  However, it
> doesn’t; _ can (apparently!) be a constant, and is also a function, and $_
> has no special handling (and I bet it’s actually used to contain values
> that are used in at least one application).
>
> Saw this today and the list() each() made me think of this thread:
> https://www.dyn-web.com/php/arrays/iterate/
>
> With you on void for same reason and what if the double-arrow was all that
> was needed, like the empty + comma in the link:
>
> foreach ($arr as $key =>)
>

I like this!
Once you get over the perception that something is missing, it is
quite obvious what is going on.

Otherwise, I prefer "foreach ($arr as $key => void)" over "foreach ($arr as
$key => null)".
With "=> null" one might think this is a fancy alternative to
array_filter(). "void" is more explicitly "not a value".

The array_keys() does not work for iterators.

And even on arrays it can be a waste if we are only interested in the first
few keys.
Optimization could mitigate this.
But I would imagine that most people would look at the code and say "that
looks wasteful", because the optimization is not visible or obvious.

If this does not get added to the language, I can live with "=> $_".
PhpStorm already has an option to ignore unused value in foreach(), if a
key exists.
It is not based on the variable name, but this could be added if people ask
for it.

-- Andreas



>
> Cheers,
> Josh

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Josh Bruce]

> * If PHP had either convention or special handling for _ or $_ as a “ignore 
> this” destination, I wouldn’t have made the proposal.  However, it doesn’t; _ 
> can (apparently!) be a constant, and is also a function, and $_ has no 
> special handling (and I bet it’s actually used to contain values that are 
> used in at least one application).

Saw this today and the list() each() made me think of this thread: 
https://www.dyn-web.com/php/arrays/iterate/

With you on void for same reason and what if the double-arrow was all that was 
needed, like the empty + comma in the link:

foreach ($arr as $key =>)

Cheers,
Josh

Re: [PHP-DEV] Compiler Optimizations

[Chase Peeler]

On Tue, Sep 15, 2020 at 9:51 AM Benas IML  wrote:

> Ah, sorry! Misread your post. Anyways, the compiler doesn't transform
> `\array_keys()` yet, so there's no optimization for that.
>
> As for other compiler optimizations, 2 that I know that the compiler does
> is:
>
> 1. Binary OP evaluation i. e. `2 * 2` does not yield `ZEND_ADD` opcode but
> is instead computed by the compiler directly.
>
> 2. There are special functions that have their own opcodes. You can learn
> more about those here:
>
> https://phpinternals.net/articles/optimising_internal_functions_via_new_opcode_instructions
>

That's a good starting point, thanks.




>
> Best regards,
> Benas
>
> On Tue, Sep 15, 2020, 4:44 PM Chase Peeler  wrote:
>
>> I wasn't proposing that my example be supported. I'm totally okay with
>> the fact that it doesn't. My question was about whether or not those kinds
>> of optimizations are documented anywhere so that developers can make sure
>> they don't miss out on them by not fitting the proper pattern.
>>
>> On Tue, Sep 15, 2020 at 9:40 AM Benas IML 
>> wrote:
>>
>>> Hey,
>>>
>>> During my free time, I'm implementing that specific `array_keys`
>>> optimization. I'm not planning on supporting cases like yours (i. e.
>>> indirection through a variable) since there's no point in doing that. And
>>> also, it's not feasible to support every use case. Should we also support
>>> cases like this?
>>>
>>> ```php
>>> $a = 'array_keys';
>>> $b = $a(...);
>>> $c = 'b';
>>>
>>> foreach ($$c as $key) {
>>> ...
>>> }
>>> ```
>>>
>>> Obviously not. `\array_keys` optimization will work the same way as an
>>> optimized `strlen` function works.
>>>
>>> That means that the optimization is only going to be applied if the
>>> `array_keys` function is used directly in the `foreach` loop and only if a)
>>> either the namespace is global b) or `\array_keys(...)`/`use function
>>> array_keys` is used.
>>>
>>>
>>> Best regards,
>>> Benas
>>>
>>> On Tue, Sep 15, 2020, 4:23 PM Chase Peeler 
>>> wrote:
>>>
 I brought this up on another thread, but it wasn't addressed (which is
 fine, since it was somewhat off-topic). I thought it might be
 worth bringing up in its own thread, though.

 In the other thread, someone had mentioned the following compiler
 optimization

 foreach(\array_keys($arr) as $key) {

 and quietly transform that into:

 foreach ($arr as $key =>
 $_unusedVariableNameThatIsntEvenSpilledToTheScope)
 {

 I would be more likely to write:
   $keys = array_keys($arr);
   foreach($keys as $key){
 Which would prevent me from being able to take advantage of the
 optimization.

 So, what I was wondering, is if there are other optimizations I might be
 missing out on, and if so, are they documented anywhere?


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

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

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

Re: [PHP-DEV] Compiler Optimizations

[Benas IML]

Ah, sorry! Misread your post. Anyways, the compiler doesn't transform
`\array_keys()` yet, so there's no optimization for that.

As for other compiler optimizations, 2 that I know that the compiler does
is:

1. Binary OP evaluation i. e. `2 * 2` does not yield `ZEND_ADD` opcode but
is instead computed by the compiler directly.

2. There are special functions that have their own opcodes. You can learn
more about those here:
https://phpinternals.net/articles/optimising_internal_functions_via_new_opcode_instructions

Best regards,
Benas

On Tue, Sep 15, 2020, 4:44 PM Chase Peeler  wrote:

> I wasn't proposing that my example be supported. I'm totally okay with the
> fact that it doesn't. My question was about whether or not those kinds of
> optimizations are documented anywhere so that developers can make sure they
> don't miss out on them by not fitting the proper pattern.
>
> On Tue, Sep 15, 2020 at 9:40 AM Benas IML 
> wrote:
>
>> Hey,
>>
>> During my free time, I'm implementing that specific `array_keys`
>> optimization. I'm not planning on supporting cases like yours (i. e.
>> indirection through a variable) since there's no point in doing that. And
>> also, it's not feasible to support every use case. Should we also support
>> cases like this?
>>
>> ```php
>> $a = 'array_keys';
>> $b = $a(...);
>> $c = 'b';
>>
>> foreach ($$c as $key) {
>> ...
>> }
>> ```
>>
>> Obviously not. `\array_keys` optimization will work the same way as an
>> optimized `strlen` function works.
>>
>> That means that the optimization is only going to be applied if the
>> `array_keys` function is used directly in the `foreach` loop and only if a)
>> either the namespace is global b) or `\array_keys(...)`/`use function
>> array_keys` is used.
>>
>>
>> Best regards,
>> Benas
>>
>> On Tue, Sep 15, 2020, 4:23 PM Chase Peeler  wrote:
>>
>>> I brought this up on another thread, but it wasn't addressed (which is
>>> fine, since it was somewhat off-topic). I thought it might be
>>> worth bringing up in its own thread, though.
>>>
>>> In the other thread, someone had mentioned the following compiler
>>> optimization
>>>
>>> foreach(\array_keys($arr) as $key) {
>>>
>>> and quietly transform that into:
>>>
>>> foreach ($arr as $key =>
>>> $_unusedVariableNameThatIsntEvenSpilledToTheScope)
>>> {
>>>
>>> I would be more likely to write:
>>>   $keys = array_keys($arr);
>>>   foreach($keys as $key){
>>> Which would prevent me from being able to take advantage of the
>>> optimization.
>>>
>>> So, what I was wondering, is if there are other optimizations I might be
>>> missing out on, and if so, are they documented anywhere?
>>>
>>>
>>> --
>>> Chase Peeler
>>> chasepee...@gmail.com
>>>
>>
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

Re: [PHP-DEV] Compiler Optimizations

[Chase Peeler]

I wasn't proposing that my example be supported. I'm totally okay with the
fact that it doesn't. My question was about whether or not those kinds of
optimizations are documented anywhere so that developers can make sure they
don't miss out on them by not fitting the proper pattern.

On Tue, Sep 15, 2020 at 9:40 AM Benas IML  wrote:

> Hey,
>
> During my free time, I'm implementing that specific `array_keys`
> optimization. I'm not planning on supporting cases like yours (i. e.
> indirection through a variable) since there's no point in doing that. And
> also, it's not feasible to support every use case. Should we also support
> cases like this?
>
> ```php
> $a = 'array_keys';
> $b = $a(...);
> $c = 'b';
>
> foreach ($$c as $key) {
> ...
> }
> ```
>
> Obviously not. `\array_keys` optimization will work the same way as an
> optimized `strlen` function works.
>
> That means that the optimization is only going to be applied if the
> `array_keys` function is used directly in the `foreach` loop and only if a)
> either the namespace is global b) or `\array_keys(...)`/`use function
> array_keys` is used.
>
>
> Best regards,
> Benas
>
> On Tue, Sep 15, 2020, 4:23 PM Chase Peeler  wrote:
>
>> I brought this up on another thread, but it wasn't addressed (which is
>> fine, since it was somewhat off-topic). I thought it might be
>> worth bringing up in its own thread, though.
>>
>> In the other thread, someone had mentioned the following compiler
>> optimization
>>
>> foreach(\array_keys($arr) as $key) {
>>
>> and quietly transform that into:
>>
>> foreach ($arr as $key =>
>> $_unusedVariableNameThatIsntEvenSpilledToTheScope)
>> {
>>
>> I would be more likely to write:
>>   $keys = array_keys($arr);
>>   foreach($keys as $key){
>> Which would prevent me from being able to take advantage of the
>> optimization.
>>
>> So, what I was wondering, is if there are other optimizations I might be
>> missing out on, and if so, are they documented anywhere?
>>
>>
>> --
>> Chase Peeler
>> chasepee...@gmail.com
>>
>

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

Re: [PHP-DEV] Compiler Optimizations

[Benas IML]

Hey,

During my free time, I'm implementing that specific `array_keys`
optimization. I'm not planning on supporting cases like yours (i. e.
indirection through a variable) since there's no point in doing that. And
also, it's not feasible to support every use case. Should we also support
cases like this?

```php
$a = 'array_keys';
$b = $a(...);
$c = 'b';

foreach ($$c as $key) {
...
}
```

Obviously not. `\array_keys` optimization will work the same way as an
optimized `strlen` function works.

That means that the optimization is only going to be applied if the
`array_keys` function is used directly in the `foreach` loop and only if a)
either the namespace is global b) or `\array_keys(...)`/`use function
array_keys` is used.


Best regards,
Benas

On Tue, Sep 15, 2020, 4:23 PM Chase Peeler  wrote:

> I brought this up on another thread, but it wasn't addressed (which is
> fine, since it was somewhat off-topic). I thought it might be
> worth bringing up in its own thread, though.
>
> In the other thread, someone had mentioned the following compiler
> optimization
>
> foreach(\array_keys($arr) as $key) {
>
> and quietly transform that into:
>
> foreach ($arr as $key => $_unusedVariableNameThatIsntEvenSpilledToTheScope)
> {
>
> I would be more likely to write:
>   $keys = array_keys($arr);
>   foreach($keys as $key){
> Which would prevent me from being able to take advantage of the
> optimization.
>
> So, what I was wondering, is if there are other optimizations I might be
> missing out on, and if so, are they documented anywhere?
>
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

[PHP-DEV] Compiler Optimizations

[Chase Peeler]

I brought this up on another thread, but it wasn't addressed (which is
fine, since it was somewhat off-topic). I thought it might be
worth bringing up in its own thread, though.

In the other thread, someone had mentioned the following compiler
optimization

foreach(\array_keys($arr) as $key) {

and quietly transform that into:

foreach ($arr as $key => $_unusedVariableNameThatIsntEvenSpilledToTheScope)
{

I would be more likely to write:
  $keys = array_keys($arr);
  foreach($keys as $key){
Which would prevent me from being able to take advantage of the
optimization.

So, what I was wondering, is if there are other optimizations I might be
missing out on, and if so, are they documented anywhere?


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

Re: [PHP-DEV] PHP 8.0 branch cut

[Christoph M. Becker]

On 15.09.2020 at 09:29, Sebastian Bergmann wrote:

> Am 15.09.2020 um 09:24 schrieb Benjamin Eberlei:
>> The options to talk about and use in docs/posts are the following:
>>
>> opcache.jit=yes|true|1
>> opcache.jit=tracing
>> opcache.jit=function
>>
>> These differentiate the Tracing-JIT from the Function-JIT. Default is
>> tracing.
>
> Thanks!

See also .

--
Christoph M. Becker

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

Re: [PHP-DEV] PHP 8.0 branch cut

[Sebastian Bergmann]

Am 15.09.2020 um 09:24 schrieb Benjamin Eberlei:

The options to talk about and use in docs/posts are the following:

opcache.jit=yes|true|1
opcache.jit=tracing
opcache.jit=function

These differentiate the Tracing-JIT from the Function-JIT. Default is
tracing.


Thanks!

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

Re: [PHP-DEV] PHP 8.0 branch cut

[Benjamin Eberlei]

On Tue, Sep 15, 2020 at 8:20 AM Brent Roose  wrote:

> Hey Dmitiry
>
> Speaking of the JIT. I remember berblei mentioning that the JIT
> configuration options were going to change prior to the final 8 release (
> https://www.reddit.com/r/PHP/comments/hjxlh9/jit_benchmarks_on_reallife_web_applications/fwuje8g/
> <
> https://www.reddit.com/r/PHP/comments/hjxlh9/jit_benchmarks_on_reallife_web_applications/fwuje8g/>).
> In other words: not one value with several integer flags, but dedicated
> options for every configuration entry. Is this still on the roadmap?
>

 Hi Brent, Hi Sebastian,

this is already done by this PR https://github.com/php/php-src/pull/5913

The options to talk about and use in docs/posts are the following:

opcache.jit=yes|true|1
opcache.jit=tracing
opcache.jit=function

These differentiate the Tracing-JIT from the Function-JIT. Default is
tracing.

>
> Kind regards
> Brent
>
> > On 15 Sep 2020, at 07:05, Dmitry Stogov  wrote:
> >
> > This also gives me a time frame to clean up JIT code without hurry.
> > I plan to separate the common JIT code, and merge JIT and VM helpers.
> >
> > Thanks. Dmitry.
> >
> > On Mon, Sep 14, 2020 at 5:55 PM Sara Golemon  wrote:
> >
> >> On Mon, Sep 14, 2020 at 9:39 AM Nikita Popov 
> wrote:
> >>
> >>> On Fri, Sep 11, 2020 at 6:49 PM Sara Golemon  wrote:
> >>>
>  Next Tuesday, Sep 15th, has been marked on my calendar as the branch
> >> date
>  for PHP-8.0 which would open master up for 8.1 targeted work.
> 
>  This would mean that bug fixes would need to include PHP-8.0 in their
>  merge
>  chain (meaning more work to merge 8.0 targeted fixes).
> 
>  Please let Gabriel and I know how you feel about this date.  I can see
>  that
>  master is still quite active, and I don't wish to make the work to
>  stablize
>  the 8.0 release any more difficult than it has to be.
> 
> 
> >>>
> >>> I think it would be good to make this week's release beta4 rather than
> >> rc1
> >>> (without affecting the rest of the schedule). In that case we'd also
> push
> >>> back the branching and final ABI freeze two weeks.
> >>>
> >>> We're close to done with the warning to Error exception promotion task,
> >>> but haven't really started on reviewing and consolidating parameter
> names
> >>> yet (in preparation for named parameters). It would be good to have
> that
> >>> work mostly finalized before RC1, so we can limit the number of
> nominally
> >>> BC-breaking changes past RC1 (I expect we'll still fix some things that
> >>> slipped through the cracks, but at least we should prevent any mass
> >>> changes).
> >>>
> >>>
> >> Yep. This seems like a reasonable adjustment to the schedule in order to
> >> finalize these features.  I'll do beta4 tomorrow/thursday, and we should
> >> plan for RC1 branching in two weeks.  Wiki (
> >> https://wiki.php.net/todo/php80 )
> >> has been updated to reflect this.  Note that I have NOT moved the GA
> date
> >> at this time, as that would push us into Dec 10th.  Though as the date
> >> approaches we may decide to add RC5 back in for safety despite the
> >> perinavidinal timing.
> >>
> >> -Sara
> >>
> >> P.S. Yes, I made that word up. You know which one.
> >>
>
>