Re: [PHP-DEV] Initializing constants once, with code?

[Mike Schinkel]

> On Jan 8, 2020, at 4:25 PM, Mike Schinkel  wrote:
> 
>> On Jan 8, 2020, at 11:10 AM, Robert Hickman  wrote:
>> 
>> My suggestion was not a preprocessor, but what others have said
>> already, a 'shim' that goes between the parser/lexer and bytecode
>> generation which allows user code to inspect and modify the AST. This
>> idea is not unusual and Python for example can do this. The idea is
>> the basis of macro systems in Lisps, and Rust has a very nice
>> implementation of it from what I've seen in passing. The system should
>> be fully aware of the syntax, scoping, namespaces etc, the lack of
>> which is the problem with C preprocessor for example.
>> 
>> With regards to how JAI does this:
>> 
>> https://www.youtube.com/watch?v=UTqZNujQOlA
>> https://www.youtube.com/watch?v=59lKAlb6cRg=PLmV5I2fxaiCKfxMBrNsU1kgKJXD3PkyxO=20=0s
> 
> Nice!  

I replied prematurely.  

OMG, JAI's ability to run code at _compile time_ is incredible, and exactly the 
kind of thing would solve the concerns about dynamic instantiation of constants.

It would also solve a large class of performance concerns, way beyond just 
dynamic instantiation of constants, as well as allow us to implement really 
robust error checking assertions into our libraries.

Which makes me wonder the following: AFAIK PHP opcodes are not something a 
developer can handle; they are only handled by PHP itself.

IOW — correct me if I am wrong — but PHP _cannot_ generate an OpCode file to 
disk that can be named and later loaded by a different PHP app?  The only thing 
similar to this is PHAR, which AFAIK is not OpCode, right?

If not, how about we discuss about creating a full API to allow developers to 
compile to OpCode files and then load and run them?  In addition to exploring 
this run PHP code to generate OpCode before the page load actually runs?

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

Re: [PHP-DEV] Initializing constants once, with code?

[Mike Schinkel]

> On Jan 8, 2020, at 11:10 AM, Robert Hickman  wrote:
> 
> My suggestion was not a preprocessor, but what others have said
> already, a 'shim' that goes between the parser/lexer and bytecode
> generation which allows user code to inspect and modify the AST. This
> idea is not unusual and Python for example can do this. The idea is
> the basis of macro systems in Lisps, and Rust has a very nice
> implementation of it from what I've seen in passing. The system should
> be fully aware of the syntax, scoping, namespaces etc, the lack of
> which is the problem with C preprocessor for example.
> 
> With regards to how JAI does this:
> 
> https://www.youtube.com/watch?v=UTqZNujQOlA
> https://www.youtube.com/watch?v=59lKAlb6cRg=PLmV5I2fxaiCKfxMBrNsU1kgKJXD3PkyxO=20=0s

Nice!  

Never heard of JAI but will be checking it out.

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

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

[Ben Ramsey]

> On Jan 8, 2020, at 05:42, Nikita Popov  wrote:
> 
> Hi internals,
> 
> I would like to propose the following RFC, which allows using "static" as a
> return type:
> 
> https://wiki.php.net/rfc/static_return_type
> 
> While I'm personally not a fan of late static binding, we do support it and
> people do use it quite heavily, so I think we should also support it in
> return types.
> 
> Regards,
> Nikita


Yes, please!

> For the fluent method example above, many projects will use a @return $this
> annotation, rather than @return static.

In my own code, I usually use `self` to mean “return the same instance.” While 
I know that, in practice, the use of `self` is identical to using the class 
name as the return type, it seems natural to designate as practice (among my 
team) that `self` always means itself and should never refer to an instance 
with different identity.

-Ben


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] Initializing constants once, with code?

[Robert Hickman]

> After posting my objection to pre-processing I remembered there was another 
> reason I object to pre-processors that is even more significant than lack of 
> composibility.  And my objection extends to all the transpiring being done 
> with Javascript and CSS too, although I put up with those because the 
> community has mitigated some of the worst problems and because so many 
> developers have embraced them.
>

My suggestion was not a preprocessor, but what others have said
already, a 'shim' that goes between the parser/lexer and bytecode
generation which allows user code to inspect and modify the AST. This
idea is not unusual and Python for example can do this. The idea is
the basis of macro systems in Lisps, and Rust has a very nice
implementation of it from what I've seen in passing. The system should
be fully aware of the syntax, scoping, namespaces etc, the lack of
which is the problem with C preprocessor for example.

With regards to how JAI does this:

