4 ms·

Best part about this is finally being able to avoid the dance of 'oh no the super called an overridden method and kinda-sorta-broke but not fatally, whoopsies'.

by tubs 4y ago

layer8 4y ago
You still have the problem that the super class might not be fully initialized when the overridden method is executed. Calling overridable methods from a constructor is just a bad idea in general.
- deleted 4y ago
  [deleted]
- tadfisher 4y ago
  There's been discussion about making this illegal, or at least emitting a warning. The term—or underlying problem—is "leaking this() in constructors".
  - layer8 4y ago
    Tools like FindBugs/SpotBugs and some IDEs have been generating such warnings for many years, this basically exists. What is difficult, however, is if a final method of the same class is called (which should be fine), but that final method in turn calls a non-final method (directly or indirectly). Or if the final method is in a superclass, whose implementation could later change (or could be made non-final). Or if you store a lambda reference to a non-final method in a field (there are valid use cases for that), then call a final method which directly or indirectly invokes that lambda. Unless you want to disallow any non-static method calls from constructors, the necessary language rules would be nontrivial. Making it illegal is difficult, because there is a lot of code relying on this, and there are valid use cases for passing this to foreign code from the constructor, foreign code which might of course invoke anything on the instance.
    - usrusr 4y ago
      Did any java-like ever try something like a language-level MyClass$WIP type? Seems quite elaborate for a niche problem like this, but could useful in other ways as well, e.g. by allowing finals not being final before promotion to non-WIP.
      - lmm 4y ago
        The checkers framework has at least some steps in this direction - possibly-not-fully-initialized classes are @Raw, which means that their fields may be null even if annotated as non-null.

Best part about this is finally being able to avoid the dance of 'oh no the super called an overridden method and kinda-sorta-broke but not fatally, whoopsies'.

by tubs 4y ago

Best part about this is finally being able to avoid the dance of 'oh no the super called an overridden method and kinda-sorta-broke but not fatally, whoopsies'.

layer8 4y ago

You still have the problem that the super class might not be fully initialized when the overridden method is executed. Calling overridable methods from a constructor is just a bad idea in general.

deleted 4y ago
[deleted]
tadfisher 4y ago
There's been discussion about making this illegal, or at least emitting a warning. The term—or underlying problem—is "leaking this() in constructors".
- layer8 4y ago
  Tools like FindBugs/SpotBugs and some IDEs have been generating such warnings for many years, this basically exists. What is difficult, however, is if a final method of the same class is called (which should be fine), but that final method in turn calls a non-final method (directly or indirectly). Or if the final method is in a superclass, whose implementation could later change (or could be made non-final). Or if you store a lambda reference to a non-final method in a field (there are valid use cases for that), then call a final method which directly or indirectly invokes that lambda. Unless you want to disallow any non-static method calls from constructors, the necessary language rules would be nontrivial. Making it illegal is difficult, because there is a lot of code relying on this, and there are valid use cases for passing this to foreign code from the constructor, foreign code which might of course invoke anything on the instance.
  - usrusr 4y ago
    Did any java-like ever try something like a language-level MyClass$WIP type? Seems quite elaborate for a niche problem like this, but could useful in other ways as well, e.g. by allowing finals not being final before promotion to non-WIP.
    - lmm 4y ago
      The checkers framework has at least some steps in this direction - possibly-not-fully-initialized classes are @Raw, which means that their fields may be null even if annotated as non-null.