On 3/25/2025 4:11 PM, Rowan Tommins [IMSoP] wrote:
Writing coalesce($foo, 0) or ($foo ?? 0) is a small cost when writing the code
to save cost every time anyone reads it.
I see, part of the concern is just avoiding implicit type coercion.
Yes, that would be an understandable reason to requir
wrong choice.
I don't know if I'd go as far as banning a single-argument coalesce, but I
would definitely discourage its use.
The feedback and the thoughtful perspective on user mistakes are
helpful. Thank you again.
-
Robert Chapin
On 3/23/2025 11:10 AM, Larry Garfield wrote:
I'm not sure it justifies a new pseudo-function language construct.
Fair enough. Thank you for the feedback.
On 3/23/2025 2:37 PM, Rowan Tommins [IMSoP] wrote:
It's telling that all your examples with ?? put a value other than
null on the right-ha
($var ??
null) with mandatory extra parentheses. A functional expression could
make this less prone to mistakes. It would also avoid concerns with
alternatives such as unary operators.
Any feedback on this idea would be appreciated.
-
Robert Chapin
Nz. What we can do with an expression like
nullc($test) === 'on' should be compatible with other existing operators
and is more elegant than operators-in-parentheses or any multi-line
statements. This would also resolve the problem of not being able to do
the same in a user function.
Further reading:
https://wiki.php.net/rfc/unary_null_coalescing_operator
-
Robert Chapin
an actual
array of bytes in PHP and trying to work on them).
Robert Landers
Software Engineer
Utrecht NL
On Mon, Aug 12, 2024 at 11:48 AM wrote:
> After reading Rowan's last message, it feels appropriate to link to this:
>
> "The Absolute Minimum Every Software Develop
ed an RFC or language changes and would allow the
development of patterns to the point where adding it to the core
language may be a no-brainer. You (and other users of it) would have a
pretty good idea of which patterns are actually important and useful
due to actually using them.
It's probably the "long way around" but at that point, you'd basically
just be pulling in the extension and discussing syntax as the behavior
would be well-defined and battle-tested.
Robert Landers
Software Engineer
Utrecht NL
On Mon, Jun 24, 2024 at 10:22 PM Bilge wrote:
>
> On 24/06/2024 09:27, Claude Pache wrote:
>
> Hi,
>
> Hi Claude! I really appreciate your feedback. Everything you highlighted is
> an important point that will be included in the RFC!
>
> A general remark: I appreciate that a static class does not
On Mon, Jun 24, 2024 at 7:28 PM Chuck Adams wrote:
>
>
> > On Jun 24, 2024, at 3:31 AM, Robert Landers
> > wrote:
> >
> >
> > There's no need to use `?` to check for existence on a key, so this:
> >
> > $arr is ['a' => string,
On Mon, Jun 24, 2024 at 7:04 AM Hendra Gunawan
wrote:
>
> I agree that this proposal should be proposed as a whole. If we break
> it down into smaller parts, there is a chance some features will not
> pass.
This is exactly my concern and I fear we will be dealing with the
repercussions of a non-w
On Sun, Jun 23, 2024 at 2:19 PM Rowan Tommins [IMSoP]
wrote:
>
>
>
> On 22 June 2024 22:57:24 BST, Robert Landers wrote:
> >In general, you assign the result of the operation so that the output
> >is useful. Here's how that might look in PHP with the C# rules:
>
On Sat, Jun 22, 2024 at 11:57 PM Robert Landers
wrote:
>
> On Sat, Jun 22, 2024 at 10:53 PM Rowan Tommins [IMSoP]
> wrote:
> >
> > On 22/06/2024 19:34, Robert Landers wrote:
> >
> > I've brought this up before, but I mostly see "as" being useful
On Sat, Jun 22, 2024 at 10:53 PM Rowan Tommins [IMSoP]
wrote:
>
> On 22/06/2024 19:34, Robert Landers wrote:
>
> I've brought this up before, but I mostly see "as" being useful for
> static analysis. That's what I've mostly used it for C#, anyway.
> L
On Sat, Jun 22, 2024 at 8:59 PM Arnaud Le Blanc wrote:
>
> On Fri, Jun 21, 2024 at 7:20 PM Robert Landers
> wrote:
> > > > I'm always surprised why arrays can't keep track of their internal
> > > > types. Every time an item is added to the map, just
On Sat, Jun 22, 2024 at 8:34 PM Robert Landers wrote:
>
> On Sat, Jun 22, 2024 at 8:04 PM Rowan Tommins [IMSoP]
> wrote:
> >
> > On 21/06/2024 19:29, Larry Garfield wrote:
> >
> > Valid points. The line between validation and casting is a bit squishy,
>
On Sat, Jun 22, 2024 at 8:04 PM Rowan Tommins [IMSoP]
wrote:
>
> On 21/06/2024 19:29, Larry Garfield wrote:
>
> Valid points. The line between validation and casting is a bit squishy,
> as some casts can be forced (eg, string to int gives 0 sometimes), and
> others just cannot (casting to an obj
On Sat, Jun 22, 2024 at 4:38 AM Gina P. Banyard wrote:
>
> On Friday, 21 June 2024 at 23:58, Robert Landers
> wrote:
> > As a user of PHP, this statement concerns me. I don't want any
> > features rushed just because someone wants it "now" and thus end up
&
pattern matching
(in general) and any passed sub-RFC's.
Maybe that could be a path forward? I don't know who makes the rules,
but they're human rules and they can be anything -- in theory. Maybe
"sub-RFC's" needs an RFC to define it, but that might let you move
faster than a) trying to do everything all-at-once, and b) let
hard-to-define parts of the overall feature get the time they deserve.
>
> --Larry Garfield
Robert Landers
Software Engineer
Utrecht NL
On Fri, Jun 21, 2024 at 6:58 PM Niels Dossche wrote:
>
> On 21/06/2024 14:43, Robert Landers wrote:
> > On Fri, Jun 21, 2024 at 5:08 AM Andreas Hennings
> > wrote:
> >>
> >>> Ilija and I have been working on and off on an RFC for pattern matching
>
On Fri, Jun 21, 2024 at 4:50 PM Rowan Tommins [IMSoP]
wrote:
>
> Le 21/06/2024 à 14:27, Robert Landers a écrit :
>
> This is why I wanted to work on "as" part of the pattern matching. It
> isn't clear what will happen with the actual pattern matching RFC
On Fri, Jun 21, 2024 at 5:49 PM Pierre wrote:
>
> Le 21/06/2024 à 15:57, Robert Landers a écrit :
> > On Fri, Jun 21, 2024 at 3:01 PM Pierre wrote:
> >> Le 21/06/2024 à 14:27, Robert Landers a écrit :
> >>
> >> This is why I wanted to work on "as&
On Fri, Jun 21, 2024 at 3:01 PM Pierre wrote:
>
> Le 21/06/2024 à 14:27, Robert Landers a écrit :
>
> This is why I wanted to work on "as" part of the pattern matching. It
> isn't clear what will happen with the actual pattern matching RFC
On Fri, Jun 21, 2024 at 5:08 AM Andreas Hennings wrote:
>
> > Ilija and I have been working on and off on an RFC for pattern matching
> > since the early work on Enumerations.
>
> I like what I see, a lot!
> One quick thought that came to my mind, regarding objects:
> Could we check method return
bytes into
more useful information (whether that string is human-readable or
not). Sometimes, a PHP extension will do it for you, and sometimes, it
won't, and you have to do it yourself. Doing it yourself is usually
where you don't want strict types (if you trust coercion to behave as
do
sk an out-of-context reply, but FWIW, it goes both
ways :) People get irrational about this topic, either for-or-against.
In any case, there is not any "type safety" in PHP because PHP doesn't
know something is the wrong type until runtime. Further, it clearly
doesn't stop bugs, otherwise we'd all be out of a job by now.
Robert Landers
Software Engineer
Utrecht NL
On Tue, Jun 18, 2024 at 11:04 PM David Gebler wrote:
>
> On Tue, 18 Jun 2024, 17:40 Robert Landers, wrote:
>>
>> Hello internals,
>>
>> Many, many people start their files fairly religiously:
>>
>> >
>> and I say "religiously" becau
On Tue, Jun 18, 2024 at 10:46 PM Rowan Tommins [IMSoP]
wrote:
>
> On 18/06/2024 17:37, Robert Landers wrote:
>
> One thing is clear is that "strict types" may be a bit of poor word
> choice and gives people a false sense of security that it is "safe" or
> &q
the right ones (even if it is years
later) can sometimes be completely worth it and even have monetary
gains.
>
> Moreover, there are many places where it is not possible to add such a
> declaration. For instance, `array_map(...)`, etc., always use
> `strict_types=0` when invoking the callback. Changing that would also be a
> big BC break.
>
> —Claude
Robert Landers
Software Engineer
Utrecht NL
Hello internals,
Many, many people start their files fairly religiously:
should work, since MyClass != myclass anymore. And serialization works
> > perfectly with class aliases, see https://3v4l.org/1n1as .
> >
> > --
> > Valentin Udaltsov
> >
Hey Rokas,
Please bottom post (it's the rules), but PHP's "decline" has
lement the methods. It would be much simpler to implement magic
methods that can intercept the method calls and not worry about
generating an entire class every time a dev wants to use this
functionality.
In my case, none of the complexity actually goes away since I still
need to generate concrete types of the correct type. That being said,
I don't exactly have millions of users so if I still need to manually
create this, I will. I just thought I'd toss out the idea of not
needing an object of the correct type, just one that can handle the
expected behavior.
Robert Landers
Software Engineer
Utrecht NL
use it doesn't actually use lazy
> objects and thus I don't understand if Manager, Dispatcher, or both are
> intended to be lazily initialized. It would help to rewrite the example
> to use `makeLazyGhost()` and indicate with a comment in which cases the
> problem would arise.
>
> - Backward Incompatible Changes
>
> There a technicality: The `ReflectionLazyObject` class name will no
> longer be available to userland.
>
> Best regards
> Tim Düsterhus
As someone who has had to maintain these proxies/ghosts before, this
looks quite useful and powerful. I feel it has rather wonky syntax,
but it is clearly better than the alternative of implementing it
yourself. I'm also a huge fan that the syntax allows for
usage/creation far and away from the definition/class itself.
Good luck, and I hope it passes.
Robert Landers
Software Engineer
Utrecht NL
y intended semantics of readonly, but in a
> compatible and acceptable way?
>
> —Claude
>
>
I know this doesn't really contribute to the conversation ... but if I
could ever mash a +1 on a single email, this is the email I'd choose.
"Best elegant solution that happens to delete readonly without
deleting readonly" award.
Robert Landers
Software Engineer
Utrecht NL
On Wed, May 22, 2024 at 4:13 AM Larry Garfield wrote:
>
> On Tue, May 21, 2024, at 6:47 PM, Bilge wrote:
> > On 22/05/2024 00:31, Larry Garfield wrote:
> >> I could see an argument for auto-populating the backing value off the enum
> >> name if it's not specified, something like this: enum Option
On Mon, May 20, 2024 at 6:58 PM Larry Garfield wrote:
>
> On Sat, May 18, 2024, at 6:15 PM, Robert Landers wrote:
>
> >> I think an important question to answer here is what we want to have as
> >> our definition of "package".
> >>
> >> 1
antity: {quantity}, Discount: {discount:P1},
Total after discount: {(price * quantity * (1 - discount)):N2}"
Price is formatted using currency with 2 decimal places, discount is
formatted using percentage and one decimal, and N is a number format
with 2 decimals.
Robert Landers
Software Engineer
Utrecht NL
On Sun, May 19, 2024 at 10:52 AM Andreas Heigl wrote:
>
> Hey Robert.
>
> Am 19.05.24 um 09:38 schrieb Robert Landers:
> > On Sat, May 18, 2024 at 9:11 PM Andreas Heigl wrote:
> >>
> >>
> >>
> >> Am 18.05.24 um 19:46 schrieb Robert Lander
On Sat, May 18, 2024 at 10:33 PM Barney Laurance
wrote:
>
> On 18/05/2024 15:00, Robert Landers wrote:
> > Hello internals,
> >
> > I've been thinking about having an "internal" attribute that will emit
> > a warning if called from outside it'
On Sat, May 18, 2024 at 9:11 PM Andreas Heigl wrote:
>
>
>
> Am 18.05.24 um 19:46 schrieb Robert Landers:
> > On Sat, May 18, 2024 at 7:38 PM Andreas Heigl wrote:
> >>
> >> Hey all.
> >>
> >> Am 18.05.24 um 16:00 schrieb Robert Landers:
>
On Sat, May 18, 2024 at 7:58 PM Larry Garfield wrote:
>
> On Sat, May 18, 2024, at 11:06 AM, Andreas Heigl wrote:
> > Hey all.
> >
> > Am 18.05.24 um 16:00 schrieb Robert Landers:
> >> Hello internals,
> >>
> >> I've been thinking about havi
On Sat, May 18, 2024 at 7:38 PM Andreas Heigl wrote:
>
> Hey all.
>
> Am 18.05.24 um 16:00 schrieb Robert Landers:
> > Hello internals,
> >
> > I've been thinking about having an "internal" attribute that will emit
> > a warning if called from
On Sat, May 18, 2024 at 5:18 PM Rowan Tommins [IMSoP]
wrote:
>
> On 18/05/2024 15:00, Robert Landers wrote:
>
> I've been thinking about having an "internal" attribute that will emit
> a warning if called from outside it's left-most namespace.
>
>
>
they are using code that
may be changed without any notice.
Any thoughts?
Robert Landers
Software Engineer
Utrecht NL
On Sat, May 18, 2024 at 12:52 PM Luigi Cardamone
wrote:
>
> Thank you for your feedback.
>
> I am already using a solution like the one
> proposed by Robert: it works but it
> leaves some doubts since each project
> can have a different name for NotSet
> while it seems
public NotSet|null|string $aValue = NotSet;
}
This way, even programmers can "unset" a property by simply setting
$value->aValue = NotSet without having to rely on the weird PHP
semantics of unsetting a property. You can also use this to
declaratively encode which properties cannot be unset, without having
to define it in your mapping code.
Robert Landers
Software Engineer
Utrecht NL
ock is adjusted.
The problem might actually be using ITIMER_PROF, which "Measures CPU
time used by the process, including both user space and kernel space"
and usage of sockets/threads might give an "accelerated" value while
maybe ITIMER_VIRTUAL is the one we should be using since it "Measures
CPU time used by the process (user space)" which won't count kernel
timings.
Robert Landers
Software Engineer
Utrecht NL
> Moreover, PHP already has a 1-indexed and 0-indexed discrepancy with the
> ob_get_level() and ob_get_status() functions.
>
> In the end, I don't really care what we choose, but this just needed
> clarification from internals on how to proceed.
>
> Best regards,
>
> G
, we access memory
from the start (0), but as humans, we count total items. You never say I
have zero goats and really mean that you have one goat. However, if you
wanted to start at the beginning of a line of goats, you'd start at
position zero to get the first goat.
Robert Landers
Software Engineer
Utrecht NL
a Closure object.
>
> There may be other parts I've not mentioned, but hopefully this illustrates
> the idea that "a native decimal type" doesn't have to be one all-or-nothing
> project.
>
> Regards,
> Rowan Tommins
> [IMSoP]
I'm not so sure this could be implemented as an extension, there just
isn't the right hooks for it.
Robert Landers
Software Engineer
Utrecht NL
ial and
> privileged information. Any unauthorized review, use, disclosure, or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message.
>
Heh, that's pretty cool that ht
ks in a codebase with hundreds of *\Mapper
classes, I feel your pain. However, 99% of the time, people are going
to be using a single database implementation at a time per
file/context. If you do find yourself in an edge case where you have
multiple database implementations in the same file, aliases work for
that case.
Robert Landers
Software Engineer
Utrecht NL
;> >
>> >
>> >
>> > For more details see the RFC:
>> > https://wiki.php.net/rfc/new_without_parentheses
>> >
>> > Implementation: https://github.com/php/php-src/pull/13029
>>
>> I always thought there was some technical parser reason why this wasn't
>> possible. Maybe that was true in 5.x but isn't anymore?
>>
>> I cannot speak to the implementation, but I'm all for the change itself.
>>
>> --Larry Garfield
>
>
> Does anyone have additional feedback? I'd like to start voting on Thursday,
> April 25th.
> I've also added a section on other syntax ideas that have been expressed on
> Twitter and in the PR:
> https://wiki.php.net/rfc/new_without_parentheses#other_syntax_ideas
> --
> Valentin
I suspect this will break (badly written) reflection in interesting ways:
https://3v4l.org/mcSNH
This basically breaks dereferencing order of operations and makes it
inconsistent.
Robert Landers
Software Engineer
Utrecht NL
think?
Robert Landers
Software Engineer
Utrecht NL
silently vote no than to be attacked simply for providing a
> dissenting opinion at an inconvenient time.
>
> - Mark
Hey Mark,
I think that is fair, but I'd also point out that RFCs have been
rejected in the past simply because voters felt it was "too last
minute" before a release. I don't think it's fair to decline RFCs for
being too last minute, but when the inverse happens to an RFC: a huge
dissenting opinion at the last second, call foul.
Largely, I agree with you but it's worth pointing out the incongruity here.
Robert Landers
Software Engineer
Utrecht NL
User` line.
As someone who has spent a number of years writing C#, the RFC looks
quite sane. I do agree that it does quite a lot in one go though. If
you look at how fields were introduced into C#, the "short syntax"
version didn't come along until years after the long version and
p
f passing the RFC, but needs-more-work
just means there is more to do (either addressing ugly syntax or the
idea is sound, but as it says, it needs more work), and can thus be
simply revoted on after concerns are addressed -- instead of creating
a whole new RFC that needs to pass the "not too similar to other RFCs
rule."
I got the impression from the Aviz discussions that most people were
against Aviz due to the syntax, not the feature itself. It would be
absolutely tragic if this failed to pass simply because people
expected Aviz here.
Robert Landers
Software Engineer
Utrecht NL
src/pull/13800
>
> Let me know what you think. I will start working on an RFC draft once
> work on property hooks concludes.
>
> Ilija
Neat! I've been playing around with "value-like" objects for awhile now:
https://github.com/withinboredom/time
Having inheritance supported would be useful, for example, consider an ID type:
data class Id {
public function __construct(public string $id) {}
}
Maybe you want to extend it to a UserId:
data class UserId extends Id {}
Now you can't accidentally pass a VideoId as a UserId, but underlying
ORMs can still use both as an Id.
Robert Landers
Software Engineer
Utrecht NL
On Mon, Apr 1, 2024 at 1:53 AM Ben Ramsey wrote:
>
> > On Mar 31, 2024, at 11:08, Robert Landers wrote:
> >
> > There are probably multiple parties that require trust: the people
> > hosting the CI servers, the people with access to the CI servers, the
> > RM,
On Sun, Mar 31, 2024 at 5:26 PM Christian Schneider
wrote:
>
> Am 30.03.2024 um 16:35 schrieb Daniil Gentili :
> >> That would break lots of tools as it requires extra dependencies so it is
> >> not something that would could in stable versions.
> > Btw, I do not believe that "it would require en
On Sat, Mar 30, 2024 at 1:06 AM 하늘아부지 wrote:
>
>
>
> 2024년 3월 30일 (토) 오전 2:15, Robert Landers 님이 작성:
>>
>> On Fri, Mar 29, 2024 at 3:41 AM 하늘아부지 wrote:
>> >
>> > Hello.
>> >
>> > I created a wiki for __callStatic re
o __callStatic() to instance methods. I don't think it makes
sense to have one without the other, and then what you want with
__callStatic() comes naturally, instead of this weird and confusing
RFC.
Robert Landers
Software Engineer
Utrecht NL
On Fri, Mar 22, 2024 at 8:02 PM Rowan Tommins [IMSoP]
wrote:
>
> On Fri, 22 Mar 2024, at 17:38, Claude Pache wrote:
>
>
> Le 22 mars 2024 à 16:18, Rowan Tommins [IMSoP] a écrit
> :
>
> $optionalExpiryDateTime = $expiry as ?DateTimeInterface else
> some_other_function($expiry);
> assert($optiona
On Fri, Mar 22, 2024 at 5:51 PM Rowan Tommins [IMSoP]
wrote:
>
> On Fri, 22 Mar 2024, at 12:58, Robert Landers wrote:
> >
> >> $optionalExpiryDateTime = $expiry as ?DateTimeInterface else new
> >> DateTimeImmutable($expiry);
> > I&
and handle the case for when $expiry
isn't a string:
$optionalExpiryDateTime = $expiry == null ? $expiry : $expiry as
DateTimeInterface ?? new DateTimeImmutable($expiry as string ?? "now")
But I can't think of why you'd want null ... null would apply to all
types and have a dedicated branch, no matter what any other type is.
Robert Landers
Software Engineer
Utrecht NL
On Fri, Mar 22, 2024 at 10:31 AM Jordi Boggiano wrote:
>
> On 2024-03-21 16:02, Robert Landers wrote:
>
> $a as int|float
>
> would be an int, float, or thrown exception.
>
> $a as int|float|null
>
> would be an int, float, or null.
>
> Just a suggestion h
On Thu, Mar 21, 2024 at 11:06 PM Rowan Tommins [IMSoP]
wrote:
>
> On 21/03/2024 19:03, Robert Landers wrote:
>
> I suppose we are taking this from different viewpoints, yours appears
> to be more of a philosophical one, whereas mine is more of a practical
> one.
>
&
On Thu, Mar 21, 2024 at 7:01 PM Rowan Tommins [IMSoP]
wrote:
>
> On 21/03/2024 15:02, Robert Landers wrote:
>
> I don't think you are getting what I am saying.
>
> $a as int|float
>
> would be an int, float, or thrown exception.
>
> $a as int|float|null
On Thu, Mar 21, 2024 at 5:15 PM Larry Garfield wrote:
>
> On Thu, Mar 21, 2024, at 9:10 AM, Robert Landers wrote:
> > Hello,
> >
> > I'm a bit confused on inheritance. In the following example of a
> > proxy, do I need to be aware of a parent's hook and han
On Thu, Mar 21, 2024 at 12:45 PM Rowan Tommins [IMSoP]
wrote:
>
> On 20/03/2024 23:05, Robert Landers wrote:
>
> In other
> words, I can't think of a case where you'd actually want a Type|null
> and you wouldn't have to check for null anyway.
>
>
> It&
On Thu, Mar 21, 2024 at 12:45 PM Rowan Tommins [IMSoP]
wrote:
>
> On 20/03/2024 23:05, Robert Landers wrote:
>
> In other
> words, I can't think of a case where you'd actually want a Type|null
> and you wouldn't have to check for null anyway.
>
>
> It&
: moves it to the set hook)? Will my proxy now cause an error?
Would simply calling $this->name call the parents hook?
Robert Landers
Software Engineer
Utrecht NL
On Wed, Mar 20, 2024 at 8:30 PM Rowan Tommins [IMSoP]
wrote:
>
>
>
> On 20 March 2024 12:51:15 GMT, Robert Landers
> wrote:
>
> >Oh and there isn't any difference between:
> >
> >$x as ?Type
> >
> >or
> >
> >$x as Type|null
On Wed, Mar 20, 2024 at 1:47 PM Robert Landers wrote:
>
> On Tue, Mar 19, 2024 at 10:06 PM Rowan Tommins [IMSoP]
> wrote:
> >
> > On 19/03/2024 16:24, Robert Landers wrote:
> >
> > $x = $attributeReflection->newInstance() as ?MyAttribute;
> > if ($x ===
On Tue, Mar 19, 2024 at 10:06 PM Rowan Tommins [IMSoP]
wrote:
>
> On 19/03/2024 16:24, Robert Landers wrote:
>
> $x = $attributeReflection->newInstance() as ?MyAttribute;
> if ($x === null) // do something since the attribute isn't MyAttribute
>
>
> I think reusing
cludes null),
or an error to be thrown.
Note that this isn't casting from one type to another, but asserting
that this type is the type you expect. It'd significantly help with
static analysis, IDE code completion, etc.
What do you think?
Robert Landers
Software Engineer
Utrecht NL
ding flag would be really useful for
those of us having to transform a base64 encoded string to a url-base64.
Robert Landers
Software Engineer
Utrecht NL
ght
> take a while to migrate all those to RST. It would be also perhaps
> smart to sync this initiative with https://github.com/php/php-langspec
> somehow or at least to display all of those together in some GH page.
Personally, the documentation is part of the code it documents,
otherwise, you don't have documentation, you have content that can be
mistaken for documentation.
Robert Landers
Software Engineer
Utrecht NL
specify a type (which may be
> > wider). So these are equivalent:
> >
> > public int $foo { set (int $value) => $value + 1 }
> > public int $foo { set => $value + 1 }
> >
> > And only those forms are legal. But you could also do this, if the
> > situation called for it:
> >
> > public int $foo { set(int|float $num) => floor($num) + 1; }
> >
> > This "all or nothing" approach seems like it strikes the best balance,
> > gives the most flexibility where needed while still having the least
> > redundancy when not needed, and when a name/type is provided, its behavior
> > is the same as for a method being inherited.
> >
> > Does that sound acceptable? (Again, question for everyone.)
> >
>
> My only question with this is the same as I had in an earlier reply (and I'm
> not sure it was ever answered directly?), and you allude to this yourself:
> everywhere *else*, `($var)` means a parameter with type `mixed`. Why is the
> type *required* here, when you've specifically said you want to avoid
> boilerplate? If we're going to assume people can understand that `(implicit
> property-type $value) is implicit, surely we can also assume that they will
> understand "specifying a parameter without a type" means the parameter has no
> type (i.e. is `mixed`).
>
> Again, for myself I'd be likely to type it (or regular parameters,
> properties, etc) as `mixed` if that's what I want *anyway*, but the
> inconsistency here seems odd, unless there's some until-now unknown drive to
> deprecate type-less parameters/properties/etc.
>
>
> > The alternative that gives the most future-flexibility is to do neither:
> > The variable is called $value, period, you can't change it, and you can't
> > change the type, either. There is no () after set, ever. Punt both of
> > those to a later follow-up. I'd prefer to include both now, but including
> > neither now is the next-safer option.
> >
> >
> > ## Regarding $field
> >
> > Sigh, now y'all like it. :-P Most of the feedback on this has been
> > negative, so I'm inclined to leave it out at this point, unless there's a
> > major swing in feedback to bring it back. But the RFC seems more likely to
> > pass without it than with right now.
> >
> > --Larry Garfield
> >
>
>
> Cheers
>
>
> Stephen
I would think that simply using return-to-set would be the simplest
solution, if you need to run something after it's set, you can use the
regular way of running code after a return:
try {
return $value + 100;
} finally {
// this runs after returning
}
Robert Landers
Software Engineer
Utrecht NL
-- Forwarded message -
From: Robert Landers
Date: Sat, Feb 24, 2024 at 9:20 AM
Subject: History of traits + inheritance
To: internals
I'm asking for a history lesson if anyone knows, as I couldn't find
any relevant information in externals and it appears to have bee
ve no idea why gmail
soft-bounced the messages, maybe rate-limiting?).
If I'm using gmail and not getting emails, how many other people are
also not getting emails on this list?
Robert Landers
Software Engineer
Utrecht NL
On Wed, Feb 21, 2024 at 7:59 PM Larry Garfield wrote:
>
> Hello again, fine Internalians.
>
> After much on-again/off-again work, Ilija and I are back with a more polished
> property access hooks/interface properties RFC. It’s 99% unchanged from last
> summer; the PR is now essentially complete
On Thu, Feb 22, 2024 at 1:03 AM Pierre wrote:
>
> Le 21/02/2024 à 19:55, Larry Garfield a écrit :
> > Hello again, fine Internalians.
> >
> > After much on-again/off-again work, Ilija and I are back with a more
> > polished property access hooks/interface properties RFC. It’s 99%
> > unchanged
know the name says "array" but often we
just mean "do this operation on this thing that looks enough like an
array for now."
Robert Landers
Software Engineer
Utrecht NL
(at some point,
though I didn't see anything), but what are your thoughts? Is this
something that even makes sense? I'll admit, I've never tried casting
to null before, but I had assumed it would "just work" and was
slightly surprised that it didn't.
Robert Landers
S
you can spot it but also believe this
> goes too far.
>
> All above already goes far beyond what you initially asked and I know that.
> I just like to share what can find.
>
> Cheers,
> Michał Marcin Brzuchalski
If I recall correctly, there is also a `\0` (null character) hidi
w a TypeError if you call it with strings (at least in strict
mode, in non-strict mode, it will be coerced to a number if a numeric
string), as it should. You shouldn't even have to catch this because
it should be caught in development, and in production, it very much
should crash.
For larger
f course, if code should start to return null/null-object as result - you
> have to implement that (refactoring the places where null is inapplicable),
> but error collection itself won't change existing code then, it works like an
> observer pattern now.
>
> ср, 7 февр.
ist
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Oh wow, this conversation got really interesting while I was asleep :D
I think this could actually be interesting in a
semi-backwards-compatible way, by just adding some syntax sugar:
function getResult(): ?Result, ?ResultError {
if($error) return null, $error;
}
instead of, but this would still work when destructuring:
function getResult(): array {
if($error) return [null, $error);
}
This would still work (the "backwards compatible" part):
[$result, $error] = getResult();
or this:
$result, $error = getResult();
Essentially, return types with a comma are just a "strongly typed
array" and a comma on the left-hand side of assignment is just a
destructure.
Robert Landers
Software Engineer
Utrecht NL
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
he error bag by nesting sequence, or by tag, or
> > by
> > > >>> error type. Error type helps the same as try/catch, tag helps if you
> > want
> > > >>> to save errors to several destinations without memory losses, and
> > nesting
> > >
You could write
while(true) {
...
$arr['var'] ?? continue;
$something ? continue : break;
...
}
Robert Landers
Software Engineer
Utrecht NL
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
a
few people will like (and would make it much more usable in static
contexts, like attributes).
I'm still not fully settled on the syntax, and this is still very much
a work in progress. So, I'd love feedback in that regard.
Robert Landers
Software Engineer
Utrecht NL
--
PHP Internal
On Fri, Jan 5, 2024 at 11:59 AM Rowan Tommins wrote:
>
> On 5 January 2024 09:02:05 GMT, Robert Landers
> wrote:
> > I don't think they are fundamentally incompatible. If we look at
> >FrankenPHP's implementation, you pass a callback that gets called when
> >
On Fri, Jan 5, 2024 at 8:47 AM Rowan Tommins wrote:
>
> On 5 January 2024 06:55:34 GMT, Robert Landers
> wrote:
>
> >I already said this, but to reiterate: I, personally, hear what you
> >are saying and largely agree with you; however, before we can really
> >
st objects. There are no such things as event
loops. There are fibers, but absolutely no std-library i/o functions
are using them, making it pointless to build on fibers except when
using user-land libraries that reimplemented everything (like amphp)
in pure PHP or an extension like swoole.
That i
r any building blocks needed to serve concurrent requests. It's
been made possible through extensions and libraries that aren't
maintained by PHP, so I'm not sure how we'd support them directly
without those other basic functionalities. If we directly wanted to
support concu
ort worker mode primitives if there were request
objects... so, it might make sense to build a v1 of the worker mode
primitives and then iterate towards request objects, because then
there would be an actual need for them.
Robert Landers
Software Engineer
Utrecht NL
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi Niels,
> They are indeed going to be very similar, but at least having better return
> types would be good to give one particular example.
> e.g. we currently have a lot of methods that can return an object or false.
> The current living DOM spec always throws exceptions instead of returning
On Thu, Dec 28, 2023 at 7:46 PM Niels Dossche wrote:
>
> Hi
>
> On 28/12/2023 19:36, Robert Landers wrote:
> > Hello internals,
> >
> > I sent an email to secur...@php.net (which I got from this page:
> > https://wiki.php.net/security#:~:text=Please%20report%2
s attached below.
For further assistance, please send mail to postmaster.
And then proceeded to list (possibly) every email address in the list.
I suspect this isn't supposed to happen?
Robert Landers
Software Engineer
Utrecht NL
--
PHP Internals - PHP Runtime Development Mailing List
To uns
nt classes (e.g.
> MyHTMLScriptElement etc).
> I'd like to hear from more people on this matter.
Custom element classes would be really nice! I ended up having to
write a custom html5 parser in pure php due to the shortcomings of
php's extension. Having the ability to create custom
1 - 100 of 863 matches
Mail list logo