https://wiki.php.net/rfc/is_list to use the name
> `is_array_and_list(mixed $value): bool` instead.
> (e.g. what if php used the reserved word `list` to add an actual list
> type in the future, and is_list() returned false for that.)
>
> I plan to start voting on the RFC in a few days.
Possible alternative that's less clumsy: is_packed_array?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ould need
the assoc array that wouldn't work just as well with ->value, and it makes the
method type definition simpler.
I've updated the RFC to have cases() always return a packed array; Ilija will
update the PR soon.
Thanks for your feedback!
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
r, and gets us to objects
that are effectively immutable from the outside, which is what's important.
(If they're mutable from the inside, either there are use cases for that or
rely on the good behavior of just the class author, who is in the best position
to know if the object should be inte
s where you can guard it
carefully and keep everything else as pure as reasonable.
All of which is why the scope I'm looking at is not how to make PHP
Haskell-esque pure. It's how do we make it more ergonomic for developers to
build stateless code in those places where it's reasonable to do so. It'
we'd call it, though. array_is_keyed? array_is_assoc?
array_is_not_objects? Bikeshed as you wish. :-) But we'd want some easy way
to tell what key-style an array uses.
... maybe a function that returns an internal enumeration of List, Assoc, or
Object for the 3 key types? :-)
--Larry Garfield
--
On Tue, Jan 12, 2021, at 10:13 AM, Ben Ramsey wrote:
> > On Jan 11, 2021, at 19:09, Mike Schinkel wrote:
> >
> >> On Jan 11, 2021, at 6:52 PM, Larry Garfield wrote:
> >>
> >> On Mon, Jan 11, 2021, at 2:27 PM, Ben Ramsey wrote:
> >>>
oted, is ADTs/tagged unions. Those
could not have a primitive equivalent, since they're not singletons. Keeping
UnitEnum and ScalarEnum separate allows us to later add TaggedEnum (or similar)
that also extends UnitEnum, but not ScalarEnum.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ooks a lot more like a generic. Which... I suppose in some ways this is if
you squint really hard? I don't have much of an argument against it other than
aesthetic. I have no idea what the parser would do with it.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
; > first half of next week, probably Tuesday-ish. If you have any other bug
> > reports or tweaks, please speak now or forever hold your patches.
> >
> > --Larry Garfield
> >
> >
> Hi,
>
> Maybe IterableEnum can actually be just Enum. As you are not allowed
The vote on the Enumerations RFC is hereby opened. It will run until 17
February 2021.
https://wiki.php.net/rfc/enumerations
Vote now, or forever hold your memory allocations.
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
On Fri, Jan 29, 2021, at 11:15 AM, Larry Garfield wrote:
> And we're back again. The RFC has been updated with a steady stream of
> smaller improvements based on feedback and testing, and is now in its
> Final Form(tm) (we think). The only major change worth noting is that
>
ta. What's the status of this RFC? Are you going to bring it to a
vote, or is something else blocking it?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
::current().
>
> Does anyone object to this rename? Shall we have a vote or is that not
> necessary?
>
> Cheers,
> Aaron Piotrowski
I support this change, and don't think it needs an RFC. I would vote for it if
it were necessary, though.
--Larry Garfield
--
PHP Internals - PHP
o me. define() is runtime anyway so it should support runtime
values.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
you're already doing
something wrong to begin with. But that's a bridge we can cross if and when we
get to it.
Would others be comfortable with that, if it allowed new-initializers for
static properties and class constants?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
will
die in v12 because we'll have real enumerations, I hope.)
get_class(): Used about a dozen times in Doctrine, but not in TYPO3 itself.
get_parent_class(): Used once in Codeception, the acceptance testing framework
strftime(): Unused
gmtstrftime(): Unused
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
not to explore that, as Nikita
explained off-list it was actually more confusing, not less, as it would
suggest "placeholder for a variadic" rather than "a placeholder that is
variadic." Otherwise, it's just more typing. The syntax choices section of
the RFC has been updated accor
particular grounds to challenge your methodology, so
I'll accept that C# seems to use readonly much more than asymmetric
visibility/accessors.
Does C# have a clone-with or equivalent? Even with readonly being useful, I
think it's only half the answer without a clean evolvability mechanism beyo
On Mon, Jun 7, 2021, at 4:06 AM, Nikita Popov wrote:
> On Sat, Jun 5, 2021 at 6:51 PM Larry Garfield
> wrote:
> > Thank you for the detailed analysis in the rationale section. I am,
> > however, still skeptical of this approach, for a couple of reasons.
> >
> >
sult is legit much nicer. i also tested it locally with a
combined partials-and-pipes branch to make sure they play nicely together, and
they do. (Yay!) Assuming PFA passes I will include those tests in the pipes
branch before this one goes to a vote.
--
Larry Garfield
la...@garfieldtech
ure. readonly would
be most useful if combined with a separate clone-with operator (discussed
elsewhere). Whether readonly is useful enough on its own without that to
justify its passage without a clone-with RFC also under discussion is an open
question, and largely what we've been debating.
Both approaches would eliminate *most* uses of __get/__set, which I think
everyone agrees is a win.
(Nikita, I hope I represented that accurately.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Mon, Jun 7, 2021, at 4:00 PM, Eugene Leonovich wrote:
> On Mon, Jun 7, 2021 at 9:03 PM Larry Garfield
> wrote:
>
> > Hi folks. Me again.
> >
> > A year ago, I posted an RFC for a pipe operator, |>, aka function
> > concatenation. At the time, the m
On Mon, Jun 7, 2021, at 8:09 PM, Mike Schinkel wrote:
>
> > On Jun 7, 2021, at 3:00 PM, Larry Garfield wrote:
> >
> > Hi folks. Me again.
> >
> > A year ago, I posted an RFC for a pipe operator, |>, aka function
> > concatenation. At the time,
On Thu, Jun 10, 2021, at 3:17 AM, Guilliam Xavier wrote:
> On Wed, Jun 2, 2021 at 7:47 PM Larry Garfield
> wrote:
>
> > Hi folks. After much off-list discussion, iteration, and consideration,
> > we have a new draft of PFA ready for review.
> >
> > T
named arguments must
> > be sorted after positional argument.
> >
> > Are there any concerns with relaxing this restriction?
> >
>
> Any further feedback on this?
>
> Nikita
I guess no one has concerns. I'm fine with it.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
uture, and presumably then
having those methods be removed outright, is the long-term plan. I'm good with
that too, but I don't see why the full death-cycle isn't included, and half of
it is instead punted to a future RFC.
Please explain.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Thu, Jun 17, 2021, at 2:54 AM, Côme Chilliet wrote:
> Le Wed, 16 Jun 2021 11:16:28 -0500,
> "Larry Garfield" a écrit :
>
> > Hi folks. The vote for the Partial Function Application RFC is now open,
> > and
> > will run until 30 Ju
On Thu, Jun 17, 2021, at 9:45 AM, Côme Chilliet wrote:
> Le Thu, 17 Jun 2021 08:37:23 -0500,
> "Larry Garfield" a écrit :
>
> > On Thu, Jun 17, 2021, at 2:54 AM, Côme Chilliet wrote:
> > > > $c = stuff(...);
> > > > $c = fn(int $i, string $s, flo
On Thu, Jun 17, 2021, at 3:01 AM, Côme Chilliet wrote:
> Le Wed, 16 Jun 2021 11:16:28 -0500,
> "Larry Garfield" a écrit :
>
> > Hi folks. The vote for the Partial Function Application RFC is now open,
> > and
> > will run until 30 Ju
ind,
potentially, although it also runs into the exciting question of type
restrictions and thus generics, which is where list type discussions go to die.
:-)
So it's not the concept I'm against; the angle of attack here feels sloppy and
coming at the problem from the wrong angle.
--Larry Garfie
ide, and they'll already
have exposure to many functional concepts even if they don't know them as such
explicitly.
For them, the common, non-pathological cases of PFA should be readily obvious
to read and understand.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Sat, Jun 19, 2021, at 12:39 AM, Hamza Ahmad wrote:
> HI Larry Garfield,
>
> Do you have a plan to further extend this rfc? I mean, what if one
> could typecast place holders? Broadly speaking, what if one could
> perform some operations, such as arithmetic, bitwise, and type
earning SQL beyond MySQL 3.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
other claim of fit-for-purpose, rather
than a claim of origin. That's guaranteed to be incorrect often enough that it
makes things worse rather than better.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ould be the
next logical step.
Also, Mel mentioned destructuring. Ilija has partially-finished work on a
pattern matching operator that would include destructuring here:
https://wiki.php.net/rfc/pattern-matching
It's not going to make it into 8.1, sadly, but hopefully that or something like
it would make it into 8.2.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
uded that database portability is no longer an
achievable or even desirable feature. SQL is just too fragmented a language,
leaving you with a least common denominator that is grossly under-whelming for
modern needs. If you want more than SQL92, it's not really viable anymore.
--Larry Garfield
On Wed, Jun 16, 2021, at 11:16 AM, Larry Garfield wrote:
> Hi folks. The vote for the Partial Function Application RFC is now
> open, and will run until 30 June.
>
> https://wiki.php.net/rfc/partial_function_application
>
> Of particular note, a few people had asked about
uot;literal string concat int --> literal string" is
incorrect and should be removed from the RFC, as it is misleading. That it may
hurt adoption is irrelevant, as creating a false sense of security is vastly
worse than slower adoption.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, Jun 15, 2021, at 10:06 AM, Nikita Popov wrote:
> On Fri, Jun 11, 2021 at 5:02 PM Larry Garfield
> wrote:
>
> > On Wed, Mar 3, 2021, at 9:03 AM, Nikita Popov wrote:
> > > Hi internals,
> > >
> > > I would like to propose allowing the use
On Mon, May 31, 2021, at 4:05 PM, Larry Garfield wrote:
> Hello again. I have also opened the vote for short-functions.
>
> https://wiki.php.net/rfc/short-functions
>
> The vote closes Monday 14 June.
The vote has now closed. Final tally:
Yes: 16
No: 18
The RFC has not pas
. If folks think that's worth doing I can do so.
It's not going to be able to scope creep much beyond its current minimalism.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e). I do believe it is the more flexible, more robust
approach, and fits with the general strategy I recommend of small, targeted
changes that combine with other small, targeted changes to offer more
functionality than either of them alone. That's exactly what we're doing here.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
find, than trying to mix inter-posting with top posting. I usually interpost
myself, which is more compatible with bottom-posting.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, May 11, 2021, at 10:38 AM, Larry Garfield wrote:
> On Sun, Apr 25, 2021, at 2:25 PM, Larry Garfield wrote:
> > Greetings, Internalians!
> >
> > I would like to offer for your consideration another RFC, specifically
> > syntax for partial function
On Fri, May 14, 2021, at 7:20 PM, Aaron Piotrowski wrote:
>
> > On May 14, 2021, at 7:00 PM, Larry Garfield wrote:
> >
> > Is that actually going to come up? Given that PHP functions (at least
> > user-space ones) accept extra trailing arguments and just let
y in dynamic cases like Nicolas pointed out, you may not
necessarily know how many arguments there are.
As Paul noted above, this isn't a syntax for calling a function; it's
effectively an even-shorter-hand way to write a short lambda. The rest of the
closure construction is derived from the function being partially applied.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
n
> others.
User-space functions have always accepted more arguments than they're defined
with. They just get dropped off the end silently, unless you use
func_get_args() or variadics. While I know not everyone likes that "feature",
it means that extra trailing ? "argument
tools separate has
its advantages, though I wouldn't make that argument myself.
I have no skin in this game and can roll with whatever, most likely. I just
want to make sure the lay of the land is clear, and there's a clear picture of
the options available. "Move to GitHub" is always a
kimmed through the PR and its tests, and I didn't see any
tests around attributes.
How do you envision attributes interacting with accessor-using properties? I
suppose there's no change for implicit accessors, but what happens for explicit
accessors?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
he case for the spec, which is why it just doesn't happen.
Is it going to be supported by people working on core? Fantastic. If not,
it's going to get and stay out of date and offer not enough value for anyone to
bother stepping up to pick up that slack. (As we've seen.)
I agree it needs to be either promoted to euthanized, one or the other.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ay of some combination of ReflectionTypes, whereas right now you
could rely on them being ReflectioNamedType. (But that also means one could
build ahead for that already with a little recursion.)
Am I following that correctly?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Maili
ion, since it wasn't entirely clear in Tyson's original email:
Static methods on Enums *are already supported*. They were included in the
original Enum RFC. The change proposed here is just about static properties.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Sun, Apr 25, 2021, at 2:25 PM, Larry Garfield wrote:
> Greetings, Internalians!
>
> I would like to offer for your consideration another RFC, specifically
> syntax for partial function application.
>
> https://wiki.php.net/rfc/partial_function_application
>
> It in
On Tue, May 11, 2021, at 11:57 AM, Nicolas Grekas wrote:
> > On Sun, Apr 25, 2021, at 2:25 PM, Larry Garfield wrote:
> > > Greetings, Internalians!
> > >
> > > I would like to offer for your consideration another RFC, specifically
> > > syntax for parti
nserialize(serialize($p1)); // This writes just "Logger start."
Am I understanding that right? If so, I'm... unclear why that is any more of
an issue than doing it the manual way now.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
: 3, z: 9);
I haven't tried running that (I don't feel like messing with the necessary
reflection), but... I think it would work already? Whether that's useful in
practice or not I don't know. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
gt; >
> > Here would be the first-class callable syntax:
> >
> > fn(...) => $callable(...)
> >
> > and for PFAs:
> >
> > fn(...) => $callable(?, 42, ...)
> >
> > Nicolas
As above, not really viable.
Also, to answer Andreas as long as I'm here: Supporting "new Foo" with PFA is a
separate question. As noted in the currently written draft of the RFC, the
problem is that object creation is not a function call; the object is created,
then the __construct initializer is called. A naive PFA implementation would
therefore create the object once, couple it to the partial, and then calling
the partial repeatedly would return the same object, rather than repeatedly
making a new object. Joe already figured out how to special case that, though,
so it's a non-issue.
Both Levi's writeup and mine could support PFA constructors, AFAIK.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ns you cite make any kind of general
> serializing both unreliable and impractical. I wouldn't plan on meaningful
> serialization.
Correct. A partial produces a Closure object like any other now, so it's as
serializable as any other Closure object. That is to say, not at all.
--Larry Garfield
-
point, just partialing them in the first place inside the match
would be better as then you never have a function name in a string to begin
with.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
olicy document on namespace usage. This is a
good first application of it.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
he constructor wasn't doing anything else besides shuffling its
parameters over to properties, which is now automatic.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
that is justification for the proposal, but it is
> one reason why ; might be preferred over {}.
>
>
> --
> Chase Peeler
> chasepee...@gmail.com
I agree that in the grand scheme of things this would be a minor matter, but
aesthetically I would prefer it as well. The {} annoys
r PFA gets sorted out in the future we end up with
yet-more-ways to do the same thing that are not optimizations of each other but
just competing syntax, in which case no one wins.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
-case to not deal
with directly, especially when the more verbose alternative still exists, but
that's the only reason I'd even consider making uninitialized something other
than "your constructor is bad and you should feel bad."
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
style
anymore. It may take a second RFC to modify this one to remove those,
technically, but I'd vote for it.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
enum Result {
case None;
}
function find_user(int $id): User|Result { ... }
$user = match($u = find_user($id)) {
Result::None => some error handling,
default: $u,
};
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Wed, Jun 2, 2021, at 6:15 PM, Mike Schinkel wrote:
> > On Jun 2, 2021, at 7:07 PM, Larry Garfield wrote:
> >
> > On Wed, Jun 2, 2021, at 5:59 PM, Mike Schinkel wrote:
> >>> On Jun 2, 2021, at 4:25 AM, Jordi Boggiano wrote:
> >
> >>> IMO
ference parameters?
$list->head() (returns first item)
$list->tail() (returns all items but the first one)
Straight outa FP. :-) Can probably do some internal optimizations to make them
more efficient, but now we're back to the discussion of a List or Vector type
built in, which always run
mpatible; it would benefit from clone-with, but still be usable
without it.
[1] https://peakd.com/hive-168588/@crell/object-properties-and-immutability
[2] https://peakd.com/hive-168588/@crell/object-properties-part-2-examples
[3] https://wiki.php.net/rfc/new_in_initializers
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
or the way methods get defined in Go.
(All of which would be quite neat, but I don't know how they'd play nicely in
PHP.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hello again. I have also opened the vote for short-functions.
https://wiki.php.net/rfc/short-functions
The vote closes Monday 14 June.
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Greetings, Internalians. After a bit of a delay, I have opened the vote for
auto-capturing multi-line closures.
https://wiki.php.net/rfc/auto-capture-closure
The vote closes Monday 14 June.
Prior discussion thread: https://externals.io/message/113740
--
Larry Garfield
la
On Mon, May 31, 2021, at 3:45 PM, Larry Garfield wrote:
> Greetings, Internalians. After a bit of a delay, I have opened the
> vote for auto-capturing multi-line closures.
>
> https://wiki.php.net/rfc/auto-capture-closure
>
> The vote closes Monday 14 June.
>
> Prior
feedback we get here).
Cheers!
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
since it was first introduced 15 months ago, and the first
pushback on it at all as far as I recall came less than 48 hours before the
feature freeze, leaving no time to have such a discussion.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Sun, Jul 4, 2021, at 2:18 AM, Olle Härstedt wrote:
> 2021-07-04 4:12 GMT+02:00, Larry Garfield :
> > On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote:
> >> Hi folks. Me again.
> >>
> >> A year ago, I posted an RFC for a pipe operator, |>, aka fu
reasons given here.
My preference would be to add property accessors in 8.2 (at least the
asymmetric visibility part), and then redefine `readonly` properties as a
shorthand for a "get only" implicit accessor property; which, if I recall
correctly, is essentially the same semantics as `readonly`. (I didn't check
the RFC; I'm going by memory here.) That would include interface properties by
nature.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
cit accessor
methods. We "just" have to convince Nikita that upgrading readonly to
asymmetric visibility in 8.2 (with or without explicit methods) is justified,
and that it should include the interface portion of that, too.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote:
> Hi folks. Me again.
>
> A year ago, I posted an RFC for a pipe operator, |>, aka function
> concatenation. At the time, the main thrust of the feedback was "cool,
> like, but we need partial function application f
On Tue, Jun 29, 2021, at 1:00 PM, Larry Garfield wrote:
> On Tue, Jun 29, 2021, at 12:30 PM, Guilliam Xavier wrote:
> > (Extracted from the "Pipe Operator, take 2" thread)
> >
> > On Tue, Jun 29, 2021 at 12:54 AM Larry Garfield
> > wrote:
> >
&
On Tue, Jun 29, 2021, at 12:30 PM, Guilliam Xavier wrote:
> (Extracted from the "Pipe Operator, take 2" thread)
>
> On Tue, Jun 29, 2021 at 12:54 AM Larry Garfield
> wrote:
>
> > On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote:
> >
> > > Would
like it would support deep cloning, but not with-er methods.
There's no way to provide a changed value. It also would mean a lot of work on
larger objects to transfer across all the properties. I don't really see what
this would add.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
r uses. It's a valid feature that has been
creeping into non-FP-centric languages slower than many would like, but it's
hardly fringe.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Interface suffix
or neither to. (Preferably neither.)
For that matter, I don't get why RandomInterface exists, if you'll just always
use Random all the time, and it's final.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Mon, Jun 28, 2021, at 3:42 PM, Olle Härstedt wrote:
> 2021-06-28 22:12 GMT+02:00, Larry Garfield :
> > On Mon, Jun 28, 2021, at 3:04 PM, Rowan Tommins wrote:
> >> On 28/06/2021 20:25, Olle Härstedt wrote:
> >> > Usage (ignoring the pes
ring pipes to a vote if PFA doesn't pass.
I'm tempted to, but it would require rewriting all the RFC text back to the
uglier version without PFA, and yeah, it's not going to look as pretty. And
the main pushback a year ago when I first brought it up was "PFA first, please,
so the callabl
en talking about all year) is to make
those things prettier and as fast as reasonable, which makes using those
techniques more natural. Once you start down that path, though, there's really
no usable solution before you get down as far as... PFA and Pipes in their
current form.
--Larry Garfield
for now, though, and
consider whether to also add asymmetric visibility in the Future(tm).
I don't really see an alternative "easy fix" for readonly and with-er methods.
I'll probably be voting +1 on readonly myself as is, even if it does make
with-ers harder, because it would at least make the case that either clone-with
or asymmetric visibility (or both, ideally) will be a necessity in 8.2.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
}
$c1 = new C();
$c2 = new C();
$strlen1 = Closure::fromCallable([$c1, 'beep']);
$strlen1b = Closure::fromCallable([$c1, 'beep']);
$strlen2 = Closure::fromCallable([$c2, 'beep']);
// What do these do?
var_dump($strlen1 == $strlen1b);
var_dump($strlen1 == $strlen2);
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ferent beast, so its
casting logic makes more sense there. I'm not entirely clear on what the use
case is in PHP. When would that be superior to "just write an asFoo() method
and move on with life"?
Scalar conversion I can see, but every time someone suggests adding siblings to
__toSt
not entirely clear on what the
> > use case is in PHP. When would that be superior to "just write an asFoo()
> > method and move on with life"?
> >
> > Scalar conversion I can see, but every time someone suggests adding
> > siblings to __toString(), there's m
I have opened the vote on the Pipe operator RFC:
https://wiki.php.net/rfc/pipe-operator-v2
The vote will close on 20 July.
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Mon, Jul 5, 2021, at 11:05 AM, Larry Garfield wrote:
> On Sat, Jul 3, 2021, at 9:12 PM, Larry Garfield wrote:
> > On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote:
> > > Hi folks. Me again.
> > >
> > > A year ago, I posted an RFC for a pipe operator, |
On Sat, Jul 3, 2021, at 9:12 PM, Larry Garfield wrote:
> On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote:
> > Hi folks. Me again.
> >
> > A year ago, I posted an RFC for a pipe operator, |>, aka function
> > concatenation. At the time, the main thrust of the
me of the issues with available symbols, and they're
> essentially the same for partials either way.) And I've been told that
> creating closures in the AST compiler is Hard(tm)...
>
> --Larry Garfield
>
>
> Wrapping stuff in lambdas is otherwise the obvious solution, no
ne-arguments mental exercise in my earlier
analysis, and the code it produces is totally disgusting. :-) clone-with is a
considerably better approach if you're starting from readonly. (It's also
better if you start from asymmetric visibility, although that version needs a
clone-help feature far less.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Wed, Jun 16, 2021, at 11:16 AM, Larry Garfield wrote:
> Hi folks. The vote for the Partial Function Application RFC is now
> open, and will run until 30 June.
>
> https://wiki.php.net/rfc/partial_function_application
>
> Of particular note, a few people had asked about
isibility and
clone-with, and combined with readonly we get a huge array of options for how
to lock down value objects and still make them evolvable. The worst case
scenario is we find that readonly cannot be extended to support clone-with for
some hand-wavy engine reasons, at which point it become
sier to read. Named arguments already
work exactly that way, too.
I don't see an advantage to adding a function that does what you can already do
with less syntax:
$args['foo'] = 5;
$args['beep'] = get_value_from_db();
$args['narf'] = 'poink';
$callable(...$args);
That works today in
le variants of Maybe.
(That is, it's a total function over Maybe.)
A comment (by whatever syntax) saying "pretty please don't extend Maybe" is
worth the executable code it generates (which is to say, None).
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
701 - 800 of 1409 matches
Mail list logo
