Re: [PHP-DEV] [RFC] Default expression
On Mon, Aug 26, 2024 at 12:47 PM Rowan Tommins [IMSoP] wrote: > Another approach that occurred to me was in the executor: rather than > evaluating to the default value immediately, "default" could resolve to a > special value, essentially wrapping the reflection parameter info. Then > when the function is actually called, it would be "unboxed" and the actual > value fetched, but use in any other context would be a type error. > I guess what the opponents to this RFC are zeroing on in this thread is the conclusion that `default` (as proposed) is a form of contravariant return, and thus breaks Liskov Substitution Principle. Your suggestion of making it an opaque value that cannot be read outside of the called function is a nice (and maybe the only) way to resolve this problem. -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] State of Generics and Collections
On Fri, Aug 23, 2024 at 4:27 PM Larry Garfield wrote: > Moving those definitions to attributes is certainly possible, though AFAIK > both the PHPStan and Psalm devs have expressed zero interest in it. > Part of the challenge is that such an approach will either still involve > string parsing, That's not really a challenge and would help somewhat with the current status quo where we have to guess where the type ends and the textual part of the comment begins. But it gets ugly for any type that has to include quotes (literal strings, array keys, etc). Technically one can use nowdocs, but it's not much better: https://3v4l.org/4hpte > or will involve a lot of deeply nested attribute classes. Yeah, that would look like Lisp's S-exprs, but much worse - which, in my opinion, would harm adoption. All in all, in my opinion attribute-based solutions are less ergonomic than what we already have now in docblocks. -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] [RFC] Decoding HTML and the Ambiguous Ampersand
On Fri, Aug 23, 2024 at 1:03 AM Dennis Snell wrote: > Just for reference, since I’ve looked before and not found it. Can > someone indicate where to find the PHP function documentation? There are a > number of updates I would love to propose but I don’t know where to find > the content that appears in > https://www.php.net/manual/en/function.html-entity-decode.php, for > instance. > There is a link on all doc pages (named `Submit a Pull Request`), in this specific instance it leads to https://github.com/php/doc-en/blob/master/reference/strings/functions/html-entity-decode.xml -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
Is there a reason to keep crc32? -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] Add $this return type
On Tue, Jun 25, 2024 at 9:51 AM Luigi Cardamone wrote: > > Is it possible to replace "$this" with "this"? Cleaner and coherent with > "self". > That wouldn't be possible, as `this` is a valid class name: https://3v4l.org/ujGOT -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] [Early Feedback] Pattern matching
This definitely looks like a powerful feature I'm looking forward to. If property/param/return guards are implemented, do you see them eventually replacing the property/param/return types we have nowadays? Asking for a friend.
Re: [PHP-DEV] [RFC][Concept] Data classes (a.k.a. structs)
On Tue, Apr 2, 2024 at 8:05 PM Ilija Tovilo wrote:
> Equality for data objects is based on data, rather than the object
> handle.
I believe equality should always consider the type of the object.
```php
new Problem(size:'big') === new Universe(size:'big')
&& new Problem(size:'big') === new Shoe(size:'big');
```
If the above can ever be true then I'm not sure how big is the problem
(but probably very big).
Also see the examples of non-comparable ids - `new CompanyId(1)`
should not be equal to `new PersonId(1)`
And I'd find it very confusing if the following crashed
```php
function f(Universe $_u): void {}
$universe = new Universe(size:'big');
$shoe = new Shoe(size:'big);
if ($shoe === $universe) {
f($shoe); // shoe is *identical* to the universe, so it should be
accepted wherever the universe is
}
```
--
Best regards,
Bruce Weirdan mailto:weir...@gmail.com
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Tue, Feb 27, 2024 at 6:22 PM Bruce Weirdan wrote:
>
> Hi Larry and others
>
> On Fri, Feb 23, 2024 at 12:57 AM Larry Garfield
> wrote:
> >
> >
> > I've added an FAQ section explaining why the Python/JS approach wouldn't
> > really work. To be clear, Ilija and I spent 100+ hours doing research and
> > design before we started implementation (back in mid-late 2022). We did
> > seriously consider the JS-style syntax, but in the end we found it created
> > more problems than it solves. For the type of language PHP is (explicit
> > typed properties), doing it on the property itself is a much cleaner
> > approach.
>
>
> The section you added [1] seems to focus on having both `public string
> $fistName` and `public function get/set firstName():string`, and how
> it's hard to keep types and visibility in sync. But I'm not sure if
> you considered making properties and accessors mutually exclusive. I
> mean the following:
>
> ```php
> class Person
> {
> public string $firstName; // compile time error, setter/getter
> defined
>
> public function __construct(private string $first, private string $last)
> {}
>
> public function get firstName(): string // compile time
> error, property defined
> {
> return $this->first . " " . $this->last;
> }
>
> public function set firstName(string $value): void // compile
> time error, property defined
> {
> [$this->first, $this->last] = explode(' ', $value);
> }
> }
> ```
>
> This seems to address most of the counterpoints you listed, to some degree:
>
> > What is the property type of the $firstName property?
>
> Well, you propose to allow wider write-types yourself, so the question
> would apply there as well. But presumably, the property type is its
> read type - so whatever getter returns.
>
> > but there's nothing inherent that forces, public string $firstName, get
> > firstName()s return and set firstName()s parameter to be the same. Even if
> > we could detect it as a compile error, it means one more thing that the
> > developer has to keep track of and get right, in three different places.
>
> With mutually exclusive accessors and properties it becomes just two
> places. And yes, accessor consistency would need to be checked at
> compile time. But the same can be said for the widening of write type
> you proposed.
>
> > What about visibility? Do the get/set methods need to have the same
> > visibility as the property?
>
> When there's no property the question becomes moot.
>
> > If not, does that become a way to do asymmetric visibility?
>
> Yes.
>
> > What about inconsistency between the method's visibility and the property
> > visibility? How is that handled?
>
> There's no inconsistency when there's no property. Accessor visibility
> can be different - allowing the asymmetric visibility you wanted to
> implement in your other RFC.
>
> > How do you differentiate between virtual and non-virtual properties?
>
> This one is hard to answer without asking another question: why would
> you need to? Does the requirement to know it stem from engine
> implementation details, or do you need as a person writing code in
> PHP?
>
> > For non-virtual properties, if you need to triple-enter everything, we're
> > back to constructors pre-promotion. Plus, the accessor methods could be
> > anywhere in the class, potentially hundreds of lines away. That means just
> > looking at the property declaration doesn't tell you what its logic is; the
> > logic may be on line 960, which only makes keeping its type/visibility in
> > sync with the property harder.
>
> Forbidding property declaration reduces that to double. The rest is
> mostly stylistic and can be said about traditional
> (non-constructor-promoted) properties as well.
>
> Now this approach naturally has some open questions, foremost about
> inheritance. But we probably don't need to go into those details if
> you already explored this way and found some technical obstacles. If
> you did, it would probably make sense to list them in the FAQ section.
>
> [1]
> https://wiki.php.net/rfc/property-hooks#why_not_pythonjavascript-style_accessor_methods
Resending this since I've never got a reply and it's quite possible
the message got lost due to mail list issues.
--
Best regards,
Bruce Weirdan mailto:weir...@gmail.com
Re: [PHP-DEV] Implement SeekableIterator for SplObjectStorage
On Sun, Mar 10, 2024 at 9:14 PM Niels Dossche wrote: > I opened a PR to make SplObjectStorage implement SeekableIterator, this means > that it'll now be possible to use `seek(int $offset): void` on > SplObjectStorage Note that it's a BC break for descendants of SplObjectStorage with an incompatible `seek()` already implemented (e.g. https://3v4l.org/uW9Yl), so it shouldn't happen in a patch release. Not that I expect there to be many of those, but still. -- Best regards, Bruce Weirdan mailto:weir...@gmail.com
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Sun, Mar 10, 2024 at 2:38 AM Jim Winstead wrote: > > On Sat, Mar 9, 2024, at 1:04 PM, Bruce Weirdan wrote: > > On Sat, Mar 9, 2024, 20:46 Jim Winstead wrote: > >> If the adherence to semantic versioning is meant to be strict, > > > > PHP doesn't follow semver and never had. > > Okay, strike that and replace it with "adherence to the documented release > process" which says that backward compatibility can only be broken in a > release where the first digit in the version number is incremented. Which is effectively semver, so... see above. It's not that semver (or that documented release process) is bad or unsuitable. It's just that particular part about BC guarantees hasn't been followed for at least a decade now (see https://www.php.net/manual/en/migration83.php and preceding Migrating from ... documents). > It's been over three years since 8.0 was released, how long until any > backwards-incompatible changes are going to intentionally make it into > another release? Until the next minor release, which lately have been happening close to the end of a year. -- Best regards, Bruce Weirdan mailto:weir...@gmail.com
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
Hi Jim On Sat, Mar 9, 2024, 20:46 Jim Winstead wrote: > If the adherence to semantic versioning is meant to be strict, PHP doesn't follow semver and never had.
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
Hi Kamil On Mon, Mar 4, 2024 at 4:43 PM Kamil Tekiela wrote: > I would like to start a discussion on a new RFC > https://wiki.php.net/rfc/deprecate-get-post-sessions > > Please let me know whether the idea is clear and the RFC is understandable. It would probably make sense to also list `session.trans_sid_tags` and `session.trans_sid_hosts` as deprecated. And mentioning that `output_add_rewrite_var()` is unaffected wouldn't harm either. -- Best regards, Bruce Weirdan mailto:weir...@gmail.com
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Hi Larry and others
On Fri, Feb 23, 2024 at 12:57 AM Larry Garfield wrote:
>
>
> I've added an FAQ section explaining why the Python/JS approach wouldn't
> really work. To be clear, Ilija and I spent 100+ hours doing research and
> design before we started implementation (back in mid-late 2022). We did
> seriously consider the JS-style syntax, but in the end we found it created
> more problems than it solves. For the type of language PHP is (explicit
> typed properties), doing it on the property itself is a much cleaner approach.
The section you added [1] seems to focus on having both `public string
$fistName` and `public function get/set firstName():string`, and how
it's hard to keep types and visibility in sync. But I'm not sure if
you considered making properties and accessors mutually exclusive. I
mean the following:
```php
class Person
{
public string $firstName; // compile time error, setter/getter defined
public function __construct(private string $first, private string $last) {}
public function get firstName(): string // compile time
error, property defined
{
return $this->first . " " . $this->last;
}
public function set firstName(string $value): void // compile
time error, property defined
{
[$this->first, $this->last] = explode(' ', $value);
}
}
```
This seems to address most of the counterpoints you listed, to some degree:
> What is the property type of the $firstName property?
Well, you propose to allow wider write-types yourself, so the question
would apply there as well. But presumably, the property type is its
read type - so whatever getter returns.
> but there's nothing inherent that forces, public string $firstName, get
> firstName()s return and set firstName()s parameter to be the same. Even if we
> could detect it as a compile error, it means one more thing that the
> developer has to keep track of and get right, in three different places.
With mutually exclusive accessors and properties it becomes just two
places. And yes, accessor consistency would need to be checked at
compile time. But the same can be said for the widening of write type
you proposed.
> What about visibility? Do the get/set methods need to have the same
> visibility as the property?
When there's no property the question becomes moot.
> If not, does that become a way to do asymmetric visibility?
Yes.
> What about inconsistency between the method's visibility and the property
> visibility? How is that handled?
There's no inconsistency when there's no property. Accessor visibility
can be different - allowing the asymmetric visibility you wanted to
implement in your other RFC.
> How do you differentiate between virtual and non-virtual properties?
This one is hard to answer without asking another question: why would
you need to? Does the requirement to know it stem from engine
implementation details, or do you need as a person writing code in
PHP?
> For non-virtual properties, if you need to triple-enter everything, we're
> back to constructors pre-promotion. Plus, the accessor methods could be
> anywhere in the class, potentially hundreds of lines away. That means just
> looking at the property declaration doesn't tell you what its logic is; the
> logic may be on line 960, which only makes keeping its type/visibility in
> sync with the property harder.
Forbidding property declaration reduces that to double. The rest is
mostly stylistic and can be said about traditional
(non-constructor-promoted) properties as well.
Now this approach naturally has some open questions, foremost about
inheritance. But we probably don't need to go into those details if
you already explored this way and found some technical obstacles. If
you did, it would probably make sense to list them in the FAQ section.
[1]
https://wiki.php.net/rfc/property-hooks#why_not_pythonjavascript-style_accessor_methods
--
Best regards,
Bruce Weirdan mailto:weir...@gmail.com
Re: [PHP-DEV] [PDO] 2 phase commit
On Thu, Nov 30, 2023 at 7:22 PM Larry Garfield wrote: > > I have not heard of this functionality before, so I don't know how common > it is. If it's only lightly supported and in different ways, perhaps this > is a use case for the new per-DB subclasses? > Postgre (https://www.postgresql.org/docs/current/two-phase.html), MySQL ( https://dev.mysql.com/doc/refman/8.0/en/xa.html) and Oracle ( https://docs.oracle.com/en/database/oracle/oracle-database/21/admin/distributed-transactions-concepts.html#GUID-8152084F-4760-4B89-A91C-9A84F81C23D1) all support it. -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] RFC: Short echo tag can also call closures
I think it's a non-starter because it would change how the existing
code is interpreted.
E.g. currently
```
```
outputs `rand`, but with your proposal it would invoke `rand()` and
output its result.
On Mon, Sep 18, 2023 at 8:19 PM Shailesh Humbad
wrote:
>
> Hello,
>
> I'm gauging interest on a proposed change to the short echo tag "
> CURRENTLY:
> The short echo tag "" is equivalent to "",
> which allows for beautiful MVC views like this:
>
>
> title ?>
> body ?>
>
>
> INSTEAD:
> Change the short echo tag "" to be equivalent to " is_callable($x) ? $x() : echo $x; ?>", which allows view model
> properties to be defined as closures. This syntactic sugar would
> encourage higher-performance coding practices, since it allows for
> content to be streamed rather than buffered into memory before being
> output. (Note that there is no need to pass any parameters to the
> closure, or even have that as an option.) Here is a sample:
>
> $model = new StdClass();
> $FileName = 'LargeFile.html';
> $model->bodyStream = function () use $FileName { readfile($FileName); };
>
>
> title ?>
> bodyStream ?>
>
>
> Thank you for considering!
>
> Regards,
> Shailesh
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
--
Best regards,
Bruce Weirdan mailto:weir...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On Wed, Jun 21, 2023 at 12:54 AM Máté Kocsis wrote: > * In order to finally achieve the strategic goal, we deprecate the old > function along with session_set_handler_callbacks() > as soon as the right time comes. That may be PHP 9.x or 10.y or 11.z, > whatever. For those who use callbacks now, how is this in any way better? They will eventually end up using an OOP approach anyway (as that's the strategic goal). Migrating from `session_set_handler_callbacks()` would still be (potentially) non-trivial. And what's the point migrating *to* `session_set_handler_callbacks()` if we already know it will be deprecated and removed soon enough? -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Closure self-reference
On Sat, Jun 3, 2023 at 9:11 PM Dan Ackroyd wrote: > I'm now opening the discussion for the Closure self-reference RFC: > https://wiki.php.net/rfc/closure_self_reference Looking at the syntax options on the RFC page, the following explanation is not clear to me: > * De-anonymize the function. This has a large aesthetic downside of appearing > to create the closure variable in the scope that the closure is declared in, > rather than internal to the closure scope. Does this mean that the variable wouldn't actually be created in the enclosing scope, but someone may *think* it would? -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Brainstorming idea: inline syntax for lexical (captured) variables
On Tue, Mar 14, 2023 at 7:09 PM Rowan Tommins wrote: > Outside of > those cases, though, there's no reason it should mean anything, just as > $this->foo or self::$foo doesn't mean anything outside a class. In fact, > it could be spelled capture::$foo or $scope->foo rather than just using > new punctuation, if we wanted to encourage that analogy. Would this be allowed in files included in the methods of the anonymous class? `$this->` and `self::` is, and it's a pain point for static analyzers, forcing us to invent things like `@psalm-scope-this` -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Idea - json_validate() validate schema
On Thu, Mar 2, 2023 at 1:23 PM Jakub Zelenka wrote: > The schema version should be specified by $schema keyword Unfortunately, it's not what happens in the wild. Some schemas even forbid `$schema` (e.g. Composer's one). -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Class Re-implementation Mechanism
On Tue, Feb 21, 2023 at 7:53 AM someniatko wrote: > We want to write some tests for the Service class, but we don't want > to use a real SomeDependency instance > during tests. A common approach is to either extract an interface > (JUST to make it testable), or to drop the > `final` keyword and allow extending the class. > > Both approaches have their flaws: > - extracting an interface unnecessarily complicates the system, where > only one "real" implementation of an interface is assumed. > - dropping the `final` keyword allows for the rabbit-hole of > inheritance abuse, like greatly described in this article: > https://front-line-php.com/object-oriented There's another approach that requires neither: removing `final` during class loading, for tests only. See https://github.com/dg/bypass-finals (and https://github.com/nunomaduro/mock-final-classes for plug'n'play integration with PHPUnit). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Dynamic class constant fetch]
On Fri, Nov 4, 2022 at 10:49 AM Marco Pivetta wrote:
> What's convenient about `Foo::{$bar}` vs `constant(Foo::class . '::' .
> $bar)`? I'm a bit confused by this :|
>From the static analysis POV `Foo::{$bar}` is way better, as we can immediately
see that the code is trying to access a constant of a specific class,
and we can,
e.g., flag those operations that did not validate that `$bar` actually exists
as a Foo constant.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] instance version of match ?
On Mon, Mar 28, 2022 at 7:56 PM Karoly Negyesi wrote:
> match ($object) {
> Someinterface => 'foo',
> AnotherInterface => 'bar',
> }
>
> this can not clash with any existing code as using identifiers like this
> are a syntax error currently.
That's valid code actually, see https://3v4l.org/BEcE4
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Strawpoll] Promoting redefining constant to exception
On Tue, Jan 25, 2022 at 9:45 PM Chase Peeler wrote:
> it will make this much more difficult to read since the constants.php will
> have to be
> updated:
>
> if(!defined('dbserver')){
> define('dbserver','productiondb.example.com');
> }
> if(!defined('otherconstant')){
>define('otherconstants','foobar');
> }
You could use this form for conciseness:
```
defined('dbserver') or define('dbserver', 'productiondb.example.com');
defined('otherconstant') or define('otherconstant', 'foobar');
```
IMHO it's clearer than `@define()` as it makes it explicit where you
expect a possible previous definition and where you don't.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Trait expects interface
On Wed, Jan 5, 2022 at 12:36 AM Kirill Nesmeyanov wrote: > Since «traits» are often an indicator of not very good code and many may not > use them quite correctly, for example, as helpers, I suggest adding support > for the `expects` keyword to indicate that the trait is part of the code > decomposition taking into account ISP. Prior art: @psalm-require-extends and @psalm-require-implements Psalm annotations: https://psalm.dev/docs/annotating_code/supported_annotations/#psalm-require-extends -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Problems with the mailing list [was: Re: [PHP-DEV] Request for karma to vote on RFCs]
On Tue, Jul 20, 2021 at 10:45 AM Lynn wrote: > I'm also still receiving a bunch of messages from > the mailing list in my spam folder (gmail), and there's not much I can do > about it. I fixed it in Gmail with a filter like this: Matches (goes into 'Has words' field): list:(internals.lists.php.net) Do this: Never send it to Spam -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] intersection types and null for defaults, properties and return types
On Mon, Jul 19, 2021 at 6:09 PM Dan Ackroyd wrote: > Prediction number 2: Having a null type in the language will happen > before PHP 9, which will enable people to have many bike-shedding > discussions over ?Bar vs Bar|null. Hasn't that already happened in 8.0? It seems to work [1] [1] https://3v4l.org/EfmJq -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Readonly properties - immutability by default
On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk wrote:
> Readonly properties are really useful for DDD, where everything is going to
> be immutable. It promotes best practices. However for people to use it,
> syntax should be concise and brief.
If every property of the class is readonly it would probably be better
to declare that with a class modifier.
E.g.
```php
readonly class Entity {
public int $count;
public string $data;
}
```
Though `readonly` doesn't look like a perfect fit in that position to me.
--
Best regards,
Bruce Weirdan mailto:weir...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] is_literal() compile-time awkwardness
On Mon, Jun 28, 2021 at 7:21 PM Craig Francis wrote: > There’s an awkward hitch with removing integer support. Correct me if I'm wrong, but all those inconsistencies would happen even if all integers were considered literal, e.g. https://3v4l.org/C9YpE/vld#output clearly performed compile-time concatenation with a float. > Now these aren’t security issues, and it doesn’t work the other way round: > `is_literal()` doesn't incorrectly report any user (non-literal) data as a > literal. I'd say it's fine that way. > OPcache adds its own similar twist if it’s enabled, but with the added fun > that unlike PHP’s own optimisation processes, OPcache is by its nature > inconsistent when it runs, changing what it optimises and when based on a > number of factors (e.g. available memory) and so isn’t guaranteed to > optimise the code every time. Now that's a problem. If the same code produces different results for expression literalness depending on external factors like available memory it may pass in the test environment, but fail in production. -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] is_literal() is back
On Sat, Jun 26, 2021 at 1:21 AM Craig Francis wrote: > We're going back to the original is_literal() proposal. > > https://wiki.php.net/rfc/is_literal Nice work! `chr()` returning literal strings is somewhat questionable, but otherwise this is looking very good. -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted
On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski wrote: > The failure condition of this query is > "return all rows from the table already being queried", not "return > arbitrary data the attacker selects from any table that the > application can read". Imagine that was a DELETE rather than SELECT and the failure condition becomes 'the table is emptied'. It may have less disastrous consequences (depending on how good your backup / restore procedures are) compared to arbitrary reads you demonstrated, but it is still, quite clearly, a glaring security hole caused by user input in SQL query - AKA SQL injection in layman's terms. > it differs from Injection vulnerabilities in one > fundamental way: The attacker cannot change the structure of the SQL > query being executed. I would say replacing a column name with value is changing the structure of SQL query, and, basically, in exactly the way you describe SQL injection: confusing the code (column name) with data. I wholeheartedly welcome this RFC as it was originally proposed: is_literal() doing exactly what it says on the tin, without any security claims. But it has gone far from there real quick and now people can't even name the thing. -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted
> - String + int concatenation isn't an injection risk.
I think this demonstrates it very well could be:
https://externals.io/message/114988#115038
--
Best regards,
Bruce Weirdan mailto:weir...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
On Fri, Jun 18, 2021 at 4:53 PM Craig Francis wrote:
> While philosophically more pure, there is actually no extra security
> benefit for excluding integers.
One would be potential denial of service prevention (e.g. with enormous `LIMIT`
value where only a limited set of ints was intended, like
"Items per page: 10, 20, 50, 100"). Another would be preventing abuse if you
used some integers like role IDs for access control. Using slightly
modified Matt's example:
```php
function f(array $allowed_ids) {
//
$query .= 'WHERE `foo` IN (' . implode(', ', $allowed_ids) . ')';
//
}
```
Here you really *don't* want $allowed_ids to include user input.
Overall I think allowing ints in literal concatenation without
tainting the result as non-literal
is a mistake. It would either prevent implementing proper literal int
type in future, or will make
it inconsistent (where non-literal int would be considered literal by
`is_literal()` for BC reasons).
Personally I would prefer limited applicability today that would not
prevent future consistent
implementation.
BTW, Psalm already distinguishes `literal-int` from `int` and
considers the result of
literal-string + int concatenation a non-literal string:
https://psalm.dev/r/59ad602688
This may mean that Matthew's point has been misinterpreted.
--
Best regards,
Bruce Weirdan mailto:weir...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
On Thu, Jun 17, 2021 at 12:01 AM Craig Francis wrote: > is_literal can be used for strings because we can flag what’s > user and what’s developer defined, and with Matthew’s request, it could do > integers (because an integer value alone is not inherently risky, and it’s > already used a lot). To clarify, do you imply that *all* integers are safe? Or would they also be differentiated into literal and non-literal varieties? -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
On Thu, May 13, 2021 at 10:43 PM Paul Crovella wrote: > Regarding "Comparison to other languages" Speaking of that section, there's one minor nitpick. Currently it says Perl 6 was renamed to Racket, but it was actually renamed to Raku. Racket is an unrelated, Lisp-like language. -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Draft] Body-less __construct
> If we allow it, I would restrict it to specifically the case of a) a
> promoted constructor b) which has *only* promoted parameters. I don't think
> we should allow replacing "{}" with ";" for methods in the general case.
It could also be useful when you want to make sure constructor is
*not* defined, e.g.
```
private final function __construct();
```
(often seen in singleton implementations).
--
Best regards,
Bruce Weirdan mailto:weir...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] noreturn type
On Thu, Apr 1, 2021 at 6:07 PM Benjamin Eberlei wrote:
>
> ```php
> if (!isset($user)) {
>throw new NotFoundException();
> }
> ```
>
Since `throw` is an expression (since PHP 8.0,
https://wiki.php.net/rfc/throw_expression), it must have a type for its
result,
as any expression has a type. And it's result is exactly `noreturn` (or
`never`, as this option seems to be preferred
judging by current vote results), because `throw` never returns.
It's quite natural to extend that to function calls that never return as
well. And then it makes sense to declare that type
as a part of function signature like you can do with other types.
--
Best regards,
Bruce Weirdan mailto:
weir...@gmail.com
Re: [PHP-DEV] Add __toString() to DateInterval
On Wed, Mar 3, 2021 at 1:07 PM Moritz Friedrich wrote:
> but I’m not too fond of the constant - all other built-in date constants
> translate to a string of plain format characters, which isn’t possible in
> this case
Adding another format character (similar to %c used by
DateTimeInterface::format()) would solve that.
--
Best regards,
Bruce Weirdan mailto:
weir...@gmail.com
Re: [PHP-DEV] [RFC] Add is_list(mixed $value): bool to check for list-like arrays
On Wed, Dec 23, 2020 at 7:44 PM Ben Ramsey wrote:
> I actually like the idea of flags added to `is_array()` for this.
>
> Something like:
>
> is_array($value, ZERO_INDEXED | ASSOCIATIVE | INTEGER_INDEXED)
>
For static analysis, though, unary predicate (e.g. `is_list()`) is much
easier to work with, secondary only to actual type. Flags may lead to
indirection, such as (contrived example)
```php
class C {
const FLAGS = ZERO_INDEXED | ASSOCIATIVE;
private function getFlags(): int {
return static::FLAGS;
}
public function foo(array $array): void {
if (is_array($array, $this->getFlags())) { ... }
}
```
--
Best regards,
Bruce Weirdan mailto:
weir...@gmail.com
Re: [PHP-DEV] #[Deprecated] Attribute
On Tue, Dec 22, 2020 at 8:55 PM Sara Golemon wrote: > > You could do that now with a polyfill from userspace. If the annotation > need not have an effect, then it's just any other userspace implementation. > It's possible now, while the attribute is not provided by PHP. But once it gets introduced and *if* it forbids usage on some elements it wouldn't be possible to fix this from userspace. -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] Proposal: Adding functions any(iterable $input, ?callable $cb = null, int $use_flags=0) and all(...)
> On Sun, Aug 30, 2020 at 6:13 PM tyson andre
> wrote:
>
>> > I like this, but I do not like the flags. I don't think they're at all
>> useful. A lot of the other discussion in the thread seems to be needlessly
>> complicating it, too.
>> >
>> > all() and any() only need return booleans. Their callbacks only need
>> return booleans. That's the point. first() makes sense to add, and it
>> would return the first value that matches.
>>
>> What would first() return on failure? Would it throw (inefficient)?
>> Would it set an optional output reference to distinguish between
>> returning the value null from an iterable and the null from no matches?
>>
>
> If it took the default value as well it could return that. While it's
> useful in itself it also would enable you to pass a marker object and check
> the identity of that to know if no matches have been found:
>
> $none = new stdClass;
> $element = first($collection, fn($elt) => ...);
> if ($element === $none) {
> // nothing found
> }
>
Of course it should have been `$element = first($collection, fn($elt)
=>..., $none);`
--
Best regards,
Bruce Weirdan mailto:
weir...@gmail.com
Re: [PHP-DEV] Proposal: Adding functions any(iterable $input, ?callable $cb = null, int $use_flags=0) and all(...)
On Sun, Aug 30, 2020 at 6:13 PM tyson andre
wrote:
> > I like this, but I do not like the flags. I don't think they're at all
> useful. A lot of the other discussion in the thread seems to be needlessly
> complicating it, too.
> >
> > all() and any() only need return booleans. Their callbacks only need
> return booleans. That's the point. first() makes sense to add, and it
> would return the first value that matches.
>
> What would first() return on failure? Would it throw (inefficient)?
> Would it set an optional output reference to distinguish between returning
> the value null from an iterable and the null from no matches?
>
If it took the default value as well it could return that. While it's
useful in itself it also would enable you to pass a marker object and check
the identity of that to know if no matches have been found:
$none = new stdClass;
$element = first($collection, fn($elt) => ...);
if ($element === $none) {
// nothing found
}
--
Best regards,
Bruce Weirdan mailto:
weir...@gmail.com
Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings
On Wed, Jul 22, 2020 at 4:21 PM Christian Schneider wrote: > but not to arithmetic *operators* like 42 + "" because that doesn't > currently trigger E_WARNING AFAIK. > It does produce warning since PHP 7.1 : https://3v4l.org/4CV1E -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods
On Fri, May 22, 2020 at 7:26 PM Marco Pivetta wrote: > Overall, this RFC breaks some design capabilities that are within the > language, specifically around `__`-prefixed methods in the language. Wouldn't your use cases be covered by `protected final` though, as proposed by Pedro? -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] [RFC] Function pipe operator
Haskell has & operator in Data.Function module which is exact equivalent of the proposed feature. Link: https://hackage.haskell.org/package/base-4.8.0.0/docs/Data-Function.html#g:2 Example: https://repl.it/repls/KindLightsalmonApplicationserver On Wed, Apr 22, 2020 at 9:09 PM Larry Garfield wrote: > On Wed, Apr 22, 2020, at 3:25 AM, Guilliam Xavier wrote: > > On Tue, Apr 21, 2020 at 4:44 PM Larry Garfield > wrote: > > > > > > On Mon, Apr 20, 2020, at 11:20 PM, Stanislav Malyshev wrote: > > > > Just a small pedantry note - in a comparison section, the RFC > compares > > > > this syntax to function composition. But this is not function > > > > composition. This is a syntax sugar for calling two functions one > after > > > > another, not operator that produces a function. It sounds pedantic > but > > > > it's rather important distinction - if |> is composition, than $foo > |> > > > > $bar is a new callable provided $foo and $bar are callable (but no > > > > function is actually being called here!). If |> is call syntax, it's > > > > actually the result of calling $bar($foo). > > > > > > > > So comparing it to function composition is a bit confusing. > Otherwise it > > > > looks OK to me, except the syntax for calling functions and methods > is a > > > > bit awkward, but it's not the problem of this RFC I imagine. > > > > > > I'm not sure I follow. The only place composition is mentioned is in > the F# section, where it calls out specifically that we're implementing > "pipe forward" and *not* the composition operators ( >> ). Is that unclear? > > > > Actually it's also mentioned in the Haskell section, but as "function > > concatenation" (which adds to the confusion I guess). > > Ah, I see what you mean. I've adjusted that section to be clearer about > what Haskell does. > > > Speaking of Haskell, that reminded me of > > http://learnyouahaskell.com/a-fistful-of-monads#walk-the-line where > > the author defines a custom `-:` operator such that `x -: f` desugars > > to `f x` (equivalent to how `$x |> $f` would desugar to `$f($x)` with > > the RFC), which allows to write e.g. `xs -: sort -: reverse` instead > > of `reverse (sort xs)` or `(reverse . sort) xs`. > > If I ever actually wrote Haskell, I'd find that extremely useful. :-) > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
On Fri, Feb 14, 2020 at 5:47 PM Paul M. Jones wrote: > > - rename $get to $query, populating it from `$globals['_GET']`, on the basis > stated above > - rename $post to $input, populating it from `$globals['_POST']`, on the > basis that it typically relates to the parsed form of php://input What about $query and $body? That would be closer to the terminology used in HTTP RFCs. -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Initializing constants once, with code?
There's also a fourth approach that does not involve any changes to PHP: autoload + eval. When PHP is looking for your class, in your autoload you load the values from config, generate the class source and eval() it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli needs a method to bind a single parameter
On Mon, Nov 25, 2019 at 8:06 PM Joel Hutchinson
wrote:
> This proposal would leave the previous mysqli_stmt_bind_param mostly
> untouched. Instead, the two could be used in tandem
> $sql = 'SELECT name FROM db.customer WHERE record_id = ? AND shipping_zip =
> ?';
> if(isset($_GET['zip'])) $sql .= ' AND billing_zip = ?';
>
> $stmt = $db->prepare($sql);
> $stmt->bind_param('is', $_GET['record_id'], $_GET['shipping_zip']);
> if(isset($_GET['zip'])) $stmt->bind_single('s', $_GET['billing_zip'], 3);
> $stmt->execute();
> This necessitates a small change to mysqli_stmt_bind_param, in that the
> current function has a parameter check to ensure that the number of binds
> matches the number of parameters in the query (or else it emits an
> E_WARNING). That check would have to move to mysqli_stmt_execute, if it is
> still to be performed.
If `bind_param` is allowed to do incomplete bind (as in your example
where you supply 2 out of 3 required bound parameters) t
hen there's no need for additional method, as you could simply do:
if (isset($_GET['zip'])) $stmt->bind_param('s', $_GET['zip']);
--
Best regards,
Bruce Weirdan mailto:weir...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] anti-coalescing-operator
Hi Ken > $_SERVER['fname'] !?? $user->setName($_SERVER['fname']); > $_SERVER['lname'] !?? $user->setName($_SERVER['lname']); > $_SERVER['mname'] !?? $user->setName($_SERVER['mname']); > $_SERVER['phone'] !?? $user->setName($_SERVER['phone']); > $_SERVER['email'] !?? $user->setName($_SERVER['email']); What you described is already achievable with short-circuit && : isset($_SERVER['fname']) && $user->setName($_SERVER['fname']); Besides, it's a widely used idiom known from shell scripting. -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exit() via exception
On Fri, Oct 11, 2019 at 2:43 PM Andreas Hennings wrote: > What other use cases exist for exit()? Setting exit code for cli scripts. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote
On Sat, Jun 22, 2019 at 6:32 PM Nikita Popov wrote:
>
> The normal str_starts_with() function is perfectly safe to use on UTF-8
> strings,
Only if you assume strings to be normalized to the same form. Checking if NFC
string starts with NFD substring by checking them bit by bit is going
to yield false
negatives [1]
[1] https://3v4l.org/4HgUL
--
Best regards,
Bruce Weirdan mailto:weir...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Symbol implementation
On Sat, Apr 27, 2019 at 11:57 PM Dan Ackroyd wrote: > > typehint > > Please could people stop using that word. PHP's type system for > parameters and return values are actual types, not just hints. People use the term PHP itself uses: https://www.php.net/results.php?q=typehint&l=en&p=all -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][DISCUSSION] Multilingual PHP
On Fri, Apr 12, 2019 at 1:10 AM Derick Rethans wrote: > > My favourite annoyance is using a non breaking space in > function/method names ;-) "Better" yet, you can use characters that are different, but look the same as Latin chars e.g. CYRILLIC SMALL LETTER ES (U+0441) instead of (LATIN SMALL LETTER C U+0063). Incidentally these two chars also share the same physical button in English/Russian keyboard layouts, so it's a mistake easy to make and very hard to spot visually: https://3v4l.org/rjjU9 -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][DISCUSSION] Multilingual PHP
On Fri, Apr 12, 2019 at 12:17 AM Benjamin Morel wrote: > This may be harder for people having a native language with a different > alphabet, though. > That's unlikely to be a problem. Even to get to the PHP manual you have to type `www.php.net` (or `google.com` if you want to google something), so it implies you have a way to enter latin characters. Keyboard layout switching is a problem solved decades ago. -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] RFC Draft: Comprehensions
> array_map and array_filter combined This example has array_map and array_filter in wrong order (duplicated once or twice below as well). The RFC proposes to allow multiple `for`s in comprehensions, and really could benefit from an example of such usage.
Re: [PHP-DEV] [RFC] JIT
On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov wrote: > > PHP+optimizer (-dopcache.jit_buffer_size=0): 32.29s (100%) > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=5000): 30.72s (95.1%) > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=5000 > > -dopcache.jit=1201): 29.95s (92.7%) > > It may be interesting to try -dopcache.jit=1235. It should JIT only hot > functions and requires some warm-up. For this use case 1201 was the fastest of all the options I tried (including 1235). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] JIT
After figuring out that opcache.jit_buffer_size is specified in bytes (not in megabytes, as RFC states) I got ~5% speedup running vimeo/psalm (static analyzer) on its own codebase with default JIT flags and ~7.3% with minimal JIT (1201). PHP+optimizer (-dopcache.jit_buffer_size=0): 32.29s (100%) PHP+optimizer+JIT (-dopcache.jit_buffer_size=5000): 30.72s (95.1%) PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=5000 -dopcache.jit=1201): 29.95s (92.7%) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal fo "Code-free constructors declaration"
On Wed, Jan 23, 2019 at 2:32 PM Andrey O Gromov wrote:
> Proposed syntax
> class A($prop) extends B("BlaBla", $prop) {
> }
Would this work with anonymous classes? If so, how would the syntax look like?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions
On Wed, Feb 01, 2017 at 07:45:50AM -0800, Rasmus Lerdorf wrote: > The reason it is feasible to do this for single-expression closures in this > short form syntax is that you don't typically need a local scope at all for > these short closures and the syntax doesn't convey the idea that you would > have a local scope. Does this mean, in the context of this RFC, that short-form lambdas won't have their own scope though? I think it's not clear from RFC. Example: // would this create $ret in the outer scope assuming $ret was not // defined array_map(fn($elt) => $ret[] = $elt, [1]); var_dump($ret); // NULL or array(1) ? Current implementation (available on 3v4l.org) does create a local scope, but it should probably be explicitly stated in the RFC (and docs, should the RFC get accepted). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enumerated Types
> (Off-topic: there are some place where I can found the internals talking about that? > The externals.io not allows search.) http://markmail.org/search/?q=https%3A%2F%2Fwiki.php.net%2Frfc%2Fenum+#query:https%3A%2F%2Fwiki.php.net%2Frfc%2Fenum%20list%3Anet.php.lists.internals+page:1+state:facets (if the link is broken just search for the exact rfc url on markmail.org)
