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
On 19/02/2020 20:21, Paul M. Jones wrote:
Sell it to me! :)
I don't do sales; occasionally I can present a good narrative. Maybe the
narrative below will help.
Hah! Fair enough. :)
- When working out the details, what code should we be picturing using the new
classes?
Not to be flippant
On Wed, Feb 19, 2020, at 1:36 PM, Marco Pivetta wrote:
> On Wed, Feb 19, 2020, 19:51 Larry Garfield wrote:
>
> > On Wed, Feb 19, 2020, at 11:05 AM, Máté Kocsis wrote:
> > > Hi Internals,
> > >
> > > I'd like to move my RFC forward to the discussion phase:
> > > https://wiki.php.net/rfc/write_once
Hi Rowan,
Again, thanks for your time and effort in evaluating this proposal.
> On Feb 18, 2020, at 14:21, Rowan Tommins wrote:
>
> - What's the sales pitch - what do YOU think is great about these classes?
>
> ...
>
> Sell it to me! :)
I don't do sales; occasionally I can present a good na
On Wed, Feb 19, 2020, 19:51 Larry Garfield wrote:
> On Wed, Feb 19, 2020, at 11:05 AM, Máté Kocsis wrote:
> > Hi Internals,
> >
> > I'd like to move my RFC forward to the discussion phase:
> > https://wiki.php.net/rfc/write_once_properties
> >
> > In short, I propose to add support for a new prop
> On Feb 19, 2020, at 2:00 PM, Bishop Bettini wrote:
>
> Consequently, the only way to safely initialize class constants and static
> members is at run-time, and I can only think of one way to do it. Apologies
> if this has already been suggested: taking a cue from C#, a static class
> constru
On Wed, Feb 19, 2020 at 12:58 PM tyson andre
wrote:
> Hi internals,
>
> > I've created a straw poll at
> https://wiki.php.net/rfc/calls_in_constant_expressions_poll , to measure
> interest in allowing calls in different types of constant expressions.
> > If there aren't any problems with the poll
On Wed, Feb 19, 2020, at 11:05 AM, Máté Kocsis wrote:
> Hi Internals,
>
> I'd like to move my RFC forward to the discussion phase:
> https://wiki.php.net/rfc/write_once_properties
>
> In short, I propose to add support for a new property modifier that would
> allow properties to be initialized, b
> On Feb 19, 2020, at 12:27 PM, G. P. B. wrote:
>
> But that's Golang's policy,
The intent was not to present someone else's policy but to instead show prior
art.
> so either we change all error messages to be lower case or we keep it
> consistent with what PHP currently does.
> Moreover, I'm
Hi internals,
> I've created a straw poll at
> https://wiki.php.net/rfc/calls_in_constant_expressions_poll , to measure
> interest in allowing calls in different types of constant expressions.
> If there aren't any problems with the poll structure or rules preventing
> creating a poll, I was go
> On Feb 19, 2020, at 12:35 PM, Rowan Tommins wrote:
>
> Thanks, I can see the reasoning, although I'm not sure I agree with it.
>
> If you're only showing it to a programmer, worrying about the grammar of a
> capital letter after a colon seems needlessly pedantic. If you're showing
> it to end-
Hey Mark,
Asking here as well, so that others are aware: is
`unset($this->aPropertyThatWasNotInitializedBefore)` still working with
this patch?
Also, are the semantics around `__get`, `__set` and `__isset` the same as
with typed properties?
In the RFC, you have `unset($foo->c)` as disallowed: th
On Wed, 19 Feb 2020 at 17:15, Mike Schinkel wrote:
> From https://github.com/golang/go/wiki/CodeReviewComments#error-strings
>
> "Error strings should not be capitalized (unless beginning with proper
> nouns or acronyms) or end with punctuation, since they are usually printed
> following other co
On Wed, 19 Feb 2020 at 18:15, Mike Schinkel wrote:
> > On Feb 19, 2020, at 12:10 PM, Rowan Tommins
> wrote:
> >
> >>> On Wed, Feb 19, 2020 at 4:20 PM David Rodrigues <
> david.pro...@gmail.com>
> >>> wrote:
> >>>
> Maybe you can set all this messages as lowercase? That way we can use
> it
>
> On Feb 19, 2020, at 12:10 PM, Rowan Tommins wrote:
>
>>> On Wed, Feb 19, 2020 at 4:20 PM David Rodrigues
>>> wrote:
>>>
Maybe you can set all this messages as lowercase? That way we can use it
more easily.
>>
>
>
>
>> On Wed, 19 Feb 2020 at 16:50, Mike Schinkel wrote:
>>
>> I
> > On Wed, Feb 19, 2020 at 4:20 PM David Rodrigues
> > wrote:
> >
> >> Maybe you can set all this messages as lowercase? That way we can use it
> >> more easily.
>
> On Wed, 19 Feb 2020 at 16:50, Mike Schinkel wrote:
>
> I am however influenced by Go which specifies that all error messages
>
On Wed, 19 Feb 2020 at 15:05, Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:
>
> Is ++$a behaving differently than $a++ for NULL/FALSE/TRUE?
>
The actual implementation of incrementing and decrementing is the same
whichever operator you use, it's just wrapped in code to return the old
Hi Internals,
I'd like to move my RFC forward to the discussion phase:
https://wiki.php.net/rfc/write_once_properties
In short, I propose to add support for a new property modifier that would
allow properties to be initialized, but not modified afterwards.
Cheers,
Máté Kocsis
> On Feb 19, 2020, at 10:33 AM, Nico Oelgart wrote:
>
> On Wed, Feb 19, 2020 at 4:20 PM David Rodrigues
> wrote:
>
>> Maybe you can set all this messages as lowercase? That way we can use it
>> more easily. If we need the first letter in capital letters we can use
>> `ucfirst()`, because the op
On Wed, 19 Feb 2020 at 16:42, Bishop Bettini wrote:
> On Wed, Feb 19, 2020 at 10:29 AM Craig Francis
> wrote:
>
>> On Wed, 19 Feb 2020 at 05:23, Bishop Bettini wrote:
>>
>>> On Sun, Feb 16, 2020 at 6:24 PM Craig Francis
>>> wrote:
>>>
Just to check, at the moment, if I was an evil hacker,
On Wed, Feb 19, 2020 at 10:29 AM Craig Francis
wrote:
> On Wed, 19 Feb 2020 at 05:23, Bishop Bettini wrote:
>
>> On Sun, Feb 16, 2020 at 6:24 PM Craig Francis
>> wrote:
>>
>>> Just to check, at the moment, if I was an evil hacker, and was to run:
>>>
>>> curl -F 'file=@example.jpg;filename=../.
On Wed, Feb 19, 2020 at 4:20 PM David Rodrigues
wrote:
> Maybe you can set all this messages as lowercase? That way we can use it
> more easily. If we need the first letter in capital letters we can use
> `ucfirst()`, because the opposite is more complicated (a `strtolower()`
> would "break" the
On Wed, 19 Feb 2020 at 05:23, Bishop Bettini wrote:
> On Sun, Feb 16, 2020 at 6:24 PM Craig Francis
> wrote:
>
>> Just to check, at the moment, if I was an evil hacker, and was to run:
>>
>> curl -F 'file=@example.jpg;filename=../../../example.php'
>> https://example.com/upload/
>>
>> The $_FILE
Maybe you can set all this messages as lowercase? That way we can use it
more easily. If we need the first letter in capital letters we can use
`ucfirst()`, because the opposite is more complicated (a `strtolower()`
would "break" the "JIT" message, for example).
Atenciosamente,
David Rodrigues
Le mercredi 19 février 2020, 15:59:24 CET Christian Schneider a écrit :
> Am 19.02.2020 um 15:52 schrieb Côme Chilliet
> :
> > Is there any reason the engine is not running the same code or even
> > compiling to the same opcodes $a++ and $a+=1?
> > If it should never differ, why is it not the sam
Am 19.02.2020 um 15:52 schrieb Côme Chilliet
:
> Le mardi 18 février 2020, 20:27:37 CET Rowan Tommins a écrit :
>> With booleans, there is at least a consistency between those two
>> operators, even though it's consistently weird. There's definitely a
>> strong case for making them match +=1 and
Le mardi 18 février 2020, 20:27:37 CET Rowan Tommins a écrit :
> With booleans, there is at least a consistency between those two
> operators, even though it's consistently weird. There's definitely a
> strong case for making them match +=1 and -=1 though.
Is there any reason the engine is not r
Hi Internals,
I've submitted a small PR proposing a new PCRE function that
returns a human-friendly string representation of the last error.
https://github.com/php/php-src/pull/5185
Currently there's only preg_last_error() which returns error codes,
which isn't really helpful. Most comments in t
Hi all,
Per the past several days of discussion, John Boehr and I have modified the
proposal:
- ServerRequest
- The `$env` property mapping to `$_ENV` has been removed
- The `$requestedWith` property mapping to
`$_SERVER['HTTP_X_REQUESTED_WITH']` has been removed
- The supergloba
29 matches
Mail list logo
