into the process.
(Like those in https://github.com/Crell/fp/tree/master/src) Hack simply got
this wrong, IMO, and I would likely vote against an RFC with that approach as
broken, as it would make it far harder to add the other functional features
that are related to pipes. (PFA, a compose operator, etc.)
Which would also free up $$ for some kind of "implied object" syntax, as this
thread was originally discussing. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
int, x: $x, y: $y, z: $z);
>
> Also, I didn't see it mentioned, but maybe for future scope, these new
> arguments should be passed to __clone().
They should not. See
https://peakd.com/hive-168588/@crell/object-properties-part-2-examples . I
went through and experimented with diffe
named arguments that supports splat. Using that
here would handle all the use cases we care about, including dynamic names,
without any additional syntax.
Let's not shoe-horn arrays in here where they're not needed. Making arrays
themselves fancier/more compact with an alternate sy
owever, we want to throw the
question out: Is this general approach even acceptable? Are there
implementation challenges to any of them we're not seeing? Would you vote for
any or all of these proposals or oppose on principle? Are you interested in
helping us implement any of them :-) ?
On Thu, Apr 20, 2023, at 7:10 PM, Deleu wrote:
> On Thu, Apr 20, 2023 at 2:25 PM Larry Garfield
> wrote:
>
>> But that runs quickly into the problem of verbosity, reusability, and type
>> aliases, and the discussion usually dies there.
>>
>
> Just out of curio
On Thu, Apr 20, 2023, at 7:30 PM, Dan Ackroyd wrote:
> On Thu, 20 Apr 2023 at 18:25, Larry Garfield wrote:
>>
>> Hi folks. This is a pre-discussion, in a sense, before a formal RFC.
>
>
> Hi Larry,
>
> The "Allow casting closures into single-method inter
ssumed the delegate will resolve into
> interface Reducer {
> public function __invoke(?int $sum, int $item = 0): int {}
> }
This is effectively the same as the "typedef" version of callable types from my
email to Dan a moment ago. See there for the challenges.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Thu, Apr 20, 2023, at 9:47 PM, David Gebler wrote:
> On Thu, Apr 20, 2023 at 6:25 PM Larry Garfield
> wrote:
>
>> ## The options
>>
>> There's three ways we've come up with that this design could be
>> implemented. In concept they're not mu
#x27;t have to be treated
that way, and that's a change that requires no core code changes.
If we actually got working shared typedefs in the language, TBH I'd probably
recommend people put all of their package's defs in a single file, "file" load
it with Composer, and move on. Don't even bring PSR-4 into the picture.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
rd that has been proposed), etc. They're a fundamentally different beast
with different syntactic implications.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
http://wiki.c2.com/?DoubleBraceInitialization,
> C#:
> https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/object-and-collection-initializers#object-initializers
> ).
>
> Regards,
> Máté
True, but PHP 8.0 sort of added something close to object ini
occurred to me that you could extend an anon
class at all, so the issue never came up. And the apparent way to do so
involves eval(), so I'm already afraid of it. Given how edge-casey this is,
I'd be inclined to just leave it be.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ical way for it to
satisfy a multi-method interface. But there are ample single-method interfaces
around PHPlandia. And a single-method interface has no ambiguity about which
method the closure corresponds to.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsu
o enforce access restrictions,
which is a desireable feature.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
y major OSS project has some kind of structure and leadership and
decision making process. PHP is the only meaningful exception.
That's not because we're special. PHP has succeeded thus far despite having an
anarchic anti-pattern structure, not because of it.
The TC is a small, mode
code instead
because that's already a broken approach.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
an asked, how much would it hurt to leave the date-related methods
available but deprecated until 10.x?
I'm also not entirely clear how you'd polyfill functions that exist, but change
behavior.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
kely be feasible to keep
> them until 10, as long as they emit the deprecation notice to slowly nag
> developers away from them towards better alternatives.
>
> Best regards
> Tim Düsterhus
Given past pushback on changes that we've gotten, a low-cost/no-cost long
deprecation p
t
runtime, they get defined at compile time, just with an auto-generated name.)
That said, I have to agree here as well that I'm not a fan of forcing anon
classes to be final, but if someone could figure out dynamic-extension anon
classes, I would be a happy camper.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
we're all on the same
page. I'm actually pretty happy with where it ended up, even if it's not the
original design. This approach eliminates several hard-to-implement edge cases
while still providing a lot of functionality in one package.
https://wiki.php.net/rfc/property-ho
On Mon, May 8, 2023, at 9:38 PM, Larry Garfield wrote:
> Ilija Tovilo and I would like to offer another RFC for your
> consideration. It's been a while in coming, and we've evolved the
> design quite a bit just in the last week so if you saw an earlier draft
> of it in
On Tue, May 9, 2023, at 5:46 PM, Larry Garfield wrote:
>> I have a bigger concern: the take on references contradicts with the intro
>> about BC breaks: turning a materialized property into virtual one would
>> break BC as far as refs are concerned. One idea to fix that: add a
losure.
$field is only available inside the hook itself, not inside functions called
from it. But that does mean you could do this instead:
class User {
// snip
public string $fullName { get => FancyLibrary\fullName($field) }
// snip
}
Which, yes, should work fine.
If such a library actually became popular, that would be an argument to
implement the "property hook packages" or "property traits" concept that Swift
has, as noted in Future Scope.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
nship building to be done
with the broader user-space community, and offering a very wide grace period is
a good way to help with that.
That these particular functions and uses are quite rare doesn't really change
any of that; if anything it strengthens it, that we're willing to be gr
t your preferred
way to address it, OK, what is? "Do nothing, it's OK if people occasionally
get bullied out of contributing" is not an answer.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
technical matters mediators", to avoid revert-fights like we just
had. Keep the topic narrow.
> On a sidenote: I'd rather try to find a new solution for the PHP Group
> as licence holder. So the idea of having an elected comitee that coupd
> perhaps replace the PHP Group was tem
ge so that they're ready to "take over leadership of HEAD"
as soon as the branch is open for development. Maybe sooner.
This is an approach I'm open to exploring, but as noted, would be a scope
change and rule change for the RMs.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
itigated by these all being very uncommon cases, yes, but as a
principle we should give people more warning than that.
I am actually tempted to propose that we do deprecations at the very start of a
release, 9.0 and 9.1 only, and then not allow them for the rest of that major,
for that exact r
o
> ```get``` hook to prevent an emptiness backing store.
>
> Please give a comment.
> Thanks.
Correct; while this syntax would compile, it would result in the value assigned
to the property being ignored, and then the other heavyTask() value assigned to
it, but that still wouldn't ensure it was available the first time you called
`get`. That's probably not what anyone wants.
It looks like you answered your own question on the interface point, so I'll
leave that be.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
nd users far more than "whelp,
we did something big, version number time!"
Tangent: If I were to put together an RFC that set out such a 5 year cycle
expectation with reasonable guidelines around when things could be deprecated,
would anyone actually support it?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
;first, $this->last] = explode(" ", $value);
> ```
>
> Explanation:
> There is no automatic backing store value created to store the default value.
>
> Terima Kasih.
Those would be compile-time syntax errors, yes. (Or possibly link time, if
inheritance is involved, but still before execution time.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
r gets rather messy otherwise.
Changing the syntax and semantics for CPP itself (as in the first code block
above) is considerably out of scope for this RFC. I recall someone pointing
out why double-declaring the property would cause problems, but I forget the
reason. In any case, another promotion syntax would be a topic for another
RFC. I don't recall off hand the reasons Nikita had for choosing the syntax
that ended up being used.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
us from voters to include it, though, we can
consider that. (Meaning, anyone that would favor including an unset hook now,
speak up or we'll assume it's better to stick with just get/set for now.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, May 16, 2023, at 2:26 PM, Derick Rethans wrote:
> On 15 May 2023 13:38:56 GMT-05:00, Larry Garfield
> wrote:
>>On Mon, May 15, 2023, at 6:36 PM, Rowan Tommins wrote:
>>> On 15 May 2023 09:54:41 BST, "G. P. B." wrote:
>>>
>>>>Why are
case, you want just the method/property name on its own, without a
namespace, because it will be used in the context of an object to be named
later.
How would nameof() handle each of these cases?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
y be faster than in PHP but... by how much? If
it were 10% faster, would that justify inclusion in core? How about 30%
faster? 3x faster than user-space?
Where is the cutoff for "enough performance different" and "common enough
usage"?
We have no consensus on that right
e FIG Core Committee and
secretary positions, if anyone is interested.)
Internals, in its current form, is structurally incapable of the design
decisions that would need to be made for a "default versions of PSRs bundled
with the language" initiative, regardless of whether it's written in C or PHP.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Mon, May 8, 2023, at 9:38 PM, Larry Garfield wrote:
> Ilija Tovilo and I would like to offer another RFC for your
> consideration. It's been a while in coming, and we've evolved the
> design quite a bit just in the last week so if you saw an earlier draft
> of it in
and you're welcome to tell them I said so. :-)
That said, people really get fussy about the coding style PSRs/PER, but FIG has
done way more than that, and arguably much more important things. :-) But I
digress...
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> Jorg
How common is it in the wild? I am pretty sure I've used it myself without
really thinking many times, which I suspect is common. Knowing how much code
would be impacted would determine how we'd go about deprecating it and on what
timeline.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
back is logically an int, I would be fully in support of "and
returns an int" versions of these functions in core.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ting, which is the example Sara gave.
The second is when you have a wide type in an interface method parameter, but
in a given child class you know with certainty that the type is going to be
some subset of that. It's not typical, but I have a few cases where I've
needed that.
On Thu, May 25, 2023, at 3:21 PM, Robert Landers wrote:
> On Tue, May 16, 2023 at 11:56 PM Larry Garfield
> wrote:
>>
>> On Sat, May 13, 2023, at 7:27 AM, Robert Landers wrote:
>> > Hello Internals,
>> >
>> > It is with much trepidation and exciteme
> Open to feedback from everyone on this - keen to get the ball rolling
> quickly on it!
Interface properties are already included in the Property Hooks RFC, which
should be going to a vote soon-ish. We hope it passes, of course. :-)
https://wiki.php.net/rfc/property-hooks
--Larry Garfiel
r about the former, except that historically it's been the
only option. Once you have hooks, though, the latter is a natural and obvious
introspection mechanism. I'm not suggesting it's superior or that anyone needs
to switch to it, just that it's a reasonable approach.
And in that case, you need a reasonable way to specify that mechanism for an
interface. Hence, interface properties.
A "raw data" property can and should still be protected or private, at which
point none of this discussion matters at all as those are not and should not be
supported by interfaces.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ff to later is, I agree, the correct move.)
I am also confused by the choice to make __clone() run before with with
properties. I would have expected it to be the other way around. Can you
explain (in the RFC) why you did it that way? That seems more limiting than
the alternative, as you cannot forward-pass information to __clone() this way.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
uot; at the
operation, so that if necessary it can make changes that __clone() can then
respond to. The inverse doesn't make sense.
The only reason for `with` to come after would be to allow `with` to "override"
or "undo" something that __clone() did. Generally speaking, if you have to
undo something you just did, you shouldn't have done it in the first place, so
that's a less compelling combination.
This one isn't a deal breaker, but we should be sure to think it through as
it's kinda hard to reverse later.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
--
Larry Garfield
la...@garfieldtech.com
On Tue, May 30, 2023, at 2:42 AM, Andreas Hennings wrote:
> Hello list,
> this proposal will be useful in combination with "Declaration-aware
> attributes"
>
>
> Problem
>
> Currently, ReflectionMethod
t): void
{
$this->name ??= $subject->getShortName();
}
}
(Side note: This is why static analysis tools that forbid writing to readonly
properties except from the constructor are wrong; it's also an example of where
asymmetric visibility would be superior to readonly. But I digress.)
My preference would be for something along those lines to be implemented in
core.
Importantly, we *MUST NOT* design it such that the reflection object gets
assigned to a property of the attribute. Reflection objects are not
serializable. Attributes will frequently be cached. That means it forces the
attribute author to make the property nullable AND then unset it sometime
before the attribute gets serialized, or it will break. That's a no-go.
That's why I think an opt-in interface is the way to go. It also avoids any
confusion around the constructor parameters, which is, based on this thread, a
confusing area. :-)
My second preference would be the ReflectionAttribute::inProgress() call in the
constructor, or something like that. I like that less because it's a stateful
call, but it would also reduce the issue with readonly properties (as in the
example above) by making both alternatives available in the constructor, so
maybe it's an acceptable tradeoff.
I can see an argument either direction here.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
--
Larry Garfield
la...@garfieldtech.com
On Mon, May 29, 2023, at 8:28 PM, Claude Pache wrote:
>> Le 8 mai 2023 à 23:38, Larry Garfield a écrit :
>>
>> Ilija Tovilo and I would like to offer another RFC for your consideration.
>> It's been a while in
mance.
Do you have benchmarks showing that implementing it in C would be notably
faster? That would help the case that it should be written in C.
Also, please do not top-post.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, May 30, 2023, at 7:34 PM, Andreas Hennings wrote:
> On Tue, 30 May 2023 at 19:12, Larry Garfield wrote:
>>
>> I've run into this issue in my attribute library as well
>> (https://github.com/Crell/AttributeUtils). What I do there is allow
>> attributes to
On Tue, May 30, 2023, at 10:04 PM, Alexandru Pătrănescu wrote:
> On Tue, May 30, 2023, 19:39 Larry Garfield wrote:
>
>> On Mon, May 29, 2023, at 11:22 PM, Máté Kocsis wrote:
>> > To be honest, the current behavior seemed like the natural choice for
>> > me, and I did
ou can also include benchmarks there. From experience, if you don't have a
compelling reason why this *needs* to be in C rather than PHP (which in this
case boils down to performance exclusively), you're not going to be able to
convince people to add another random utility function. That's just the
reality these days.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
; condition-array.
>
> Looking forward to hearing your thoughts.
>
> Best regards,
> Janusz
As with the array_group thread:
What is the argument to put these functions in hard to update C, rather than
PHP that is easy to download with Composer? "could be a nice addition"
On Thu, Jun 8, 2023, at 6:15 PM, Nicolas Grekas wrote:
>> On Tue, May 30, 2023, at 10:04 PM, Alexandru Pătrănescu wrote:
>> > > On Tue, May 30, 2023, 19:39 Larry Garfield
>> > wrote:
>> > >
>> > >> On Mon, May 29, 2023, at 11:22 PM, Máté Kocs
eakd.com/hive-168588/@crell/object-properties-part-2-examples
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
o another so heavily) so here we are.
You're suggesting some kind of `clone` hook on properties? That would be
interesting, but definitely out of scope for both RFCs at the moment. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ray, where $array is an honest to goodness assoc
array/array literal, created by any means the developer wants.
Either of those are equally expressive; the first is, IMO, cleaner and easier
to read/type, and probably nicer on static analysis tools, but they're still
both equally express
t the same as now, and
>potentially makes extending existing interfaces easier.
I think I am overall positive, but still a bit uneasy and having a hard time
articulating why.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
for anyone that still needs to make the switch.
(A generic "functions to object wrapper" class is probably a not-too-hard
composer package for someone to write, either, but that's not a task for
internals.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
isite for ADTs being usable. (cf:
https://wiki.php.net/rfc/tagged_unions, though the design there is out of date.)
So... hopefully stay tuned.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
; in the future.
>
> I look forward to your reply.
>
> Best Regards,
> Go Kudo
For me, it's about the timeline. I'm on board with getting rid of mt_rand()
entirely, just not in 2 years time. The new Random extension is still very
new, tutorials aren't updated for it y
will PDO still have the postgres methods, or will their code break?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, Jun 27, 2023, at 5:20 PM, Dan Ackroyd wrote:
> On Tue, 27 Jun 2023 at 17:25, Larry Garfield wrote:
>>
>> The RFC doesn't specify if `new PDO(...)` changes behavior at all.
>
> That behaviour is not changed at all.
>
>> will PDO still have the postgres
he leaf entities in said array
> could be a subclass of SplFileInfo referencing the uploaded temporary
> file, with additional read-only properties for the extra upload-related
> attributes - but really the important thing is just having a sane,
> consistent structure. Having an
On Mon, May 8, 2023, at 4:38 PM, Larry Garfield wrote:
> Ilija Tovilo and I would like to offer another RFC for your
> consideration. It's been a while in coming, and we've evolved the
> design quite a bit just in the last week so if you saw an earlier draft
> of it in
doesn't that translate to "WeakMaps are currently not actually
Weak, and thus don't work at all?" I don't quite know how that would be a BC
break to fix...
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
s noted, now consider a Baz interface. For interface-and-trait, you add 2
more definitions. For interface-with-defaults, you add 1. For abstract
classes, you need to add 4: BazBase, FooBazBase, BarBazBase, and FooBarBazBase.
And that's assuming you're even in control of the base cl
On Tue, Jul 11, 2023, at 3:16 PM, Robert Landers wrote:
> On Tue, Jul 11, 2023 at 4:36 PM Larry Garfield wrote:
>> You have to check your vendor folder for an interface, or trait, or abstract
>> class. That doesn't change anything.
>>
>> As noted, now consider
asses still love to talk
about inheritance as a great thing for code reuse but... it's really not, and
many of the 21st century languages have been drifting away from that.
Traits/default-method-interfaces are a better alternative that doesn't conflate
"copy-paste avoidance&qu
ution to PHP.
> Looking forward to your feedback.
>
> Thanks.
> Robin
I think that would require an RFC.
To clarify, you're proposing to replace this:
count((new ReflectionClass(Beep::class))->getAttributes(Ignore::class)) == true
with
(new ReflectionClass(Beep::class))->has
h of the pushback is "that is weird and not
normal, according to the normal I first learned, so it must be a bad idea," and
people just stop there.
(If you voted no and the above description doesn't apply to you, please do
explain what your alternate reasoning is, because RFC authors desperately need
more feedback than we get right now.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
"multiple inheritance done right", that's what this RFC is
already.
I hope that helps clarify the context.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
th PHP's weaker type system, but
there are ways it could be done.
I'd like to bring the Pipes RFC back if I thought there was a reasonable
potential for it to pass this time. I would use the crap out of it myself.
Though I've also since decided that we do need a straight up func
On Mon, Jul 17, 2023, at 7:07 PM, Olle Härstedt wrote:
> 2023-07-17 18:58 GMT+02:00, Larry Garfield :
>> On Mon, Jul 17, 2023, at 2:57 PM, Olle Härstedt wrote:
>>> 2023-07-17 14:25 GMT+02:00, Karoly Negyesi :
>>>> Hi,
>>>>
>>>> I tried to r
support that.
(Which basically comes down to >>= and making monadic classes easier to work
with, but also runs into the generics problem, and that's its own mess.)
[1] https://peakd.com/hive-168588/@crell/much-ado-about-null
[2] https://github.com/Crell/fp/blob/master/src/composition.php#L39
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
more work to implement.
The original idea was that combining real PFA with a callable-based pipe would
give us the same net effect if we wanted it, but with greater flexibility and
more power across the whole language. Unfortunately the PFA RFC barely didn't
pass, due to its complexity. A nicer implementation, if it could be found,
would probably pass.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
erms of concat,
but I'd rather have both natively.
For more on my thoughts there, see:
https://peakd.com/hive-168588/@crell/aoc2021-review
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
k walls.
If any of the above has convinced someone that we should try any of these
features again, please speak up. I seriously do want this functionality, but
OSS spec work is not my favorite way to spend time.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Wed, Jul 19, 2023, at 12:08 PM, Olle Härstedt wrote:
> 2023-07-18 18:50 GMT+02:00, Larry Garfield :
>> On Tue, Jul 18, 2023, at 4:47 PM, Olle Härstedt wrote:
>>
>>> Any comment on a pipe (or piped process) as a first-class value? When
>>> you use |> the func
t Regards,
> *Ollie Read*
I'm not opposed to these, but would this be a good time to also add an
interface for attributable reflection objects, so that we can type against
that? These methods would all then go on that interface.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ttempt to let shared hosters lock down their
environment. That's an increasingly small percentage of the PHP using market,
though, so I am perfectly happy to lose disabled_classes entirely. However, I
think it should not get an exception for code-freeze. At best, I could see a
deprecation warning
elf.)
As a tangent here, that has a workaround:
https://peakd.com/hive-168588/@crell/php-tricks-access-control-bypass
Which I make use of in Crell/Serde, which is then used by my own config library
to produce exactly what you describe:
https://github.com/Crell/Config
--Larry Garfield
--
PHP
ode in the wild that
use the current syntax. Changing it now is virtually impossible, even if
everyone here agreed that it should be done.
So, like it or not, PHP attributes use #[] and will continue to do so.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
of the functionality, but having it silently
not-work on Windows is not a good approach. That may mean a larger refactoring
of tempnam is a good next step, to fix the issues noted in the RFC and then
support Windows consistently. I would support that, and including a suffix
either with that
in PHP 10.0 might be a better
> option.
I would also be fine with deprecating and removing the old/useless error modes,
but only if there's a long enough deprecation period. I question if 8.4->9
would be sufficient. I'd be more comfortable with deprecating them now and
removing in 10.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
gt; We could settle for a solution that works for all cases, returning null by
> default. Whether this solution is acceptable is likely a matter of taste.
That would taste just fine to me, frankly, and I'm OK with the code block shown
right after it.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
o, and again have double the
work and double the debate.
4. The Reflection API is complicated enough as is, without having to deal with
a whole other type of type. As someone who maintains a serializer, that would
be a lot of work for me to support, with no actual benefit.
In short, there's only two versions of structs that could realistically end up
existing: Crippled in some way, and "objects that pass funny."
So if what we really want are objects that pass by value, let's just implement
by-value opt-in objects and be done with it. It's much less work, much more
powerful, and avoids many more debates in the future.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
designed to be more misuse-resistant.
> DOMDocument will NOT change, and remains for the foreseeable future.
>
> We also have to change the $ownerDocument field in DOMNode to have type
> ?DOM\Document instead of ?DOMDocument.
> Problem is that this breaks BC (but only a min
is, but as others have noted I don't think
it's really the right way to go about it.
If the property hooks RFC passes (we're stalled a bit trying to put together
benchmarks, sorry), that will solve this use case in a much cleaner and more
generic way. (A property could be virtual,
that are
always managed via DI), I often prefer a named constructor just for convenience.
I don't see it as a Java-ism at all. Java is (in)famous for excessive layers
of factory classes, which is something different than what is going on here.
(How fair that reputation is in 2023, I don't know.) This is just "named
constructors," which has been a reasonably common pattern in PHP land for a
long time.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ing
usage would help. It would also help to know what the actual definition of
huge is right now; just referencing a header file in some other library doesn't
help me. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ceil and
floor should always return ints, unconditionally, because that's literally what
their purpose is. But that RFC doesn't say that, which makes me quite confused.
Similarly, the BC shim would therefore be (float)ceil($x), not ceil((float)$x),
which... I don't think that would
t begin with XML_ I propose to keep the prefix.
Unclear to me: Would the XML constants also be aliased into the namespace
verbatim, or left globally?
Did you consider making the new classes throw exceptions rather than forcing
people to remember to call another "was there an error"
On Fri, Sep 29, 2023, at 5:13 PM, Tim Düsterhus wrote:
> Hi
>
> On 9/29/23 18:58, Larry Garfield wrote:
>>> \DOMDocument will also use DOM\Document as a base class to make it
>>> interchangeable with the new classes. We're only adding XMLDocument for
>>>
that in the
Errors section to make it clear why exceptions right now are not an option,
given the push elsewhere to get rid of the old error handling approaches in
favor of exceptions.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ld have a setMaxDepth() method with
that name, since, AIUI, they wouldn't be able to actually set the max depth.
So I think the chances of there being a conflict are extremely remote, and an
acceptable risk.
This could be verified by doing a "top packages" scan using Nikita's scri
opinion, would be pertinent to add at the same time.
That has already been done: https://www.php.net/array_is_list
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
7;m pretty sure
the impact of going all the way would be small. I'm currently undecided on
which I prefer, but at least allowing them to be final sounds reasonable.
One thing I'm not sure about: What opcache optimizations would final enable?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
601 - 700 of 1424 matches
Mail list logo
