Hi Rob
On Thu, Mar 13, 2025 at 12:01 PM Tim Düsterhus <[email protected]> wrote:
>
> 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
I would like to echo these thoughts. I also think the RFC is kind of
missing the mark. Arguably the most common use-case for @internal is
to restrict a class to a specific package/module or namespace,
regardless of the user's class hierarchy. I believe you specifically
call this a non-goal:
> Currently, many libraries implement “internal” classes by using a naming convention or an
> @internal annotation in the docblock. Inner classes enable libraries to define an internal class
> that cannot be used outside the class it is defined inside. This feature is not meant to be used as
> a “module” system, but rather as a way to encapsulate logic internal to a class, such as DTOs or
> helper classes.
At least if I understand this statement correctly.
In that case, I see much less value in nested classes. They might
still be ok if they are extremely simple, but the proposal is
currently quite complex. It has a custom operator, it deals with
shadowing, LSP, runtime resolution and more, in addition to visibility
which is the actual goal. Maybe more use-cases are enabled, but I
don't think they are currently well described. Assuming visibility can
partially be implemented in a simpler way (e.g. top-level,
file-private classes), the costs seem to outweigh the benefits in my
opinion. Hence I would not be in favor of the RFC in this or a similar
form.
Ilija