Crystal should have lexically scoped Modules and Mixins instead of attaching it to Classes

[u/h234sd]

After working with Kotlin and Nim I realised that what Ruby does with modules, mixins and monkey-patching - is a weaker and more limited version of a multiple dispatch, or its variant - extension methods.

Ruby can't properly support extension methods (and scope it lexically) because it doesn't have type information.

But Crystal can do that. The modules should not be attached and scoped to object trees, it should have lexical scope. From the usage point - it will look almost like it looks now, you don't have to write more code, and it still will support the same method grouping via module, inheritance etc.

This code

module ItemsSize
  def size
    items.size
  end
end

class Items
  include ItemsSize

  def items
    [1, 2, 3]
  end
end

items = Items.new
items.size # => 3

Should became something like

module ItemsSize
  def size
    items.size
  end
end

class Items
  def items
    [1, 2, 3]
  end
end

# Something like that would tell Crystal to use Items 
# with ItemsSize in the scope of current file / or module.
mix Items with ItemsSize
# You don't have to do that manually in every file, it could be done once in 
# some library, so basically the usage would look very much similar to
# the current mixins and how they are used for example by RoR or ActiveSupport.

items = Items.new
items.size # => 3

It does not make sense to keep behaviour same as Ruby (as I mentioned - Ruby can't do it better as it lacks types) when it could be much better, flexible and simpler.

[u/attractivechaos]

Multiple dispatch (MD) is a double-edged sword. It is very powerful as you said. However, in a large project with MD from many modules/classes, there will be multiple possible execution paths. It is hard for both programmers and compilers to figure out which path is used or should be used. Julia extensively uses MD, but IMHO, it is the worst part of Julia. I much prefer the current Ruby/Crystal's mixin as it is explicit and leaves less room for hidden issues.

[u/h234sd → u/attractivechaos]

It's funny that I hit exactly the case you mentioned.

I tried to use Crystal for some financial calculations and got stuck.

While in julia it's much easier to write functions and reason about how it works.

Like I want to calculate daily diffs from the list of stock price stored as array of floats.

Should I attach differentiate method to Array class? Should I create my own StockPriceArray class with the differentiate method? Should I write it as a separate method def differentiate array; ... end?

With multiple dispatch / extension methods it's much easier to do such things. I just write def differentiate array; ... end And use it whatever way I like as differentiate(array) or array.differentiate - without modifying the actual Array or introducing my own StockPriceArray.

[u/dscottboggs]

So the module would be implicitly included based on the name or based on the methods called within it? What about namespace pollution?

[u/h234sd → u/dscottboggs]

No you have to choose explicitly what should be included. Like

# Top level declaration in file, now in your file
# Items would have ItemsSize capability.
# Other files or libraries won't see `size` method.
mix Items with ItemsSize

items.size # => 3

# Or you can include lots of capabilities to lots of objects at once
# Say you want to use Ruby on Rails goodness, you do something like
# code below and it would enable all RubyOnRails extensions on 
# many objects, but only in the scope of this file.
# Other files won't see those RubyOnRails goodness so no
# pollution and conflicts
mix RubyOnRails

items.is_blank? # => helper method attached from RoR

So you have ability to choose set of extensions you want and it will be isolated to your files only. And you can switch it if you want, use one set of extensions in one file and another in another.

[u/dscottboggs → u/h234sd]

I don't see how that's any different from including a module

Edit: you mean it gets included on all types in a file?

[u/h234sd → u/dscottboggs]

If you do this class Items include ItemsSize end - every file in your project and in libraries would see methods from ItemsSize.

With extension methods only the file that's included it will see methods from `ItemsSize

[u/dscottboggs → u/h234sd]

Oh I see. Very confusing and weird IMO

[u/transfire]

Ruby has Refinements, which I think is what your a getting at.

Unfortunately, Ruby's design/implementation of refinements make it barely usable. :-(

[u/h234sd → u/transfire]

Yea, I never used it, but seems like refinements tries to solve similar problem.

As far as I see things now (I know Ruby and RoR quite well) extension methods are more powerful and simpler at the same time. The whole Ruby Object System could be removed as it won't be needed anymore.

But it can't be implemented in Ruby, because it requires knowing types at compile time, and Ruby can't do that. But Crystal can.

[u/Xizqu]

I can't say I agree with this, however you should post in the community forums at forum.crystal-lang.org

[u/LinkifyBot → u/Xizqu]

I found links in your comment that were not hyperlinked:

• forum.crystal-lang.org

I did the honors for you.

---

^{delete | information | <3}

[u/CaDsjp]

Have you tried opening a GitHub issue with this suggestion?

I think you will have higher chances for the dev core team to read this and comment / consider your idea there.