Implement abstract classes

[amomchilov]

This PR is already pretty large and complicated, so I descoped several things that would make it even worse:

1. Class methods like abstract def self.foo

2. abstract! on the singleton class, like:

   class C
     class << self
       abstract!
     end
   end

There are tests to ensure those unsupported features raise. I'll open follow-up PRs which implement them.

[amomchilov]

• Patch allocate instead of .new #22
• Implement abstract classes #3 👈 (View in Graphite)
• Implement interfaces #2
• Initial README #13
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[Morriar]

Relying on this inherited method means we only restore .new when user-defined self.inherited hooks call super. If an abstract class defines an inherited hook without super, concrete subclasses keep the abstract .new and can't be instantiated:

class Base
  abstract!

  def self.inherited(_subclass)
    # no super
  end

  abstract def call; end
end

class Impl < Base
  def call; end
end

Impl.new # raises CannotInstantiateAbstractClassError

I wonder if we should install this as a prepended singleton hook, or otherwise wrap/chain the existing hook, and add a regression test so subclass instantiation doesn't depend on user hooks calling super.

[amomchilov]

Good find. I'll come back to this, because:

1. Diagnosing and raising in that case requires more state variables, which an upstack branch will have and make trivial
2. Fixing it requires a bunch more anonymous modules and prepending stuff which is icky and I want to punt on.

It's doable, but not calling super is a skill issue, as the kids would say. There's even a default cop called Lint/MissingSuper which catches it.

For now I just added a test case that documents the broken behaviour.

Tracked in #45

[Morriar]

@amomchilov is it meant to be required standalone?

require "type_toolkit/ext/class"

like we do for not_nil!

require "type_toolkit/ext/nil_assertions"

If yes 2 comments:

1. We should require lib/type_toolkit/abstract_class.rb‎ in there to avoid undefined constant
2. We should rename it as type_toolkit/ext/abstract.

I'm not a fan of requiring files under ext directly, it would be cleaner to require features and let them require the internal plumbing properly:

require "type_toolkit/abstract"
require "type_toolkit/nil_assertions"

[amomchilov]

See https://github.com/Shopify/type_toolkit#cherry-picking-features

1. True.
2. Conventionally, ext files are named after the class they extend, not what they do. See https://github.com/rails/rails/tree/main/activesupport/lib/active_support/core_ext for example