On Tue, Mar 18, 2025, at 03:37, Bob Weinand wrote:
> Hey,
>
> On 17.3.2025 19:58:39, Rob Landers wrote:
>> On Mon, Mar 17, 2025, at 19:05, Bob Weinand wrote:
>>>>> . The idea that extending the parent class doesnt no inherit the child
>>>>> classes doesnt make sense to me.
>>>>> As then if you extend a parent class and call a function of that class
>>>>> which could rely on the existence of an inner class, I can see a lot of
>>>>> headaches caused by this exact scenario.
>>>>> As a developer, if I extend a class, I expect the entire dependance of
>>>>> that class to be inherited, otherwise the extending class won't work.
>>>>
>>>> I'm not sure what you mean. When you inherit a class, you do not
>>>> necessarily inherit everything from its superclass. You are free to
>>>> override it however you want. Since we are defining "types" in the sense
>>>> of PHP, we cannot merely inherit a "type", otherwise we would cause all
>>>> kinds of issues with LSP. This is specifically why inheritance works the
>>>> way it does in this RFC and why `static::` is forbidden.
>>> I don't understand the problem here.
>>>
>>> for each nested class in parent class:
>>> class_alias(substitute parent class with child class in class name,
>>> class name)
>>> Very simple. There's no magic needed, it can be simply class aliases. This
>>> will also make static, self and parent trivially work.
>>>
>>
>> PHP doesn't go out of its way to prevent the developer from violating LSP --
>> but where it can, it does. If a type were inherited, then the subclasses
>> wouldn't be able to guarantee that an inner/nested class implemented the
>> parent inner/nested class. Or, if it did, it would require that all
>> subclasses using a class of the same name MUST inherit from the parent class
>> as well.
>>
>> This is non-trivial to implement as the parent class may or may not have
>> been compiled yet when we are compiling the subclass. So, we have no idea
>> what the parent class actually looks like until runtime. Further, it is much
>> simpler to reason about each class as a distinct type vs. maybe inheriting a
>> type from a supertype.
>>
>> Thus, if you want to inherit from the super-class's inner classes, you can,
>> but this RFC won't force you to do so. In my mind, this is the biggest
>> argument for a `\`, because the enclosing class acts more like a namespace
>> than a type, from the perspective of the inner class.
>>
>> If we were to embrace `\`, then it could be argued that a namespace is
>> technically a class in itself, (but a partial class, to borrow from C#
>> terminology) and every class in a namespace is essentially just a public
>> class in that super-class/namespace.
>>
>> Nobody has argued that perspective, but I believe it may be interesting (and
>> would lay a foundation for namespace private/public class
>> behavior/visibility). That being said, it truly does cause issues with
>> autoloading -- at least, PSR-4 autoloading -- and I'm not sure whether we
>> should solve that problem here; however, it is something to be cognizant of,
>> for sure. There are other types of autoloading supported by tools, such as
>> composer, that do not have any issues with using `\` as a separator.
> Okay, I see the point with LSP. I'm not sure whether we need to preserve LSP
> for that specific scenario, but neither can I say that we should ignore it.
>
> (Effectively implementing LSP would mean that there's an implicit interface
> matching all public method signatures of the parent class, for child classes
> - which is doable, but possibly too much for the initial RFC.)
>
>
> I would however ask, should we not implement LSP compatible inner classes, to
> enforce that no child class may name a class the same than any non-private
> inner class declared by any of its parents, until we resolve this question
> (in possibly a future version of PHP).
> I do not think we should bar ourselves from allowing this in the future.
>
I'm not sure I understand what you are asking. But I think you are saying the
following should be illegal?
class ParentOuter {
class ParentInner {}
}
class ChildOuter extends ParentOuter {
class ParentInner {} // not allowed
}
>
> However nice grand unified naming schemes may seem, I don't think it's a good
> idea to pursue. Clarity and explicitness shall reign supreme here.
> I also don't think that the proposed visibilities are applicable to
> namespaced classes. In particular and in practice shared internal classes are
> not necessarily directly organized in a way it makes sense to organize inner
> classes. Also visibilities like protected propagate along the inheritance
> chain, something which is not given with (outer) namespaced classes.
> The less we mix these slightly different concepts, the better.
>
>
> "It's similar, except in these and those cases" is the death of all
> consistent experiences. Thus, let's not even attempt to pretend it is.
>
This is true.
>
> And not pretending starts with using a different symbol than a backslash.
>
I have been thinking about this for a couple of days now... When thinking
through the ramifications of my decision to use :> over ::, this will also
affect generics, most likely -- whenever that happens. This is because if this
RFC passes, generics will want to be consistent with whatever exists currently.
If we were to use :>, then generics would probably look something like this to
be consistent:
class Box<T> {
public function add(self:>T $item) {}
}
The same thing would also probably apply to ::
class Box<T> {
public function add(self::T $item) {}
}
With `\`, it nearly follows exactly what you would expect-ish:
use \Box\T as T;
class Box<T> {
public function add(T $item) {}
// or without use
public function add(Box\T $item) {}
}
With `\`, we can also just automatically check the current class as part of
namespace resolution when compiling:
class Box<T> {
public function add(T $item) {}
}
This would also make it easier to user inner classes:
class Outer {
public class Inner {}
public function foo(Inner $bar) {}
}
The other syntax options do not allow this; at least, I don't think so. I'm
very heavily leaning towards `\` as the separator.
— Rob
