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 <t...@bastelstu.be> 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
