On Thu, Mar 13, 2025, at 12:41, Ilija Tovilo wrote:
> 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
>
Hey Ilija,
> the proposal is
> currently quite complex.
Most of this is just describing how classes work already and going in-depth on where there may be
confusion -- there are no significant changes to how classes actually work. The actual changes to
the engine are basically just visibility rules, some syntax changes (to allow nesting
class inside another class), and handling the new operator. The hard part is explaining
how classes work, because they don't really have a defined behavior. In other words, I cannot
just say "the way this works doesn't change anything."
> They might
> still be ok if they are extremely simple
And now you can understand why they WERE just simple classes (short classes). So, you can see why I
originally bundled them together because of this EXACT argument. :sigh:
> 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:
I was specifically echoing this callout from Michał earlier in this thread and other
emails/comments I have gotten off-list; including my own libraries. I usually have DTOs that I want
to use specifically for certain things, but not expose them in the user application -- or even the
rest of the library. This isn't a replacement for "modules" or "namespace
privacy" but rather, complements it, if we ever implement it.
— Rob