On Tue, Oct 20, 2020, at 1:19 PM, Larry Garfield wrote:
> A while back, Nikita mentioned that it should now be easy to offer an
> abbreviated syntax for functions that are just a single expression. I
> decided to take a crack at it and it turns out he was right. I thus
> of
and only some projects adopt it. Basically, a mess.
Whatever we do, it should be language-consistent so that there's no bikeshed
potential.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
flame retardant suit*
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e string $lastName,
) {}
public function getId(): int => $this->id;
public function getUserName(): string => $this->username;
public function getRole(): string => $this->role;
public function getFullName(): string => sprintf(%s %s', $this->firstName,
$this->l
nce that if the RFC passes the code will actually get completed by the
people that proposed it, rather than just expecting someone else to magically
do it for them.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ove and go with the result.
@@ may be easier to type than the others, but at the end of the day the parsing
problems it introduces seem like the killer blow to me.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Sun, Jul 26, 2020, at 11:24 AM, Larry Garfield wrote:
> The vote on the PHP namespace policy is now open:
>
> https://wiki.php.net/rfc/php_namespace_policy
>
> Usual rules, 2/3 required for passage. Vote will be open until 9 August.
The vote has been closed. Final results:
r the use cases i can foresee it's not actually
relevant.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
parate syntax.
I mention it here mostly for transparency and to make sure we don't end up with
multiple competing RFCs that duplicate functionality needlessly.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, Jul 7, 2020, at 4:22 PM, Miguel Rosales wrote:
> Larry Garfield wrote on 07/07/2020 16:46:
> > This has reached the 2 week mark, but there's not been much discussion.
> > Anyone else want to weigh in?
> >
>
> I guess I'm missing something obvious here,
On Thu, Jul 9, 2020, at 6:55 AM, Rowan Tommins wrote:
> On Thu, 9 Jul 2020 at 09:58, Dan Ackroyd wrote:
>
> > On Tue, 7 Jul 2020 at 15:47, Larry Garfield
> > wrote:
> > >
> > > This has reached the 2 week mark, but there's not been much discussion.
> &g
we could all agree to do so.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ple of what kind the language might look like when
> several such features are potentially accepted in the future.
>
> May I propose that some of us interested in this do a short call over the
> summer on this topic to see if we can align on direction?
I'm open to that. Explicit design
On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote:
> Greetings, Internalians.
>
> There has been much talk of the \PHP namespace of late, including one
> unsuccessful RFC. In the discussion, the pushback broke down into two
> main camps:
>
> * We should never na
On Fri, Jul 10, 2020, at 3:54 AM, Nikita Popov wrote:
> On Tue, Jul 7, 2020 at 4:47 PM Larry Garfield
> wrote:
>
> > On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote:
> > > Greetings, Internalians.
> > >
> > > There has been much talk of
alsifiable also. "
What's that about?
"(Including __construct() replacing old style constructors in PHP 7.)" -
__construct replaced old-style constructors in PHP 5. :-)
I think the truth tables have a formatting error; check the last line that goes
wider than the rest. Also, watch out for "smart quotes" in the string parts.
Also, YAY summary tables!
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
null) but also has
default values in it for the base case. A user object likely wouldn't use
that, but a value object like an Address very well could.
Until we can support for-reals monads (which would require enums and generics
to do properly; the former is possible the latter is very hard), it
On Wed, Jul 15, 2020, at 11:43 AM, Marco Pivetta wrote:
> Hey Larry,
>
> On Wed, Jul 15, 2020 at 5:32 PM Larry Garfield
> wrote:
>
> > 1) return null, which is a non-type, and thus you need to make the return
> > type ?User or User|null, which means the call
On Wed, Jul 15, 2020, at 11:59 AM, Marco Pivetta wrote:
> Hey Larry,
> <http://ocramius.github.com/>
>
>
> On Wed, Jul 15, 2020 at 6:55 PM Larry Garfield
> wrote:
>
> > I disagree entirely. The value of a Maybe over just null is
> >
> > 1) Y
oo');
Same statement: Seems logical, although why anyone is still using
call_user_func() I don't know. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
use Markdown. It uses some
wonky proprietary ancient mess instead. Now that you have Wiki access you
should probably start using the PHP Wiki instead of Github so that you don't
have to convert a mess of nice formatting from Markdown to PHPWiki-down.
I like this idea and wish I had the s
hink probably acceptable.
So, I think I'd favor get:X set:Y as modifiers, with the assumption that
1) Should accessors ever happen they'd be expected to NOT duplicate the
visibility, either with the option above or something similar.
2) isset and unset can be skipped for now but the RFC can explicitly state that
should they ever be needed, they'd be added in the same way.
Here endeth my analysis. Thanks again, Andre!
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
properties of by-val objects
cannot be by-ref objects or resources, which seems reasonable to me.
I think that would do a far better job of addressing the shared-mutable-state
issue than reference counting, because it attacks the root problem rather than
a symptom.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
free to steal the user-repo example if you
want.
I have no strong feelings about interface vs. magic method, that's an old race
I don't have a horse in.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Sat, Jul 11, 2020, at 4:04 PM, Olle Härstedt wrote:
> > I think that would do a far better job of addressing the
> > shared-mutable-state issue than reference counting, because it attacks the
> > root problem rather than a symptom.
> >
> > --Larry Garfield
>
n color as a
justification. All of Europe being "white" is just as made-up as all of Africa
being "black."
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
equality in the world. get your butt out to a
Black Lives Matter march, write your legislator, join a reform group, work on
hiring practices in your own company, or do something else that requires actual
work. That goes for everyone.
5) Acknowledge that there are very likely a lot of people
orge P. Banyard
This seems reasonable, but the RFC text should be updated. It still says it's
targeting 7.4. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Wed, Jun 24, 2020, at 2:32 PM, Rowan Tommins wrote:
> On 24/06/2020 01:30, Larry Garfield wrote:
> > * We should never namespace anything ever.
> > * We can namespace things but we need something more concrete than "RFCs
> > can namespace things if they feel like it
th for documentation and
for consistency.
I am in favor of this RFC for that reason.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
any such transitions to minimize
disruption.
The intent is to bring this proposal to a vote in time for 8.0's freeze one way
or another, even though it's unlikely to have any impact on 8.0 itself. It's
still a convenient deadline.
*dons flame retardant suit*
--
Larry Garfield
la...@garfi
gut feeling is that @@ is notably worse inline. It subjectively feels
messier because there's no clear indication of where the end is. On separate
lines, @@ and << >> seem about equally ugly to me.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
doesn't render docblocks redundant, it renders "using docblocks for custom
metaprogramming" redundant, which was always a fugly hack to begin with.
A type system improvement for "this parameter must be a positive integer less
than 50" would be super nice, I agree, but is in no way related to the topic at
hand at all.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
. Thank you for your interest in PHP.
I generally agree with the issues of combining subtype and uses-code-from into
a single operation; PHP already has a solution to that, though: Traits. It's
not exactly the same as what you describe, but it's close enough for most cases.
cf: https://www.garfieldtech.com/blog/beyond-abstract
That aside, a change of that scale couldn't happen in PHP 8 at this point.
Feature freeze is in less than 2 months and even just figuring out how to
implement such a change would take longer than that, even assuming universal
buy in.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
officially reserving and using PHP (and/or Ext) as the "core vendor," and then
following existing conventions. Everything else is already the standard
practice across the ecosystem, just said in more formal words with some
collaboration processes defined.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
The vote on the PHP namespace policy is now open:
https://wiki.php.net/rfc/php_namespace_policy
Usual rules, 2/3 required for passage. Vote will be open until 9 August.
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
c to add a number of attribute
classes, which would logically have very generic seeming names. Getting those
out of the global namespace and into a logical organization would be very good.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
are already claimed.
https://wiki.php.net/rfc/php_namespace_policy
This is probably (I hope) the final edit of consequence before voting. Speak
now or forever hold your peace. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net
On Mon, Jan 11, 2021, at 2:27 PM, Ben Ramsey wrote:
> > On Jan 10, 2021, at 20:09, Larry Garfield wrote:
> >
> > On Sun, Jan 10, 2021, at 4:40 PM, Mark Randall wrote:
> >> On 10/01/2021 21:27, Larry Garfield wrote:
> >>> The "a method that begi
On Tue, Dec 29, 2020, at 2:26 AM, Marc wrote:
>
> On 28.12.20 21:23, Larry Garfield wrote:
> > There's been a number of discussions of late around property visibility and
> > how to make objects more immutable. Since it seems to have been
> > well-received in t
On Tue, Dec 29, 2020, at 2:48 AM, Marc wrote:
>
> On 28.12.20 21:21, Larry Garfield wrote:
> > Hello, Internalians!
> >
> > After considerable discussion and effort, Ilija and I are ready to offer
> > you round 2 on enumerations. This is in the spirit of the previ
lieve it is
> time to drop this limitation for arrays as well.
>
> Regards,
> Nikita
Hard yes. I ran into a case just yesterday (while doing some sample code for
immutability) when I wanted to merge associative arrays this way and the
alternate was much yuckier.
--Larry Garfield
-
r enums have a ton of value unto themselves.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
I'll make a note in the RFC that they must be unique.
> *Enum & UnitEnum interfaces*
>
> The implementation does not seem to support these yet. Taking the examples
> from the RFC:
>
> Suit::Hearts instanceof Enum; // true => Parse error: syntax error,
> unexpected tok
On Mon, Dec 7, 2020, at 9:56 AM, Rowan Tommins wrote:
> On 07/12/2020 15:26, Larry Garfield wrote:
> > Assuming it's feasible to do, what do people feel about supporting that?
> > IMO, cases(), from(), and values() need to be kept no matter what as
> > they're more sel
Ilija question.
Assuming it's feasible to do, what do people feel about supporting that? IMO,
cases(), from(), and values() need to be kept no matter what as they're more
self documenting and can be passed around as callables. So the question is
just whether we should also try to add casting a
Dec 4, 2020 7:37:51 PM Paul Crovella :
> On Fri, Dec 4, 2020 at 3:25 PM Larry Garfield wrote:
>>
>> Greetings, denizens of Internals!
>>
>> Ilija Tovilo and I have been working for the last few months on adding
>> support for enumeration
itself
go entirely to me.
*dons flame-retardant suit*
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ans that all enumerations would to based on a
> general enum.
> This would be very helpful on providing functionalities especially
> for enumerations thinking about a doctrine enumeration type or again an
> EnumSet / EnumMap.
Not at the moment. We're discussing the implications o
On Sat, Dec 5, 2020, at 3:26 AM, Pierre R. wrote:
> Le 05/12/2020 à 00:24, Larry Garfield a écrit :
> > Greetings, denizens of Internals!
> >
> > Ilija Tovilo and I have been working for the last few months on adding
> > support for enumerations and
On Fri, Dec 4, 2020, at 5:24 PM, Larry Garfield wrote:
> Greetings, denizens of Internals!
>
> Ilija Tovilo and I have been working for the last few months on adding
> support for enumerations and algebraic data types to PHP. This is a
> not-small task, so we've broken it
>perms[Role::Admin] = [Action::Order_Read, Action::Order_Edit];
}
public function isAllowed($user, $action): bool {
return in_array($action, $this->perms[$user->role]);
}
}
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e would be, but it's still a big step
forward. By breaking it into chunks, we make it more likely that as much as
can be done will get done, and approved, and into the language, even if the end
result is the same feature set when 8.1.0 gets tagged.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Sat, Dec 5, 2020, at 2:26 PM, Larry Garfield wrote:
> On Fri, Dec 4, 2020, at 5:24 PM, Larry Garfield wrote:
> > Greetings, denizens of Internals!
> >
> > Ilija Tovilo and I have been working for the last few months on adding
> > support for enumerations and
b/master/proposed/security-disclosure-publication.md
It unfortunately never really went anywhere, but I thought it was a good idea.
There's some links there to some prior art we were drawing from, or planning to
draw from. The idea was to allow projects to publish a link to a feed of
s
t the method in question is on an enum.
Having a way for developers to flag a function as safe to memoize would be
helpful, but is a completely different topic from Enums.
Forbidding enum-bound state is as close to guaranteed idempotence as PHP
allows, which is what the current RFC does.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
; I started an informal discussion for this change during the 7.4 cycle
> already, but decided to postpone the change at the time.
>
> Regards,
> Nikita
Seems well thought-out to me. Endorse.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ke use of the strict comparison semantics. Only switches that make
> use of non-trivial fallthrough behavior could not be easily expressed using
> match.
>
> Nikita
Disagree. switch is a procedural logic flow control. match is an evaluation
expression. Things like fallthrough do not be
why something
isn't a legit file; "missing" and "it's a stupid name anyway and it should feel
bad" and "the disk is missing" are all the same thing as far as it's concerned.
All it's asking is "if I try to open this file, should I expect it to work?"
Ha
tion getNumberKind(int $number) => match {
> $number > 0 => NumberKind::POSITIVE,
> $number == 0 => NumberKind::ZERO,
> $number < 0 => NumberKind::NEGATIVE,
> }
> ```
>
> See how natural it looks and reads.
Ah, someone gets what I'm driving towar
space.
>
> -Sara
It looks like the quoted part from someniatko changed from a named function to
an anon function? Not sure what happened there.
I've included both a named and lambda version of his example in the RFC,
however, and linked to the short-functions RFC as that would allow the
ern matching RFC that Ilija and I
have been kicking around for post-enums:
https://wiki.php.net/rfc/pattern-matching
That's still in the "it would be cool if" stage only, and is IMO off topic from
the abbreviation effort in this RFC.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, Dec 15, 2020, at 3:00 AM, Nikita Popov wrote:
> On Mon, Dec 14, 2020 at 6:34 PM Larry Garfield
> wrote:
>
> > I present to Internals this tiny RFC to follow up on the match()
> > expression RFC from earlier in the year. There was solidly positive
> > support f
://wiki.php.net/rfc/short-match
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ring in the straw poll, note that the longer the prefix, the
uglier chained calls will get. Whether that's done with pipe or something
else, expect to be typing that prefix a lot. That's why I am OK with most
options except `iterable_`, because that's a lot of needless typing.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
thods on them at
compile time.
It's not perfect, but I think it's a good solution to a long-standing
challenge. (Whether or not such higher order functions belong in the standard
lib is debatable; it probably depends on what the performance difference is.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ell, since I'm quoted... :-)
I'm fine with this, but have one question and one correction:
* If we do eventually end up with list/vec types, would the naming here
conflict at all? Or would it cause confusion and name collision? (Insert name
bikeshedding here.)
* The last quote, from me, ha
y would conflict so I'd be fine with both happening.
+1 from me in concept.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Please explain?
> 4. Should we be considering other bloat^W features?
> a. Exclusive Union: type SingleSerialization = Stringable ^
> JSONSerializable; // XOR: Must be one, but not both
> b. Blacklist: type AnythingButDOM = !DOMElement;
> My opinion: Hell no. Just spitballin'.
>
> -Sara
Hard pass. At that point, make separate methods.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ld be a
> good start, but I think what's missing the most currently is a good API to
> get inspiration from.
> Is there a filesystem library in another language that is considered
> state-of-the-art at the moment?
>
> — Benjamin
I have heard very positive things about Rust's file sy
,
1 => 1,
default => $fib(n - 1) + $fib($n - 2),
}, range(1, 6));
print $fib(5); // Does this work?
(No you shouldn't write it like that, but since Fibonacci is the example we're
working with...)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ct(public string $name) {}
}
Why is that not OK? Someone mentioned it means you couldn't call a function
there, but... that's not a huge problem because I can't imagine why you would.
If we really wanted to avoid that:
#[Foo(new Bar(name="baz"))]
That would be unambiguous, if a bit
view of performance, self-documentation, or usability -- is stdClass. :-) I
can't recall using it in the last decade at least, and my code has been better
for it.
Especially now with constructor promotion and named properties, I'd prefer to
just forget that stdClass exists and encourage others to do so as well.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, Oct 20, 2020, at 11:08 PM, Mike Schinkel wrote:
> > On Oct 20, 2020, at 2:19 PM, Larry Garfield wrote:
> >
> > A while back, Nikita mentioned that it should now be easy to offer an
> > abbreviated syntax for functions that are just a single expression. I
>
Good luck with the RFC.
>
> - Nuno
Yes, that's how it would fall out, assuming multi-line-arrows happen. I'm
honestly still torn on that myself for various reasons, but "=> means
expression, fn means auto-capture, use one or both as appropriate" seems like a
reasonable syntax guideline that we can teach people.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
New Year. May it be enumerable.
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
is here:
https://peakd.com/hive-168588/@crell/object-properties-and-immutability
I hope it proves stimulating, at least of discussion and not naps.
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net
those 3 copies are not that expensive, so we can most of the
time ignore them except as a very micro-optimization. (See previous email.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Wed, Dec 30, 2020, at 12:30 PM, Aleksander Machniak wrote:
> On 28.12.2020 21:21, Larry Garfield wrote:
> > https://wiki.php.net/rfc/enumerations
> Why can't this be simplified to:
>
> enum Size {
> case Small;
> case Medium;
> case Large;
> }
>
> 'Sm
ling with very small numbers, so
in most cases you're unlikely to notice a difference unless you really are
iterating over something a million times.
I also tossed some big string properties into the class, and while the total
time went up a bit the ratio between the two stayed about the same
On Wed, Dec 30, 2020, at 6:27 AM, Rowan Tommins wrote:
> On 28/12/2020 20:21, Larry Garfield wrote:
> > After considerable discussion and effort, Ilija and I are ready to offer
> > you round 2 on enumerations.
>
>
> Thank you both, again, for all your efforts. I'm pleas
On Wed, Dec 30, 2020, at 2:43 AM, Markus Fischer wrote:
> Hi,
>
> On 28.12.20 21:21, Larry Garfield wrote:
> > The full RFC is here, and I recommend reading it again in full given how
> > much was updated.
> >
> > https://wiki.php.net/rfc/enumerations
>
fically. Yes, they're different
things, but the cost of them is not all that different because of CoW, so
considering them separately is not as important as it would be in a language
that doesn't automatically do CoW in the background for us.
(Whoever in the 90s decided to bake CoW into the eng
s. But only by eliminating some cases.
> I can see how enum RedSuites could extend enum Suites without breaking LSP.
> Not sure if it makes sense to dig on this now.
>
> Regards,
> Alex
Possibly as a future scope, if we see demand for it. The RFC is ambitious
enough as is and al
y-on-write behavior, full on
immutability doesn't actually waste that much memory. It does use up some, but
far less than you think. (Again, based on the tests MWOP ran for PSR-7 a ways
back.)
> I wonder if that difference can be optimised out by the
> compiler/OpCache: detect clones that immediate
()" after "private function __construct() {}"
Both fixed, thanks.
> Finally, I got a segmentation fault while trying to use what I think is an
> unsupported syntax (removing the ":string" from a scalar enum), where is
> the correct place to report this? The GitHub PR?
e stuck with class-level visibility so that's what we've
got to work with.
That's all background on why I think, in PHP specifically, letting developers
emulate immutability at the level they need rather than forcing it tightly at
the language level is going to be a better strategy.
(But, of course, I could be convinced otherwise with sufficient demonstrated
use cases, but they'd have to address the drawbacks of "immutable except for" I
noted previously.)
It sounds like no one is against clone-with, though? :-) Anyone want to argue
for clone-arguments?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ss structure
> (although this is not the actual code that runs):
>
> You might want to change the constructor to
>
> private function __construct(public string $case) {}
>
> in this example. The use of "new static" for a final class is also
> confusing.
Got them all, thanks. (new static is because at this point I basically never
use self and always use static, as it's what I actually want 99.4% of the time.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
/@crell/object-properties-part-2-examples
Along with an analysis of the pros/cons of each. As shown there, `initonly`
creates backdoors that make any but the most basic cases untennable.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Sat, Jan 9, 2021, at 7:24 PM, G. P. B. wrote:
> On Sun, 10 Jan 2021 at 00:33, Larry Garfield wrote:
> > It took a few days, but I am back with some more concrete examples. I
> > decided to try and convert PSR-7 to the various options considered in my
> > previous post.
ans nullable, and no-try means not nullable.) I'm good with it if the
consensus is good with it, but I want to see what the consensus is first.
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Sun, Jan 10, 2021, at 4:40 PM, Mark Randall wrote:
> On 10/01/2021 21:27, Larry Garfield wrote:
> > The "a method that begins with try is nullable, so watch out" idiom is
> > present in C# and Rust, but to my knowledge has never existed in PHP. That
> > d
On Fri, Jan 15, 2021, at 9:55 AM, Pierre R. wrote:
> Le 10/01/2021 à 22:27, Larry Garfield a écrit :
> > This is a little tangent from the Enums RFC, but I want to flag it because
> > it it's the sort of in-passing decision that could have far-reaching
> > implications,
n abusive user with many email addresses
is putting all the effort of dealing with an abuser on the victims. That's the
worst possible advice one could give.
cf: https://peakd.com/community/@crell/why-you-can-t-just-ignore-them
Please, for the love of all that is holy, expunge "don't feed the tro
ror reporting mode to
> exception mode. This change follows the same change in PDO. The RFC can be
> found here https://wiki.php.net/rfc/mysqli_default_errmode
>
> Kind Regards,
> Kamil Tekiela
Consistency FTW. +1
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing
ull at all then. If you want $bar to be optional,
and to be an empty array if not specified, then just do:
function foo(array $bar = []) { ... }
At that point, the only thing adding ?array does is allow you to explicitly
pass null, presumably because it has some meaning to your function. If you
d
On Thu, Jan 21, 2021, at 4:37 PM, Sara Golemon wrote:
> On Thu, Jan 21, 2021 at 3:29 PM Larry Garfield
> wrote:
> >
> > I'm unclear why you'd allow null at all then.
> > If you want $bar to be optional, and to be an empty array if not
> specified, then just do:
>
On Mon, Dec 28, 2020, at 2:21 PM, Larry Garfield wrote:
> Hello, Internalians!
>
> After considerable discussion and effort, Ilija and I are ready to
> offer you round 2 on enumerations. This is in the spirit of the
> previous discussion, but based on that discussion a grea
y in
PHP in syntactically clumsy and ugly. We want to fix that, and that has to
include some means of "give me a new value based on this existing value but
with some difference." (aka, exactly what with-er methods do, although I agree
entirely that if you have the option of less gen
On Fri, Jan 1, 2021, at 12:08 PM, Benjamin Eberlei wrote:
> On Mon, Dec 28, 2020 at 9:22 PM Larry Garfield
> wrote:
>
> > Hello, Internalians!
> >
> > After considerable discussion and effort, Ilija and I are ready to offer
> > you round 2 on enumerations. This
601 - 700 of 1363 matches
Mail list logo
