Re: [PHP-DEV] [RFC][Voting] Fetch properties of enums in const expressions
> Am 01.07.2022 um 15:03 schrieb Ilija Tovilo : > > Hi everyone > > I opened voting for the "Fetch properties of enums in const expressions" RFC. > https://wiki.php.net/rfc/fetch_property_in_const_expressions I voted no, because this introduces a special case in const expressions that is hard to explain and seeing it in the wild will give code readers ideas on property access in consts that will never be generalizable. Imho Const expressions should soley be about declaring state not traversing it. > > Voting closes on 2022-07-15. > > Ilija > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] SensitiveParameterValue serialization behavior
> Am 26.02.2022 um 12:49 schrieb Dan Ackroyd : > > On Thu, 24 Feb 2022 at 14:11, Tim Düsterhus, WoltLab GmbH > wrote: >> >> I see two possible options to remediate this issue: >> >> --- >> >> 1. Disallow both serialization and unserialization. >> >> This will make the serialization issue very obvious, but will require >> adjustments to exception handlers that serialize the stack traces. > > That sounds the best option. Yes, people who serialize/unserialize > stack traces will need to take into account the new behaviour, but > they will need to do that anyway, and it's better for something to > fail early, when the data is serialized rather than it happen later > when someone goes to use that data. Programs continuing when they have > already failed is Bad™. > >> Allow unserialization, but poison the unserialized object and >> disallow calling ->getValue() on it. > > That sounds like something to be instantly added to the list of PHP Sadness. > >> I theoretically could add an additional public function isPoisoned(): bool >> as well. > > To me, that sounds like a workaround needed by a bad design aka a hack. > > Guilliam Xavier wrote: >> to avoid potentially breaking existing code. > > Technically, all existing code will continue to run, as no-one is > currently using SensitiveParameter and so that code will continue to > run. When people start using that feature, then yes they will need to > make sure that any stack serializer is aware of the new feature. But > that doesn't sound like a huge problem to me. That is not technically true from what I understand the SensitiveParameter will be added to core functions in a second step, so this will make them appear in existing code immediately. It would also require some iteration across the whole stack trace and all its parameters to sanitize. Code that would always look the same and have no extra purpose. However i cant seem to wrap my head around serialising stack traces with parameters. Does someone have an open source example of this kind of code? Still I am for the second option, because SensitiveParameter without a value is still enough information in an unserialized state. > > In general, I think we should only add surprising and awkward apis > when there is a really strong reason for doing so, not because there > might be a problem. If it's left as unserializable for now, people > would have the opportunity for saying why it needs to be relaxed > later, aka "no is temporary, yes is forever" for features. > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Methods Overloading in PHP
Von meinem iPhone gesendet > Am 28.02.2021 um 13:50 schrieb Eugene Sidelnyk : > > Hi there! > I faced a lack of methods overloading in PHP once again and would like to > ask will it be implemented at some point? The way php implements methods and dynamic calling it is pretty unlikely this will get implemented. See more info here: https://github.com/Danack/RfcCodex/blob/master/method_overloading.md > As well, I want you to show some pros and cons which you see in this > feature. > > Here're some thoughts about this by Yegor Bugayenko:
Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
Von meinem iPhone gesendet > Am 03.09.2020 um 09:39 schrieb Brent Roose : > > Hi all > > I want to point out the use-case when you're using CS tools, static analysers > and IDEs: they report unused variables as errors. There are ways around those > errors, but it's more convenient if there's language support. I'd say that > conceptually it's also more correct: if you're not using a variable, it > shouldn't be there. > These tools all work with documentation conventions already, it would be much easier they standardise on $_ to allow being unused instead of changing the language. > As some of you have shown, there are ways achieve the same result without > adding new syntax. Just like we didn't need short closures and keep using the > normal closure syntax, like we could write if statements and didn't need the > nullsafe operator, like we didn't need named arguments or constructor > property promotion. I think the past years of PHP devlopment have shown that > the majority likes convenient langague syntax and constructs, not because > it's absolutely necessary, but because it's just a little more clean, a > little less verbose, a bit more convenient. > > PHP has been maturing over the last years, which means there's room, and > need, for things that aren't strictly necessary. > > Kind regards > Brent > >> On 3 Sep 2020, at 09:18, Stanislav Malyshev wrote: >> >> Hi! >> >>> If it adds a micro-optimization, great, but allowing a developer to >>> explicitly signal intent is the primary argument for adding void. >>> IMO. >> >> You can signal intent by using $_ or $dummy or whatever. You don't need >> new language construct each time for each way of using or not using a >> variable. >> >> -- >> Stas Malyshev >> smalys...@gmail.com >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
> Am 16.08.2020 um 01:08 schrieb Paul M. Jones : > > HI all, > > >> On Aug 15, 2020, at 18:00, Benjamin Eberlei wrote: >> >> Additionally, Derick and I are waiting for word from Sara and Gabriel at >> the moment, but we suggested to close and reset the vote to wait until the >> discussion period is over on Tuesday to accommodate the criticism of us >> prematurely starting the vote (by accident, not intentionally). > > /me furrows brow > > If I understand correctly, that means the currently-running vote overlaps > with the discussion period? If so, that sounds (again) highly irregular. > > The proper thing to do here is a full reset: restart the 2-week discussion > period at the moment the current vote is declared null and void, then start a > new vote (if the RFC is not withdrawn) after thatn 2-week period. > > Basically, the sooner the current vote is explicitly declared null and avoid, > the sooner the properly-conducted 2-week discussion period can begin. The Voring RFC clearly states 2 weeks from the announcement on this list. If we consider the current vote an instance of human error, then i dont see how restarting the discussion helps. I spent the whole day incorporating every argument and discussion thread into the new RFC Version to be, so that voters will be fully informed by the RFC once the vote re-starts on Tuesday. > > -- > 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 > > >
Re: [PHP-DEV] Introducing compile time code execution to PHP preloading
Am 14.01.2020 um 20:23 schrieb Mike Schinkel :
>
> On Jan 14, 2020, at 1:10 PM, Larry Garfield wrote:
>>> I get your concern about recursion, but if that kind of issue is really
>>> a concern I don't see why we could not artificially limit recursion on
>>> preload to a configurable amount, with 100 being the default?
>>
>> It's not recursion itself that's an issue. It's that the behavior of the
>> code changes between preload and non-preload contexts in subtle, non-obvious
>> ways.
>>
>> I don't mean a recursive function that runs during preload. I mean if a
>> function that runs in a normal request is written recursively, it will fail
>> at high recursion levels only if the file it is in was not preloaded. So
>> whether or not foo.php was run through opcache_compile_file() changes when
>> and how code in that file will fail. That's the situation we want to avoid
>> like the plague, IMO.
>
> With respect, that feels like you are concerned about some real edge cases,
> and ignoring the probability that most code run during preloading would be
> written bespoke for preloading.
>
> ALSO, I think I may have caused confusion by calling it "preloading." In my
> mind that meant "run once" vs. "run for each page load" but I think you are
> (rightly) conflating what I have called "preloading" with the new preloading
> feature in PHP 7.4?
>
> What I have been envisioning is a `preload` (or some other) keyword that we
> could apply to functions, methods, and expressions. When `preload` modified
> functions/methods/expressions are reached during OpCode generation, rather
> than generate a call to runtime code PHP would just run the code and then
> take the return value and generate OpCode for that return value.
>
> class Foo {
> preload function bar() {
> return < a_really_time_consuming_expression>;
> }
> }
> $foo = new Foo();
> echo $foo->bar(); // This would not actually execute anything at runtime.
> // It would simply echo the constant value that
> was
> // returned by
> .
>
So like this old memoize extension? https://pecl.php.net/package/memoize
>
> I could be wrong but I find it hard to believe the runtime profile would be
> so different in this context as to create problems of the nature you are
> fearing.
>
> Maybe someone like Dimitry who understand the OpCode generation process could
> weigh in?
>
>
>>> I do completely see your points about the AST and most PHP developers.
>>>
>>> The unfortunate problem with PHP is there is no way to use 3rd party
>>> code to extend PHP w/o being able to reconfigure the server by adding
>>> extensions. It would be nice if we could come up with a way for 3rd
>>> party developers writing in C or another language — people who are more
>>> likely to test their code before distributing it — to extend PHP such
>>> as by generating OpCode files that a userland developer could load.
>>
>> That... sounds a lot like the new FFI extension? Write code in C or Rust or
>> anything that can produce a .so file, plug it into PHP, go?
>
> Unless I am misunderstanding, using an .so requires a sysadmin to add an
> extension and update php.ini. Which is a non-starter on hosted sites like
> Pantheon, WPEngine, Kinsta, Pagely, Flywheel, PressLabs and similar.
>
> What I was instead calling for what a way to extend PHP that a userland
> developer with no access to php.ini would be able to achieve.
>
> Interestingly, after my above comment I googled and came across this PHP
> extension that can load a compiled Web Assembly (.wasm) file. Something like
> this in core would be very useful:
>
> https://github.com/wasmerio/php-ext-wasm
>
> -Mike
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