https://www.youtube.com/watch?v=UTqZNujQOlA
https://www.youtube.com/watch?v=59lKAlb6cRg=PLmV5I2fxaiCKfxMBrNsU1kgKJXD3PkyxO=20=0s

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

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

[Benjamin Morel]

>
> I would like to propose the following RFC, which allows using "static" as a
> return type:
> https://wiki.php.net/rfc/static_return_type



Big +1 from me as well. I actually asked why this wasn't supported back in
2015:

static return type in PHP 7 interfaces


— Benjamin

RE: [PHP-DEV] zend_call_method with arguments passed by reference

[mdolezal.noctuint.cz via internals]

Thank you for your answer Nikita.
Can you please give me more details what you mean? I can try that approach.
zend_call_method copies the args to params array which is assigned to 
zend_fcall_info fci. 
I can pass there for example "test" zval string.
Then the mentioned lower level zend_call_function() is called with fci as 
parameter, that's what I do.
In PHP code "test" is changed to "changed".
But after the call the fci.params are not changed, still "test", so I have 
nothing to copy back manually.


-Original Message-
From: Nikita Popov  
Sent: Wednesday, January 8, 2020 4:06 PM
To: mdole...@noctuint.cz
Cc: PHP internals 
Subject: Re: [PHP-DEV] zend_call_method with arguments passed by reference

On Wed, Jan 8, 2020 at 3:59 PM mdolezal.noctuint.cz via internals < 
internals@lists.php.net> wrote:

> Hello,
>
> I hope this is the appropriate mailing list, please redirect me to 
> better please if required.
>
>
>
> I am currently rewriting our PHP extension from PHP5 to PHP7.
>
> To call PHP methods from our C/C++ code we use slightly modified 
> zend_call_method from Zend/zend_interfaces.c (to use more arguments 
> than 2).
>
>
> Now I found out that it does not work with arguments passed by 
> reference, such as:
>
> public function FuncWithRef(array &$changeThis)
>
>
>
> if values are changed in the PHP code then zval values back in C part 
> after zend_call_function call are not influenced.
>
> With PHP5 the value was overwritten and could be used later in C code.
>
> Previously the zend_fcall_info struct for function call was filled 
> with params simply by
>
>
>
> params[0] = 
>
>
>
> In PHP7 this is changed to
>
>
>
> ZVAL_COPY_VALUE([0], arg1);
>
>
>
> After function is executed (zend_call_function) both fci.params and 
> arg1 contain still the original zval values,
>
> changes made in PHP code are not available. Is there any way how to 
> solve this?
>
> I am mainly searching for and comparing code snippets in PHP/ext 
> folder to see how things were rewritten from PHP5 to PHP7.
>
> Sorry if I missed something obvious and thank you for your help.
>

It looks like the implementation of zend_call_method() does not support this, 
as it does not copy parameters back after the call. I'd suggest to use the 
lower level zend_call_function() for the cases where you need this for now.

Nikita

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

Re: [PHP-DEV] zend_call_method with arguments passed by reference

[Nikita Popov]

On Wed, Jan 8, 2020 at 3:59 PM mdolezal.noctuint.cz via internals <
internals@lists.php.net> wrote:

> Hello,
>
> I hope this is the appropriate mailing list, please redirect me to better
> please if required.
>
>
>
> I am currently rewriting our PHP extension from PHP5 to PHP7.
>
> To call PHP methods from our C/C++ code we use slightly modified
> zend_call_method from Zend/zend_interfaces.c (to use more arguments than
> 2).
>
>
> Now I found out that it does not work with arguments passed by reference,
> such as:
>
> public function FuncWithRef(array &$changeThis)
>
>
>
> if values are changed in the PHP code then zval values back in C part after
> zend_call_function call are not influenced.
>
> With PHP5 the value was overwritten and could be used later in C code.
>
> Previously the zend_fcall_info struct for function call was filled with
> params simply by
>
>
>
> params[0] = 
>
>
>
> In PHP7 this is changed to
>
>
>
> ZVAL_COPY_VALUE([0], arg1);
>
>
>
> After function is executed (zend_call_function) both fci.params and arg1
> contain still the original zval values,
>
> changes made in PHP code are not available. Is there any way how to solve
> this?
>
> I am mainly searching for and comparing code snippets in PHP/ext folder to
> see how things were rewritten from PHP5 to PHP7.
>
> Sorry if I missed something obvious and thank you for your help.
>

It looks like the implementation of zend_call_method() does not support
this, as it does not copy parameters back after the call. I'd suggest to
use the lower level zend_call_function() for the cases where you need this
for now.

Nikita

[PHP-DEV] zend_call_method with arguments passed by reference

