Why are there no abstract modules?

Help & Support
1

Seems like this is related to Abstract def inside module not being enforced, but then again not:

module Sth                      # there is no abstract module in Crystal
    abstract def magic : Int32  # this is not enforced by Crystal (only typos here will trigger a compile error)
    def twice_magic : Int32
        magic * 2               # a non-abstract class would trigger a compile error here (without the abstract(s) above)
    end
end

class X
    include Sth
    def magic : Int32
        5
    end
end

x = X.new
p x.twice_magic

Is there a specific reason for this?

2

What is the issue in the pasted code? X implements magic, and it has the correct return type. So why would you expect a compile time error here?

# a non-abstract class would trigger a compile error here (without the abstract(s) above)

I assume you mean module there? That is just how modules work - they don’t have to be self-contained.

3

An abstract class is a class that cannot be instantiated.

Modules are already non-instantiable, so maybe that’s why there’s no abstract keyword for them.

Are you actually looking for something like an interface, protocol, or trait, rather than an abstract module ?

In Ruby, it’s common to write tests for this kind of thing. But since Crystal performs some compile-time checks, I’m not sure if that would be the best practice here.

1 Like
4

Also please note that the behaviour described in Abstract def inside module not being enforced has since been fixed. The compiler now refuses non-matching signatures.

5

I think I was too quick in my initial post. Let’s try to get it more straight.

If we define an abstract class…

abstract class X
    abstract def x
    def y
        z()
    end
end

… the compiler will…
a) always complain if x is not defined by the subclass and
b) complain about missing z if y is being called only. But it will not complain that z needs to be declared as abstract.

I was assuming Crystal would generally complain about missing abstract (class) method definitions, unlike (b) above (but it doesn’t).
And likewise I wanted to have a similar way for modules.

It seems abstract method definitions are optional in both classes and modules - so the more general question now for me is: is this on purpose?

1 Like
6

Abstract methods are entirely optional. They serve to document interfaces and validate their implementations. But they’re never required to type a program. Assuming a valid program, dropping all abstract defs should produce exactly the same output.
So yeah this is on purpose. Crystal uses duck-typing and generally tries to be hassle-free by default. If the compiler can type a program, it’s happy. We can optionally provide more explicit typing information like this, but it’s not required.

I can see the point that if implementors of X are supposed to implement the instance method z, there should be an abstract def for it.
But calling that out should not be the a responsiblity of the compiler. The compiler can perfectly type this program. It doesn’t need abstract defs, they’re just a tool for implementors.

Complaining about a call to a method z which is unspecified in the scope of X could be a task for a linter, though.

2 Likes
7

Thanks, I think I get your point. Either the compiler chokes on something it cannot fulfill - or it spills out a binary.

Non-fulfillability can arise out of methods or variables having incompatible types vs. use cases. Crystal enforces as little typing as possible, but allows arbitrary much of it. In that mindset, abstract is entirely optional on purpose. I double-checked the docs, I think it’s missing there.

On the other hand, if I declare a class (or maybe also a module, which is not possible right now) as entirely abstract to start with, shouldn’t it not also have proper abstract methods marked as such?

Could it also have an impact on e.g. Incremental compilation exploration?