On Wednesday, 30 April 2025 at 13:16, Christian Schneider
wrote:
> Am 27.04.2025 um 20:22 schrieb Gina P. Banyard intern...@gpb.moe:
>
> > I fundamentally reject the concept of this RFC to restrict our ability to
> > do input validation.
>
>
> I am sorry but I fail to see how the RFC restric
On 7 May 2025 21:51:29 BST, Michael Morris wrote:
>On Wed, May 7, 2025 at 3:24 PM Rowan Tommins [IMSoP]
>wrote:
>
>Other libraries have the means to import into a namespace because their
>namespaces aren't just a quick and dirty string replacement. I've even
>proposed such a long, long time a
On Wednesday, 7 May 2025 at 20:20, Paul M. Jones wrote:
> Hi Maté and all,
>
> > On May 5, 2025, at 16:36, Máté Kocsis kocsismat...@gmail.com wrote:
> >
> > Hello Internals,
> >
> > After more than a hundred emails refining even the tiniest details, we have
> > reached a point where I'd like
On Wed, May 7, 2025 at 3:24 PM Rowan Tommins [IMSoP]
wrote:
>
> Problem number 2 is what you seem to be trying to address.
>
The main thing, yes. This solution incidentally solves class privacy issues
several unrelated and failed RFC's have addressed, including Nested Classes
which is currently
On 07/05/2025 22:02, Tim Düsterhus wrote:
> Hi
>
> Am 2025-05-07 21:43, schrieb Niels Dossche:
>> Definitely NAK on deprecating properties, which has the potential of adding
>> lots of overhead.
>
> FWIW: Deprecating properties is already possibly by means of deprecating a
> property hook. I gu
Hi
Am 2025-05-07 21:43, schrieb Niels Dossche:
Definitely NAK on deprecating properties, which has the potential of
adding lots of overhead.
FWIW: Deprecating properties is already possibly by means of deprecating
a property hook. I guess this is an acceptable workaround to not require
a ded
Hi
Definitely NAK on deprecating properties, which has the potential of adding
lots of overhead.
Note also that cache slot merging (during compact_literals optimizer pass) when
opcache is active may dodge the deprecation notice, and I don't want more VM
workarounds for then doing this anyway.
On Wed, May 7, 2025, at 12:50 PM, Daniel Scherzer wrote:
> Hi internals
>
> I'd like to start off some preliminary discussion about expanding the places
> that `#[\Deprecated]` can be used, and more widely how userland code can have
> the engine trigger deprecation warnings (rather than just manual
On 04/05/2025 08:34, Michael Morris wrote:
PHP has no way of dealing with userland code trying to write to the
same entry
on the symbol tables. Namespaces are a workaround of this and
combined with
autoloaders they've yielded the package environments we currently have
(usually
composer), but a
Hi Maté and all,
> On May 5, 2025, at 16:36, Máté Kocsis wrote:
>
> Hello Internals,
>
> After more than a hundred emails refining even the tiniest details, we have
> reached a point where I'd like to call for a vote.
> I know that the new API still doesn't support many use-cases, it still has
On Wed, May 7, 2025 at 10:59 AM Larry Garfield
wrote:
>
> So it's not really giving private symbols. It's not even blocking access
> to anything, since it can still just be included or autoloaded. What
> you're proposing is really just an optional loading facade (the real kind
> of facade) that
Hi internals
I'd like to start off some preliminary discussion about expanding the places
that `#[\Deprecated]` can be used, and more widely how userland code can
have
the engine trigger deprecation warnings (rather than just manually calling
`trigger_error()`). This is intended to be a follow-up
On 07/05/2025 14:10, Tim Düsterhus wrote:
And rewrite all references inside of `Foo` to `Foo$Bar` (using Java's
name mangling). This is effectively what Ilija's proposal for
file-private classes did: https://externals.io/message/126331#126337.
I think this would also be nicer on the autoloading
On 07/05/2025 14:18, Tim Düsterhus wrote:
I don't think it is currently possible to define a minimum composer
version as part of a package’s dependencies.
There are three "platform dependency" pseudo-packages available for
packages to depend on different aspects of Composer's version:
https
On Mon, Mar 24, 2025 at 11:33 AM Daniel Scherzer <
daniel.e.scher...@gmail.com> wrote:
> Hi internals,
>
> I'd like to start the discussion for a new RFC about allowing final
> promoted properties. You can see some preliminary discussion at <
> https://externals.io/message/126475>, but this is now
Hi
Am 2025-05-06 21:33, schrieb Rowan Tommins [IMSoP]:
The classes that you'll need to be aware of will exist whether this
feature is added or not, and you'll already need to avoid conflicting
with them - usually by simply avoiding the main namespace prefix of the
library.
If this feature wa
On Tue, May 6, 2025, at 1:33 AM, Michael Morris wrote:
> Resetting and moving the proposal writeup to a github hosted markdown
> file here:
> https://github.com/michael-lloyd-morris/php-modules-rfc/blob/main/php-modules.md
>> From your follow up statements, it seems that what you are proposing i
Hi
Am 2025-05-06 22:04, schrieb Rob Landers:
I think these are fundamental problems (if they are a problem at all)
with how PHP currently does namespaces and names.
I don't think that this is a fundamental problem of namespaces and
names. Ilija solved the naming conflict issue in his file-pri
18 matches
Mail list logo