[mdolezal.noctuint.cz via internals]

Hello,

I hope this is the appropriate mailing list, please redirect me to better
please if required.

 

I am currently rewriting our PHP extension from PHP5 to PHP7.

To call PHP methods from our C/C++ code we use slightly modified
zend_call_method from Zend/zend_interfaces.c (to use more arguments than 2).


Now I found out that it does not work with arguments passed by reference,
such as:

public function FuncWithRef(array &$changeThis)

 

if values are changed in the PHP code then zval values back in C part after
zend_call_function call are not influenced.

With PHP5 the value was overwritten and could be used later in C code.

Previously the zend_fcall_info struct for function call was filled with
params simply by

 

params[0] = 

 

In PHP7 this is changed to

 

ZVAL_COPY_VALUE([0], arg1);

 

After function is executed (zend_call_function) both fci.params and arg1
contain still the original zval values,

changes made in PHP code are not available. Is there any way how to solve
this?

I am mainly searching for and comparing code snippets in PHP/ext folder to
see how things were rewritten from PHP5 to PHP7.

Sorry if I missed something obvious and thank you for your help.

[PHP-DEV] Bump required libcurl version to 7.17.1

[Christoph M. Becker]

Hi all,

quite a while ago I've submitted
, but received no feedback on
that so far, so I'm writing this mail.

The pull request is about bumping the required libcurl version for
ext/curl to 7.17.1, which has been released twelve years ago.  The main
reason for the bump is to remove most of the obsolete constants which
have been scheduled for removal from libcurl for more than ten years.
The fact that we still use them, has almost bitten us not long ago[1],
so I think that PHP 8 is a good opportunity to finally remove them.

If there are no objections, I'll merge PR #4917 in a week.

[1] 

Thanks,
Christoph

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

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

[Paul M. Jones]

> On Jan 8, 2020, at 05:42, Nikita Popov  wrote:
> 
> Hi internals,
> 
> I would like to propose the following RFC, which allows using "static" as a
> return type:
> 
> https://wiki.php.net/rfc/static_return_type

Very happy to see this.


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

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

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

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

Re: [PHP-DEV] Adding TypeError and ValueError to count() function

[Björn Larsson]

Den 2020-01-07 kl. 21:57, skrev George Peter Banyard:

Greetings internals,

I would like your input on adding TypeError and ValueError exceptions
to the count() function in respect to the Consistent type errors for
internal functions RFC [1], the initial PR [2] was denied as null was
not accepted as a value when it seems to be prevalent to use count()
as a substitute for isset() (this is currently done in the test runner
for php-src), although a "type error" warning was already emitted with
null.

So I've made an adjustment by still accepting null but deprecating it's
usage. An other option is to allow null as a value that always return 0.

I've also added a ValueError exception on invalid modes.
The new pull request is located at https://github.com/php/php-src/pull/4940

Any comments would be appreciated.

Best regards and happy new year.

George Peter Banyard

[1] https://wiki.php.net/rfc/consistent_type_errors
[2] https://github.com/php/php-src/pull/4572


Hi,

My take on this is that when converting a legacy code base from
PHP 5.2 to PHP 7.4, the RFC Counting of non-countable objects
generated quite a lot of hassle. Count was used for checking
return of DB values. Code piece could e.g. look like:
for($i=0; $i    $blog_result[$i]->nrOfComments = 
$blog->getNumberOfComments($blog_result[$i]->id);

}

If I read this correctly, with warnings today as is, the code after
will continue, but with exception I presume execution will stop
(unless I catch it  of course).

I still have warnings to weed out from legacy code but also
from Smarty library. So I wonder what impact this change
will have? I mean, I can live with the warnings fixing code
bit by bit...

r//Björn L

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

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

[Mark Randall]

On 08/01/2020 11:42, Nikita Popov wrote:

Hi internals,

I would like to propose the following RFC, which allows using "static" as a
return type:

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


So many "@return $this" docblocks are going to be deleted as a result of 
this when PHP8 lands.


+1 from me.

--
Mark Randall
marand...@php.net

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

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

[Rowan Tommins]

On Wed, 8 Jan 2020 at 11:42, Nikita Popov  wrote:

> I would like to propose the following RFC, which allows using "static" as a
> return type:
>
> https://wiki.php.net/rfc/static_return_type
>
> While I'm personally not a fan of late static binding, we do support it and
> people do use it quite heavily, so I think we should also support it in
> return types.
>


A big +1 from me; I'd probably have assumed it would work and be
disappointed when it didn't.

