> On May 26, 2021, at 7:44 PM, Hendra Gunawan
> wrote:
>
> Hello.
>
>>
>> Yes, but Nikita wrote this note about technical limitations at the bottom of
>> the repo README:
>>
>> Due to technical limitations, it is not possible to create mutable APIs for
>> primitive types. Modifying $self wit
Out of curiosity,
Couldn't PHP raise an error when there is an uninitialized state left
unhandled after calling the constructor?
It might make the developer think of either providing a default value or
initializing it in the constructor.
Hence no uninitialized state.
On Thu, May 27, 2021, at 8:23 AM, Rowan Tommins wrote:
> The combination of union types and enums actually gives a much more
> expressive way of representing "valid value or explicit null or special
> default". To use the ORM lazy-loading example:
>
>
> enum ORMState {
> case Unloaded;
>
On 27/05/2021 17:13, Andreas Leathley wrote:
How is "uninitialized" magic? It is a state of a class property in PHP
that is currently being exposed via reflection
Apologies if my last message was a bit too hastily written, and may have
come across as rude.
What I meant by it being "magic"
> On May 27, 2021, at 12:05 PM, Rowan Tommins wrote:
>
> On 27/05/2021 16:33, Mike Schinkel wrote:
>> Since the argument against is_initialized() seems to almost universally be
>> that we should not write code that lets type properties be uninitialized
>> past the constructor then it would f
On Thu, May 27, 2021 at 3:55 PM Andreas Leathley wrote:
> Also, is_initialized cannot be done in
> userland, as passing an unitialized property to a function already leads
> to an error
>
The feature request was indeed `is_initialized($foo->bar)` (language
construct, akin to isset); but the PR
On 27.05.21 16:43, Rowan Tommins wrote:
isset in this case is abused to check for uninitialized, hiding the
actual intent
On the contrary, the uninitialized state is what is being abused. If
you want to make the intent clear, use a clear flag of "needs
lazy-loading", or whatever you're actual
On Thu, May 27, 2021 at 9:07 AM Nikita Popov wrote:
> Ah, I think I explained the original issue badly: The test runner output
> isn't really a problem, or at least I never perceived it to be.
>
> The problem is that if you change a test that contains a null byte
> anywhere (read: in var_dump out
On 27/05/2021 16:33, Mike Schinkel wrote:
Since the argument against is_initialized() seems to almost universally be that
we should not write code that lets type properties be uninitialized past the
constructor then it would follow that PHP is in the wrong to even allow
uninitialized state pas
> On May 27, 2021, at 10:43 AM, Rowan Tommins wrote:
>
> On 27/05/2021 14:55, Andreas Leathley wrote:
>>
>> When using isset on a non-nullable property a
>> static analyzer would rightfully complain that the property is not
>> nullable
>
>
> Precisely, so don't mark a property as non-nullable
Thanks for all the input everyone, very successful consensus gathering
exercise.
Since the response was pretty overwhelmingly negative, I think we can just
stop here.
I've closed the PR and wrapped up the FR.
Anyone is of course free to pursue the RFC that would be required, however
ill advised.
On 27/05/2021 14:55, Andreas Leathley wrote:
When using isset on a non-nullable property a
static analyzer would rightfully complain that the property is not
nullable
Precisely, so don't mark a property as non-nullable and then leave it unset.
isset in this case is abused to check for unin
On Thu, May 27, 2021 at 3:54 PM Sara Golemon wrote:
> On Thu, May 27, 2021 at 8:42 AM Nikita Popov wrote:
>
>> The most prudent and BC-safe thing would be to add another function
>>> `var_dump_escaped()` or even to prefer/advise json_encode() when content
>>> safety is relevant, but additional t
On 26.05.21 12:13, Joe Watkins wrote:
Not absolutely convinced that it's a good idea, I asked Nikita to review,
and he's unconvinced also and suggested a discussion should be started.
You can read both of our thoughts about it on the PR.
What I'm looking for now, is reasons that we are wrong -
On Thu, May 27, 2021 at 8:42 AM Nikita Popov wrote:
> The most prudent and BC-safe thing would be to add another function
>> `var_dump_escaped()` or even to prefer/advise json_encode() when content
>> safety is relevant, but additional type information is not (most of the
>> uses of var_dump we h
On Thu, May 27, 2021 at 3:22 PM Sara Golemon wrote:
> On Thu, May 27, 2021 at 5:44 AM Nikita Popov wrote:
>
>> https://github.com/php/php-src/pull/7059 does a surgical change to
>> replace
>> null bytes with \0.
>>
>>
> Before delving into any other observations, I first want to state
> emphatic
On 27/05/2021 13:07, Pierre wrote:
So, if it's going to be used and abused in those magic APIs we all use
daily without thinking about it (let's say, hydrators or serializers,
dependency injection containers and all that stuff, and you do
maintain some if I recall) and unlock some performance o
On Thu, May 27, 2021 at 5:44 AM Nikita Popov wrote:
> https://github.com/php/php-src/pull/7059 does a surgical change to replace
> null bytes with \0.
>
>
Before delving into any other observations, I first want to state
emphatically that we should not ONLY escape chr(0). We either apply full
on
Le 27/05/2021 à 14:18, Michał Marcin Brzuchalski a écrit :
Please take no offense. I just think it's not that common.
While I do work with many integration projects most of the time already
could forget about writing my own stuff for this kind of thing where I have
learned to rely on community-de
czw., 27 maj 2021 o 13:29 Pierre napisał(a):
> Le 26/05/2021 à 21:24, Michał Marcin Brzuchalski a écrit :
> > I don't think nowadays anyone does that without a kind of deserializer
> > which
> > reads the metadata of desired DTO and like Symfony's Serializer or JMS
> > which just deal with such t
Le 27/05/2021 à 13:42, Marco Pivetta a écrit :
On Thu, May 27, 2021 at 1:29 PM Pierre wrote:
why not having it ?
More API, similar-but-not-exactly-like `ReflectionProperty#isInitialized()`
Minimalims should really be valued more :D
I agree and disagree at the same time. I agree because my
On Thu, May 27, 2021 at 1:29 PM Pierre wrote:
> why not having it ?
>
More API, similar-but-not-exactly-like `ReflectionProperty#isInitialized()`
Minimalims should really be valued more :D
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
Le 26/05/2021 à 21:24, Michał Marcin Brzuchalski a écrit :
I don't think nowadays anyone does that without a kind of deserializer
which
reads the metadata of desired DTO and like Symfony's Serializer or JMS
which just deal with such tasks!?
Hello,
Just for your information, we do have our own
Hey,
> whether var_dump() should be performing any escaping at all, and if yes
Well, since var_dump is essentially for debugging purposes, it makes sense
to escape certain characters. Like you mentioned, some IDEs do not
print/support
null bytes. Hence, I am all for it, as it simplifies debugging
Hi internals,
A regular annoyance with our test suite is that var_dump() prints null
bytes literally, those null bytes get into our test expectations, the test
is interpreted as a binary file by git, and diffs will not be shown on
GitHub.
Of course, the null bytes are also confusing to the reader
25 matches
Mail list logo
