2021/05/28/a kluge using abstract methods

From Woozle Writes Code
Revision as of 14:06, 28 May 2021 by Woozle (talk | contribs) (Created page with "{{box/nav/log}} category:post category:ferreteria I don't know if I'll end up using this technique or not, but I thought I'd make a note of it because of the underlyin...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Template:Box/nav/log I don't know if I'll end up using this technique or not, but I thought I'd make a note of it because of the underlying problem it illustrates.

  • I have a number of traits which need to be initialized somehow.
  • It turns out to be a bad idea to define constructors inside traits, because the different classes that use those traits may have different constructor arguments.
    • In other words, there's no clean way to have a trait call the constructor of a class that uses it, unless you carefully restrict what classes can use it...
      • ...and even if that were desirable (which it is in some circumstances), there's no way to enforce it.
  • I had resorted to putting notes in the trait documentation -- like "HOSTING: host must call [name_of_trait_initialization_method]"...
    • ...but when a trait is several layers deep in other traits (which happens a lot with the method/routing pattern I use), this can be easy to overlook.

The solution I'm trying is to just define an abstract method named "Call_[name_of_initialization_method]". Whatever host does the calling simply defines this method with no code, to signal that the call has happened. This serves as nothing more than a reminder to the coder that a thing needs to be done when using a given trait.