On Wed, 15 Apr 2020 at 20:54, G. P. B. <george.bany...@gmail.com> wrote:
> On Wed, 15 Apr 2020 at 19:24, Andrea Faulds <a...@ajf.me> wrote: > > We already have PHP language features relying on classes in the root > > namespace (Closure, Throwable, ArrayAccess, etc) so the point Marcio > > makes about inconsistency is nonetheless valid I think. > > > The proposal is not to move everything into the PHP namespace. > I would even argue that these interface make more sense in the global > namespace as they are meant to be available to all users to implement > and extend. > > [...] > > A more relevant example, in my eyes, is the current proposal of attributes. > Engine attributes like JIT, NoJIT, and possibly in the future Deprecated > and/or Final are features provided by the engine which should not have the > possibility to be extended by end users, only consumed. > I don't really understand the distinction here. We currently have many interfaces which exist to trigger "magic" in the Engine, some of which even have special restrictions on how they can be used (e.g. you can't actually implement Throwable or Traversable). If we want to prevent users extending an attribute like JIT or NoJIT, we can just mark the relevant class "final", and while extending ArrayAccess or Countable is possible it isn't a particularly common use case, so that doesn't seem like a meaningful difference. If ArrayAccess didn't exist yet, and was proposed after this RFC was accepted, my interpretation of the text would be that it must be placed in the \PHP namespace, because it is "tightly coupled to the internals/engine of the PHP interpreter". Regards, -- Rowan Tommins [IMSoP]
