Re: [RFC][DISCUSSION] PHP Namespace in core
| From: | Michał Brzuchalski | Date: | Wed, 15 Apr 2020 17:07:53 +0000 |
| Subject: | Re: [RFC][DISCUSSION] PHP Namespace in core | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-109661@lists.php.net to get a copy of this message | ||
Hi Derick,
śr., 15 kwi 2020 o 15:51 Derick Rethans <derick@php.net> napisał(a):
> On Wed, 15 Apr 2020, Michał Brzuchalski wrote:
>
> > Hi internals,
> >
> > I hope you're doing well.
> >
> > I'd like to announce the PHP Namespace in core RFC for discussion.
> > The RFC is authored by me together with George Peter Banyard and it's
> > purpose
> > is nothing more like to allow the use of PHP Namespace in the core.
>
> I think a "may" is not a clever way forwards. I think that if you want
> to use the PHP namespace for engine specific things (like
> Attribute/Token), then they must all use that, or none.
>
You mean if we want to introduce PHP namespace we should also propose
immediately to move
engine specific things (like Attribute/Token) into proposal?
If so then we should search for the rest of engine specific things which
will include then
many interfaces and classes like:
1. Traversable, Iterator, IteratorAggregate - cause these are used in
foreach statements
2. ArrayAccess - cause this one is required to accept r/w by dimension
(offset* - methods)
3. Serializable, __PHP_Incomplete_Class ?! - cause this is used in
serializing/deserializing and this is bound to magic methods in classes
4. stdClass - cause this is a default class of the object which is produced
when an array is cast to (object)
5. Closure, Generator - cause these are also tightly coupled with the engine
6. Throwable, etc. - just for consistency with the rest from
https://www.php.net/manual/en/reserved.classes.php
and https://www.php.net/manual/en/reserved.interfaces.php
Is that what you mean?
Cheers,
Michał Brzuchalski