On Thu, Mar 13, 2025, at 23:26, Bob Weinand wrote:
> Hey Rob,
>
> On 13.3.2025 21:46:49, Rob Landers wrote:
>> On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote:
>>> Hi
>>>
>>> Am 2025-03-12 11:10, schrieb Rob Landers:
>>> > - Accessing inner classes is done via a new token: ":>" instead of
>>> > "::".
>>>
>>> I don't particularly like that. It is “invented syntax” and I don't
>>> think that inner classes are sufficiently valuable to dedicate an entire
>>> operator to them that could serve a more useful purpose in the future.
>>> It also got 4 negative points in the rating back when the namespace
>>> separator was decided: https://wiki.php.net/rfc/namespaceseparator
>>>
>>> Would \\ (i.e. two backslashes) work? The outer class for inner
>>> classes effectively act as a namespace, so it makes sense to me to use
>>> syntax that is similar to namespaces.
>>>
>>> I'll look into the rest when there is a new implementation, since I
>>> assume some details will still be clarified and fixed as part of
>>> implementing the proposal.
>>>
>>> Best regards
>>> Tim Düsterhus
>>>
>>
>> I am not particularly attached to the separator. I specifically chose it due to being a
>> mixture of :: and -> and -: seemed like a bad idea. In other words, an inner class felt natural
>> to use :> -- however, I have some issues with it myself. Particularly, it is too much like |>
>> and as shown in the namespace RFC, way too easy to typo. Personally, after using it for a few days,
>> I'd almost rather go back to :: ...
>>
>> I will give \\ a try, but it has to be typed quite a bit when referencing inner classes, so
>> keeping it easy to type is a must. I feel like \\ requires a large movement to type, at least on a
>> qwerty non-english keyboard. Maybe people using other keyboards can chime in.
> Please go back to ::. The double colon was perfectly fine, the only thing which was weird was
> the implicit constant. It's fine for constants and inner classes to share the same name scoping
> (i.e. a constant must not share a name with an inner class). But an inner class should not be an
> actual constant.
>
> But otherwise, this was perfectly fine.
>
My biggest issue with :: is that it gets weird:
class Foo {
public class Bar {}
public const Bar = "";
public static function Bar() {}
}
echo Foo::Bar; // this is the constant
new Foo::Bar(); // this is the class
Foo::Bar(); // this is the method
new (Foo::Bar()); // this is the method
new (Foo::Bar); // this is constant
I can now differentiate between these all in the AST, but it seems weird to me. If we go this route,
I'd personally have the preference to allow them all and let people's code-style dictate
what is acceptable or not -- assuming I can ensure there is no ambiguity in the grammar. At least
with :> (or something else) we don't have to even have that discussion.. :)
>>> I don't think that inner classes are sufficiently valuable
>>
>> I'm curious why some people feel this way and why some other people are saying the
>> opposite (emphatically). I'll nudge the private emails I've received to speak up publicly
>> on the list as well. But, why do you feel this way?
>
> I don't know why some people feel this way, but at least with the autoloading mechanisms
> we have in PHP there are definite limitations to multiple classes in one file:
> - If you deserialize your data structure and it contains another class, whose name does not
> match the file name, you better hope to god that it has been autoloaded already. Surprising failures
> in production follow. (e.g.: the amphp\parallel process runner will try to serialize your exception.
> That's fine. But as soon as it's accidentally bubbling up and as it's not
> autoloadable, the hell breaks loose.)
> - Enums or Data Transfer objects specific to one or multiple functions of only this specific
> class would naturally fit into the same file. But you can't do it ... because the autoloading
> might try to load the enum first, before the class whose constructor or function you want to call is
> actually loaded.
> - Now, if you actually stuff multiple classes / enums into a single file, it's non-trivial
> to figure out (as the human reader, but obviously for the autoloader too) which file to access to
> read up the definition of a specific enum (short of using dedicated tooling for it).
>
>
> Certainly, one may say - yeah, just religiously use different files for ... every ... single
> ... class.
> But what's the point of that dogma?
> It definitely doesn't help the organization of dedicated helper structures tied to a
> single class.
> It's a tool for organization. It's not complex to understand.
>
> Outside of very puristic arguments I don't see any reason why one would not want inner
> classes.
>
>
> Further, with short classes, should they hopefully be introduced as well, it will become
> trivial to write shapes for any internal datastructures - simply using a "class Point(int $x,
> int $y); private Point $pos;" rather than "/** @var list{int, int} */ private array
> $pos;".
> This will be a very ergonomic way to reduce ad-hoc arrays which are only typehinted by phpdoc,
> giving proper typing and also safe access to structures via named accessors rather than [0] and [1]
> etc.
>
> Further Questions on the (original) RFC:
>
> - Why is there a conflict in static properties and the inner class name? The former always has
> a leading $ sigil.
>
Funny enough, this was due to me messing up the AST such that it was trying to access a property
instead of a constant. Once I fixed that, the conflict went away.
> - Any particular reason to disallow abstract inner classes? Feels arbitrary.
>
This went away as well, once I started cleaning up the grammar. Basically, I couldn't work out
how to allow :: in extends. I eventually figured it out once I implemented
:>. Replacing :> with virtually anything else is quite possible --
including going back to :: (I think).
> And a note: I consider the inheritance example misguided as "static constructors"
> (static methods which invoke new()) would be a better pattern here. Could you maybe come up with
> another example here?
>
>
>
> Bob
>
That was a pretty bad example! It illustrated the point but would probably be a bad practice.
— Rob