>
> Regarding $field vs. $this->propName, there's a few reasons we went that
> route.
Overall I think this is a really good proposal, but you might want to
consider a second vote for that particular syntax.
`$field` vs `$this->propName` feels a little magical. It's a simpler magic
than actual ma
>
> What's the advantage of a language construct over the following?
>
> ```php
> /**
> * @template T of object
> * @psalm-assert T $value
> * @param class-string $type
> */
> function as(mixed $value, string $type): mixed
> {
> if (! $value instanceof $type) { throw
> SomeKindOfException::
On Thu, 8 Aug 2019 at 19:08, Zeev Suraski wrote:
> 3. Putting your apparent personal bias against backwards compatibility
> aside - if P++ goes in the directions you're hoping for - towards giving
> you the goodies on your wish list, why would you care if PHP still existed
> without these new ch
There are already some userland taint-checking solutions for PHP e.g. the
Phan taint-check plugin from MediaWiki:
https://www.mediawiki.org/wiki/Phan-taint-check-plugin
I'm working on my own userland solution, too (based on Facebook's
approach). Demo is here: https://psalm.dev/r/ebb9522fea
> If anything, this proposal would help user-land solutions (it gives them
> more information while the code is in running).
>
Well, it might help runtime-based user-land solutions, but not static
analysis-based solutions.
In our bug disclosure program at Vimeo we've had no SQL injection issues
r
Looking at our notice logs, I estimate (fairly roughly) that it would
require about a week's worth of my time to fix these issues in vimeo.com’s
700K LOC codebase (the undefined variables are confined to our views).
IMO it's akin to taking the training wheels off the language – I think the
PHP eco
2019 15:22:22 BST, Matthew Brown
> wrote:
> >Looking at our notice logs, I estimate (fairly roughly) that it would
> >require about a week's worth of my time to fix these issues
>
> I honestly thought you were posting that as an argument against. A week of
> resource
ew code with sth like declare(strict_variables=1);
> or declare(SomeNamespace\Foo:strict_variables=1); That way, people can write
> new code in a better way, include new libraries and upgrade old code piece by
> piece without any big pressure.
>
> Regards
> Thomas
>
>>
It's not breaking all the things - it's breaking code that should have been
broken already, but somehow wasn't.
On Wed, 28 Aug 2019 at 12:38, Rowan Collins wrote:
> On 28 August 2019 16:05:13 BST, Marco Pivetta wrote:
> >A week for 700KLOC is *impressively low*.
> >Many organisations spend more
Wed, Aug 28, 2019 at 5:22 PM Matthew Brown
> wrote:
>
>> Looking at our notice logs, I estimate (fairly roughly) that it would
>> require about a week's worth of my time to fix these issues in vimeo.com
>> ’s
>> 700K LOC codebase (the undefined variables are conf
both static analysis
tools and runtime error handlers.
On Wed, 28 Aug 2019 at 13:24, Rowan Collins wrote:
> On 28 August 2019 17:53:55 BST, Matthew Brown
> wrote:
> >It's not breaking all the things - it's breaking code that should have
> >been broken already, but
I'm no management expert, but I'd be surprised if a boss who won't set
aside time to fix a few undefined variables nevertheless green-lights
rewriting everything in C#.
On Wed, 28 Aug 2019 at 12:26, Chase Peeler wrote:
> On Wed, Aug 28, 2019 at 12:12 PM Mark Randall wrote:
>
> > On 28/08/2019 1
e well to other languages.
With this change we can make it harder for people to write bad code, which
I think will result in existing PHP users becoming better developers.
On Wed, 28 Aug 2019 at 14:32, Zeev Suraski wrote:
>
>
> On Wed, Aug 28, 2019 at 8:20 PM Matthew Brown
> wrote:
>
If we want PHP to be as easy as possible then $nullref->bar(),
$foo->someUndefined(), new UndefinedClass etc shouldn’t be exceptions either -
they can just be notices.
> On Aug 28, 2019, at 4:01 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>> Javascript has treated undefined variables as a catcha
This is where I think PHP may have broken us a little.
I just asked a few non-PHP developers here what they expect "(function () {
$a++; })()" to do, and they agreed it would be some sort of error. Got the
same answer for "(function () { $a->bar = 5; })() ".
Indeed, anyone who's used another C-li
$foo++ becoming 1 when $foo is undefined is not intuitive to me.
To take a very trivial example, that behaviour causes “for ($i = 0; $i < 10;
$I++) {}” to loop indefinitely.
> On Aug 28, 2019, at 6:52 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>> This is where I think PHP may have broken us a li
I don’t think it’s helpful to compare C#’s BC policies to PHP’s. C# is used
today mostly as its architect intended at its founding. PHP, having
transitioned from a templating system to a fully-fledged language, is used
quite differently.
> On Aug 29, 2019, at 11:50 AM, Chase Peeler wrote:
>
>
- Agree on the usefulness of a stringable meta-type.
- Hack supports an explicit “: this” return type (without dollar) when
returning “new static(...)”. I think I might prefer that to “: static”.
- From a type perspective, I don’t understand the “int|void” idea - it might
make your users’ life
Without your contributions in the early 2000s, PHP likely would not enjoy
the popularity it does today.
But I don't think that gives you veto power over the entire process. You
haven't made any significant contributions to the codebase in over a
decade, and yet the language has still gained many m
>
> that don't fundamentally change the language
There's clearly a big disagreement about whether this is a fundamental
change or not.
Preventing something that the entire field of software engineering frowns
upon (and that most PHP developers avoid like the plague) doesn't seem like
a *fundamen
>
> What if Java suddenly said that all properties are suddenly private, and
> can only be accessed through getter/setter methods?
>
If Java announced that the next major version was to make the change after
95% of userland developers favoured it and over 2/3rds of their internals
team did, I'd th
I'm sure that some people wrote code like this, expecting it to always work
in PHP:
if ($some_condition) define("HELLO", 0);
if (HELLO) { var_dump("got here"); }
The equivalent, relying on buggy behaviour, PHP code looks like
if ($some_condition) $hello = 1;
if (!$hello) { var_dump("got here");
Though this is truly a stylistic complaint, I think it will lead to
harder-to-analyse code.
Currently I have a static analysis tool that can verify (in 99% of cases)
whether all properties of a class have been initialised in the constructor.
This check is even more important in PHP 7.4, where use
> As far as I know, the only viable way to do that is to make the array
> intrinsically typed, which means that types are validated when elements are
> inserted into the array, not when it is passed across a function boundary.
> In other words, array generics.
>
What if we left the array type alon
Someone recently requested something similar for a PHP static analysis tool
I wrote (https://psalm.dev/r/f75997a263), though that version only allows
lazy initialisation inside the class in which a given property is declared.
Personally I don't like either approach – I think per-property getters a
This proposal is great, but most PHP static analysis tools already do a
reasonable job of understanding by-reference assignment and detecting bugs
there (an exception is closure use by-reference checks, which is a
static-analysis no-man's land).
No static analysis tools catch your specific use-cas
This is expected behaviour given my understanding of how late static binding
works:
If there is a chain of “self::” calls that ultimately ends in
“static::someMethod”, then PHP behaves as if every preceding call was a call to
“static::”, not “self::”. In your second call you’re explicitly overr
For information that's needed at runtime (as opposed to documentation or
static analysis) docblocks have an obvious overh
I think the syntax here looks great, and I think this would be an exciting
addition to the language. I want to build things with it!
On Mon, 9 Mar 2020 at 10:43, Benjamin Eber
Saying "the syntax makes my eyes bleed" is slightly useless feedback.
You could say "it's hard to scan", but I don't even think that's true –
prepending everything << makes it easy to pick out attributes in plain text
at a glance, and one can assume that IDEs will help even further.
Additionally
r 9, 2020, at 9:48 PM, Mike Schinkel wrote:
>
>
>>
>> On Mar 9, 2020, at 9:36 PM, Matthew Brown wrote:
>>
>> Saying "the syntax makes my eyes bleed" is slightly useless feedback.
>
> That was just a header. There was elaboration right below it:
>
I love the idea!
The syntax for new objects looks a little verbose – would it be possible to
use
$foo = new Foo()[
property1 = "hello",
property2 = 5,
];
as an alternative to
$foo = (new Foo())->[
property1 = "hello",
property2 = 5,
];
On Mon, 16 Mar 2020 at 07:48, Jakob Givoni wrote
sure Nikita could clarify, though.
On Mon, 16 Mar 2020 at 21:13, Jakob Givoni wrote:
> On Mon, Mar 16, 2020 at 9:10 AM Matthew Brown
> wrote:
> > I love the idea!
> Thanks Matthew!
>
> > The syntax for new objects looks a little verbose – would it be possible
> to us
I think this is great.
It reminds me of a construct that Hack introduced called "as expressions":
With throw expressions the Hack assignment,
`$a = $b as string;`
would be equivalent to the PHP assignment
`$a = is_string($b) ? $b : throw new TypeError('$b must be a string');`
If this passes,
I accept that it adds an extra level of understanding to the language – if
you see
function addAmounts($a, $b) { return $a + $b; }
you no longer definitely know the answer will be numeric.
However, I imagine that the sorts of people who will use this are _also_
the sorts of people who would add
stian Bergmann wrote:
> Am 21.01.2020 um 22:21 schrieb Matthew Brown:
> > What if we left the array type alone, and instead focussed on "list"
> > type and "dict", "dict" types?
> >
> > That would allow a clear break from previous behavi
Before I create an RFC or attempt a reference implementation, is there any
interest in adding (and then obviously supporting in perpetuity) a list
type?
The first line of PHP's documentation for "array" states: "An array in PHP
is actually an ordered map". There are some optimisations that make ar
>
> Making a special kind of array _value_ that must stay a “list” sounds
> more problematic… I think without automatic casting back and forth from
> regular “arrays” it might play badly with existing code, but then there
> would be no point…
>
Makes sense – then conversion from lists to arrays wo
Thanks for your comments!
> How would array_shift(), array_merge(array, list) ... be handled? Would
they return lists or arrays?
I think they would return lists where appropriate – Psalm & Phan already
infer some of that behaviour, adding runtime support would be an
undertaking, but not impossibl
t 13:28, Larry Garfield wrote:
> On Tue, Apr 21, 2020, at 2:00 PM, Matthew Brown wrote:
> > Before I create an RFC or attempt a reference implementation, is there
> any
> > interest in adding (and then obviously supporting in perpetuity) a list
> > type?
> >
>
won't be a
drop-in-replacement, they won't feel familiar to the average PHP developer,
and I imagine few people would update existing code to use them, because
it'd be too risky.
On Wed, 22 Apr 2020 at 15:01, Larry Garfield wrote:
> On Wed, Apr 22, 2020, at 1:49 PM, Matthe
> For simplicity's sake I haven't
> implemented a type declaration right now, just an is_list() function,
> but it could easily be extended to one
This is a crucial question – should is_list function like
is_numeric($some_string), where is_list just tells you about the keys in
the array at a given
>
> Anyway, I hope this was interesting and can help inform discussion and
> perhaps provide inspiration!
>
This was very useful, and it makes me feel more strongly that list should
be an entirely separate type so that checking for packed keys is rarely
necessary.
> This is the *design* process for a language, and it's important...
Stepping back to reconsider how collections work generally, and how we can
improve them in a graceful way that leads to a clean end-state, would be
very valuable.
Though you have much more experience with internals than I do, I t
>
> IIRC, they switched from object semantics to value semantics (like PHP
> arrays). Can someone more knowledgeable confirm?
>
Yes, sorry – Hack introduced the vec type (with value semantics) in 2016
after they'd experimented first with Vector (object semantics). Use of
Vector is now discouraged.
>
> I'm not as strongly against adding "mixed" to the language as Bob, but I'm
> not convinced I'd ever bother using it.
>
I'm opposed to the use mixed in codebases – I try as best I can to remove
it from any code I come across, and a static analysis tool I've built flags
the use of mixed types wh
>
> How much would you like/be adverse to a rector rule that changes `mixed`
> into a long union type (without `resource` in it)?
> Considering above posts, `mixed` is effectively
> `null|bool|string|int|float|array|object|resource`,
>
At runtime those things are effectively the same, but in th
This would break quite a lot of existing code, though PHP could add an
explicit keyword like "inout" that catches this behaviour (see example in
Hack: https://docs.hhvm.com/hack/functions/inout-parameters).
Today these issues can also be caught with static analysis:
https://psalm.dev/r/1f670956ab
> I do not see a point in soft reserving something we don't even know if
> it will make it into 8.x.
An enum implementation seems like something that almost certainly will make it
into the language in the next 4 years, given PHP’s gradual adoption of features
that already exist Hack (e.g. att
On Tue, 14 Jul 2020 at 19:59, Josh Bruce wrote:
> Implement an interface and magic method to allow objects to represent
> false (or empty) while still be valid instances of the custom object (type).
>
> https://wiki.php.net/rfc/objects-can-be-falsifiable <
> https://wiki.php.net/rfc/objects-can-b
>
>
> I don't see how that would happen. What non-pathological case would allow
> for $foo && !$foo == true?
>
>
I suppose something a little less pathological would be
`$collection && $collection->pop() && !$collection`
which is still pretty icky (to me at least).
The other implication is that
On Thu, 20 Aug 2020 at 01:42, Sergey Panteleev
wrote:
> Hi, Benjamin,
>
> I think Nikita's suggestion is suitable for these purposes:
> https://github.com/php/php-rfcs.
>
> At the moment this is an experimental repository, but in this case, it
> will be quite possible to get feedback from the com
This would be a fantastic addition, and it would also alleviate an issue in
static analysis land where it's very tricky (in the general case) to verify
exactly what implications successfully completing a given foreach loop has
on the array being iterated over (e.g.
https://github.com/vimeo/psalm/is
Quick thing before I get into my own reaction:
Transpiling is normally thought of as the process of converting one
language into another. Tools like Babel transpile TypeScript to JavaScript.
What's being proposed here (AFAICT) is type erasure – the generic type
information would be erased during
> On Sep 17, 2020, at 1:28 PM, Brent Roose wrote:
>
> But I don't want to get stuck on phrasing, if elidiing is the right term as
> Larry suggests, let's go with it!
No, the correct term is “type erasure”:
https://en.m.wikipedia.org/wiki/Type_erasure
Its opposite is called reification:
https:
> On Sep 17, 2020, at 3:25 PM, Levi Morrison
> wrote:
>
>
>>
>> On Thu, Sep 17, 2020 at 1:00 PM Matthew Brown
>> wrote:
>>>> On Sep 17, 2020, at 1:28 PM, Brent Roose wrote:
>>> But I don't want to get stuck on phrasing, if elidiing
I think the addition of runtime-erased generics would be a good thing for the
language.
I don’t think PHP should perform any sort of checking of generic parameters at
compile time. No other equivalent interpreter performs those compile-time
checks, and it’s also *very* complex — since adding su
W/r/t the goals:
– Promote the release of PHP 8 to the PHP developers
> – Promote PHP as a modern language, as well as the PHP 8 release, to the
> general tech audience
The page's design does a *great* job of promoting PHP 8 to existing PHP
developers, but a general tech audience skeptical of PH
>
> > or https://psalm.dev/ (open source) are projects in that area
> > (Matthew Brown is one of the authors of Psalm)
> >
> I don't like the idea of executing that on www.php.net for a few reasons,
> but someone else mentioned the possibility of donated cpu time
This proposal is interesting, and I see why the enum proposal makes it
useful.
Supporting this will mean a small amount of work for me (assuming it
passes) and other static analysis tools, but I don't want that to factor
into anyone's decision.
I am curious, though, whether the scope of this RFC
Hey all,
Is there interest in prohibiting whitespace around double colons in the
next major PHP version?
I was surprised to learn that PHP treats :: similar to ->, allowing double
colons like
A::
b();
Looking at the top 2,000 packages in Packagist I can't find any evidence of
people using a dou
There are plenty of places where PHP doesn't allow whitespace currently.
The most comparable example is between namespace separators:
Ns \ bar();
Ns \ SOME_CONST;
are both syntax errors.
`MyClass::bar()` and `MyClass::SOME_CONST` are often used in place of
`Ns\bar()` and `Ns\SOME_CONST` because
On Mon, 15 Feb 2021 at 11:05, Sara Golemon wrote:
> That change was made very recently (8.0) and was done for technical
> reasons (attributes) not aesthetic ones.
>
> Personally, I agree that adding whitespace around double colon is a
> suspect move, but breaking valid code for the sake of one's
15 Feb 2021 at 15:06, Rowan Tommins wrote:
> On 15/02/2021 14:52, Matthew Brown wrote:
> > The most comparable example is between namespace separators:
> >
> > Ns \ bar();
> > Ns \ SOME_CONST;
> >
> > are both syntax errors.
>
>
> As Sara says, this o
On Tue, 23 Feb 2021 at 06:21, Nikita Popov wrote:
> Another possibility would be to recognize T_ENUM in the lexer, but only if
> it is followed by whitespace and an identifier. This would possibly be
> friendlier for tooling using token_get_all(). It would not permit comments
> in between the tok
Hey!
Long-time internals lurker, first-time RFC creator & C coder.
Could I get some karma please?
Best wishes,
Matt
Thanks!
On Wed, 10 Mar 2021 at 11:30, Christoph M. Becker wrote:
> On 10.03.2021 at 16:54, Matthew Brown wrote:
>
> > Long-time internals lurker, first-time RFC creator & C coder.> > Could I
> get some karma please?
> Sure! RFC karma has been granted for mattbrown.
Hey,
Ondřej Mirtes and I present an RFC for the noreturn type:
https://wiki.php.net/rfc/noreturn_type
The feature already exists in Hack (the primary inspiration) and is
currently supported by our static analysis tools inside docblocks, and we
feel there's a good argument for it to be supported b
On Wed, 10 Mar 2021 at 13:55, Rowan Tommins wrote:
> I am however slightly confused by what exactly the implementation
> checks, and when. Is it actually looking for "exit" and "throw" statements?
>
No. Any function annotated with `: noreturn` causes the engine to insert
a ZEND_VERIFY_NORETURN_T
On Wed, 10 Mar 2021 at 16:04, Kamil Tekiela wrote:
> I am concerned with some edge cases. What if a function both returns and
> throws at the same time? For example:
>
> function a():noreturn {
> return throw new Exception('Boom!');
> }
>
> or
>
> function a():noreturn {
> try {
> throw new E
On Sun, 14 Mar 2021 at 12:02, Gert de Pagter wrote:
> Hey Internals,
>
> Recently i've been working on an older code base, where we have a lot
> of classes with all
> static methods. We've been moving to injecting the classes, and
> calling the methods as if they
> were not static.
>
> I wanted t
On Sun, 14 Mar 2021 at 18:09, Rowan Tommins wrote:
> Are you saying that having the parent::getSomeInt() call fail would be
> problematic?
>
>
Yes, that's where this becomes unsound – you can call the child method
statically, but the parent call assumes a dynamic instance.
This is just my persp
On Mon, 15 Mar 2021 at 09:36, Nikita Popov wrote:
> I'm not sure I follow your point. The fact that something is compatible,
> does not mean that you can just blindly perform a forwarding call. For
> example, consider this:
>
> class A {
> public function method(string $x) {}
> }
>
> class B
On Fri, 19 Mar 2021 at 10:53, Nikita Popov wrote:
> On Fri, Mar 19, 2021 at 3:45 PM Marco Pivetta wrote:
>
>> Hey Nikita,
>>
>> On Fri, Mar 19, 2021, 14:35 Nikita Popov wrote:
>>
>>>
>>> Is it allowed to declare a noreturn function that returns by reference?
>>>
>>> function &foo(): noreturn {}
On Sat, 20 Mar 2021 at 11:35, Larry Garfield wrote:
> My main concern is around the covariance of inheritance. The example
> given:
>
> abstract class Person
> {
> abstract public function hasAgreedToTerms(): bool;
> }
>
> class Kid extends Person
> {
> public function hasAgreedToTerms()
On Tue, 23 Mar 2021 at 05:32, G. P. B. wrote:
> I'm calling this proposal pure intersection types as there would be no
> possibility of mixing intersection and union types, I'm leaving this as a
> future scope.
>
Does this miss an opportunity, though? It's useful to be able to write
A&B|null.
On Thu, 25 Mar 2021 at 10:23, Christian Schneider
wrote:
> Am 25.03.2021 um 14:29 schrieb Mark Randall :
> > On 25/03/2021 09:28, Rowan Tommins wrote:
> >> That's not quite what I meant. I meant that you can't say "capture by
> default, but this variable is definitely local".
> >
> > I think if t
On Thu, 25 Mar 2021 at 12:24, Nuno Maduro wrote:
> Hi,
>
> Concerning the comments about what's exactly "auto-captured" by the scope
> of a multi-line short closure, we will be just reusing the "auto-capture"
> feature that already exists in one-line short closures. Therefore, this RFC
> doesn't
If there are no more questions, we plan to open up voting for this on Tuesday
March 30. There will be two votes — a 2/3 majority required for the feature,
and a simple majority required for the name — “noreturn” vs “never”.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
> On Mar 29, 2021, at 1:25 PM, Ilija Tovilo wrote:
>
> Hi Matthew
>
>> Ondřej Mirtes and I present an RFC for the noreturn type:
>> https://wiki.php.net/rfc/noreturn_type
>>
>> The feature already exists in Hack (the primary inspiration) and is
>> currently supported by our static analysis too
Hey everyone!
The vote for adding noreturn is now open:
https://wiki.php.net/rfc/noreturn_type
Voting will run through April 13th
Best wishes,
Matt and Ondrej
On Tue, 30 Mar 2021 at 12:55, Theodore Brown wrote:
> On Tue, Mar 30, 2021 at 10:06 AM Matthew Brown
> wrote:
>
> > Hey everyone!
> >
> > The vote for adding noreturn is now open:
> >
> > https://wiki.php.net/rfc/noreturn_type
> >
> > Voting
On Wed, 31 Mar 2021 at 09:30, Theodore Brown wrote:
> On Tue, Mar 30, 2021 at 5:24 PM Matthew Brown
> wrote:
>
> > On Tue, 30 Mar 2021 at 12:55, Theodore Brown
> wrote:
> >
> > > On Tue, Mar 30, 2021 at 10:06 AM Matthew Brown <
> matthewmatt...@gmail
On Thu, 1 Apr 2021 at 04:56, Benjamin Eberlei wrote:
> This RFC is using the declaration of the return type, to specify that it
> never returns. As such noreturn or never is a keyword a long the lines of
> public or final, but it is not a return type.
>
> I don't think the argument for potential
On Tue, 30 Mar 2021 at 13:51, Ilija Tovilo wrote:
> Hi Matthew
>
> > I like the proposal. I also support the covariance.
> >
> > One question though.
> > The RFC mentions possible future use of "nothing" as a bottom type for
> > parameters in generics. This makes a lot of sense to me. Even withou
On Sat, 3 Apr 2021 at 12:30, Benjamin Eberlei wrote:
>
> But adding a new keyword "noreturn" would not be necessary, it could just
> be an Attribute as i said in my first e-mail explaining my no-vote:
>
> #[NoReturn] // sets a function flag modifying the void behavior
> public function foo(): not
On Sat, 3 Apr 2021 at 22:29, David Rodrigues wrote:
> It is very likely that the proposal will be accepted (it is already 33/10),
>
I'm definitely not counting my chickens.
> Is there any chance of discussing terms, even if the "never" indication is
> winning at the moment? Or did I miss this
contributed comments and suggestions!
Matt and Ondřej
> On Mar 30, 2021, at 11:06 AM, Matthew Brown wrote:
>
>
> Hey everyone!
>
> The vote for adding noreturn is now open:
>
> https://wiki.php.net/rfc/noreturn_type
>
> Voting will run through April 13th
>
> Best wishes,
>
> Matt and Ondrej
> On Apr 24, 2021, at 10:43 AM, Levi Morrison via internals
> wrote:
>
> On Sat, Apr 24, 2021 at 8:04 AM Benjamin Eberlei wrote:
>>
>>> On Sat, Apr 24, 2021 at 2:56 PM Pierre wrote:
>>>
>>> Le 24/04/2021 à 12:55, Saif Eddin Gmati a écrit :
Hello Internals,
I'm sending this
On Sun, 25 Apr 2021 at 16:12, David Rodrigues
wrote:
> I know that this discussion comes back from time to time, but now that PHP
> is quite strong in relation to argument typing, I think it is worthwhile to
> have a quick discussion about it. Maybe to PHP 9.
>
> One of the things I remember that
On Tue, 4 May 2021 at 06:34, Nikita Popov wrote:
> Hi internals,
>
> I'd like to present an RFC for property accessors:
> https://wiki.php.net/rfc/property_accessors
>
> Property accessors are like __get() and __set(), but for a single property.
> They also support read-only properties and proper
On Thu, 20 May 2021 at 10:17, Ondřej Mirtes wrote:
> Hi, I’m confused by the syntax, when I read it, I think to myself “I know
> this, this is just a method call… oh wait, it’s actually a callable”. It
> really makes my head hurt.
>
I agree with the first point — slightly confusing initially, bu
This is a great idea!
Might be worth mentioning that Psalm already supports a `@readonly`
docblock annotation (first suggested by Nuno Maduro), and it matches the
proposed behaviour (though Psalm doesn't currently prevent inheritance
issues):
Example: https://psalm.dev/r/7ed5872738
On Fri, 4 Jun
On Sat, 12 Jun 2021 at 13:00, Craig Francis
wrote:
> Hi Internals,
>
> I'd like to start the discussion on the is_literal() RFC:
>
> https://wiki.php.net/rfc/is_literal
>
> is_literal() brings a proven way to identify Injection Vulnerabilities to
> PHP, already used by Google in their Java and Go
On Mon, 14 Jun 2021 at 08:30, Dan Ackroyd wrote:
> Hi Craig, Joe,
>
> While I think the idea behind this RFC is great, the current
> implementation is terrible, as it will cause some fatal errors in
> production.
>
>
I'm not sure it's productive to call the implementation terrible. With
Someniatk
I've just added support for a `literal-string` type to Psalm:
https://psalm.dev/r/9440908f39
This will remain whether or not the RFC passes, but if it passes the
is_literal check will be used to inform Psalm in a similar fashion to how
array_is_list (coming in 8.1) will inform Psalm's list array t
On Sun, 18 Jul 2021 at 14:47, Tobias Nyholm wrote:
> There has not been many (maybe just one or two) RFCs where I wished the
> vote turned out the other way.
>
This was the reason that I did *not* think that I needed a vote, as a
prolific PHP coder — while individual voters might be voting the "
Hey!
Using the "never" type to require that downstream libs specify a type does
not make intuitive sense to me, because the same is not true the other way
(covariantly) for return types.
The existence of a "never" type on an overriding method does not require
that upstream libs specify a return t
On Thu, 26 Aug 2021 at 21:20, Sara Golemon wrote:
> We're
> going to need to run some static analyzers on some frameworks and
> libraries. Who's got it in them to do the research?
>
> -Sara
>
I'm not volunteering, but I forked Nikita's package analysis to add Psalm
scanning a while ago: https:/
> On Sep 6, 2021, at 11:29 AM, Nikita Popov wrote:
>
I think this would be a massive benefit to first-time PHP users one or two
years from now.
I remember being confused by this terminology — I am sure bugs have been caused
by people who assumed stdClass was a base class for all objects.
B
On Thu, 16 Sept 2021 at 23:33, tyson andre
wrote:
> Yeah, as mentioned in
> https://wiki.php.net/rfc/vector#adding_a_native_type_instead_is_vec , it
> would require a massive amount of work.
>
> - A standard library for dealing with `vec`, filtering it, etc
> - Userland libraries and PECLs would
1 - 100 of 105 matches
Mail list logo