I can see why late static binding isn't to everyone's taste as a concept,
but it is very useful to emulate other features like named constructors, as
you show in the RFC.

The fluent interface example is interesting, because it doesn't actually
involve late static binding at all, we just need some way to say "what
comes out is the same type as what goes in".

Regards,
-- 
Rowan Tommins
[IMSoP]

[PHP-DEV] [RFC] Static return type

[Nikita Popov]

Hi internals,

I would like to propose the following RFC, which allows using "static" as a
return type:

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

While I'm personally not a fan of late static binding, we do support it and
people do use it quite heavily, so I think we should also support it in
return types.

Regards,
Nikita

Re: [PHP-DEV] Initializing constants once, with code?

[Rowan Tommins]

On Tue, 7 Jan 2020 at 22:19, Mike Schinkel  wrote:

> I think you are taking one of my use-cases and over-focusing on it rather
> than accepting it as just one of many applicable use-cases.
>


Yes, I dived quite deep into that one example, mostly because I was trying
to understand why you picked it.

I do think it's important though to demonstrate that a new language feature
meets a real and common need, rather than just an interesting theoretical
possibility.



Again, those are my preferences. Yours can clearly be different. But unless
> the PHP "charter" is revised to embrace "one way and only one way to
> accomplish a given task" like the Zen of Python, my preference and your
> preferences should be allowed equal weight.
>


That would be the case if the language didn't support either, and we were
choosing between, but we're not. I'm arguing for using the existing
features of the language to solve the problem, whereas you're saying we
need to add a new way to do it. That requires a higher bar than "it's not
objectively worse and I happen to like it".




> That said, maybe I should be requesting that PHP constants be able to have
> objects, too...?
>



If they can be initialised at run-time based on arbitrary code, it's going
to be hard to avoid including that in the implementation, because at the
moment constants are restricted not by types of value, but types of
expression, so I'm not sure you could say at runtime "does this value look
constant-y?".




> > Or maybe everybody really wishes it had them, but nobody's come up with
> an
> > implementation that fits into the language design?
>
> Po-ta-to, po-tah-to; a past design decision really does not matter. It is
> an example of a "sunken cost."
>


You've lost the context here. You said "Python did not feel there was a
need"; I was saying maybe they thought there was a need, but hadn't found a
solution.

It's all beside the point anyway: PHP already has compile-time constants,
so without a time machine, our discussion has to start from that basis.





> > Then all the JS and Java examples aren't going to help your argument,
> > because those are most definitely immutable variables, not compile-time
> > constants extended with initialisation syntax.
>
> My argument has been and continues to be that that is a distinction
> without a difference.
>


Your last e-mail seemed to say completely the opposite; maybe I
misunderstood:

> As for immutable variables, I see those as very useful to, but I think
their use-cases are orthogonal to the use-case I was trying to address.


I think immutable variables very much address the use cases you're trying
to address, except for the additional requirement about which syntax access
should use.




> Besides, didn't you ask for examples and I gave you one from each of five
> of the most common languages? It seems disingenuous to now try to argue the
> examples I gave don't apply on reasons of technicality.
>



I asked for examples because it's useful to examine them and see how
they're similar and how they're different. The "technicality" is that Java
didn't introduce a syntax for compile-time constants and extend it with
initialisation, they introduced a restriction which can be applied to any
variable, and which when used in a certain way is roughly equivalent to a
compile-time constant. That's a really significant difference, because it
means that they inherit all the behaviours and syntax of variables, which
PHP's constants currently do not.





> > My point was that more assumptions will break if you widen the meaning of
> > "constant" than if some variables are marked immutable.
>
> I'm all for taking those into consideration assuming we delineate them
> concretely instead of just referring to them abstractly as a class of
> unknown problems.
>
> So, what real-world specific concrete problems will this "widening" cause?
>



A couple of things come to mind:

- tools that examine expressions involving constants for things like
unreachable code, wrong types used, etc, would need to treat
run-time-initialised constants specially
- constants could now presumably be any type, including mutable objects,
which is likely to break a bunch of assumptions





> What would be interesting instead would be to have some kind of
> developer-controlled pre-loading where classes could be marked to be
> pre-loaded in some way. If we had those then one potential compromise
> would be that constants could only be dynamically-initialized in pre-loaded
> classes, which could significantly reduce Larry and your stated objection
> since the initialization would happen at preload time and not page-load
> time.
>


At the point where you have different pieces of code run at "pre-load" and
"execution", that to me is equivalent to having a pre-processor that
outputs OpCodes rather than PHP code (and thus is possibly easier to do
things like present correct line numbers to debug tools).

Running the pre-processor on preload sounds