From: Josh Cheek <josh.cheek@...>
Date: 2011-01-13T19:25:00+09:00
Subject: Re: improvements on mixins

--001485f7d33cc33b900499b7bac7
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 13, 2011 at 12:52 AM, Joseph Lenton <jl235@kent.ac.uk> wrote:

> If the module is included to a class that contains the method 'bar',
> then the modules 'bar' method is called after the classes bar method.
> I'm pretty
> certain it's possible to build stuff like this in Ruby, but I'm thinking
> of baking this into my language to make it easier to do more aspect-like
> programming.
>
>
If you do that, it would be nice if you could register any number of
callbacks with it, and they will all be run, so that you don't have to put
all your after behaviour in one place, but can instead have lots of code
receive notification of this method's completion. I am curious what this
method will receive, your example looked like it took parameters, how do you
intend to pass parameters to it?


>
> If you were also trying to build a better module system then Ruby's
> (which I already think is better then those in most languages) what
> would you want to be able to do?
>
>
When I include a module, I would want to be able to pass it parameters, so
the module could customize its methods for the class more intelligently. For
example, if you want to use Ruby's Enumerable module, you must define #each.
But what if you could name your iterator whatever you wanted? Well, to make
that happen you have to jump through some counter-intutive hoops, like they
do with Rails plugins. Okay, naming it something other than each isn't very
useful, but think about things like Paperclip, where you can name your
attachment whatever you want, and the methods it creates will be customized
accordingly.


> Another idea I was thinking of moving towards would be if you could
> compose whole objects solely from mixing modules together. Like an
> asteroid could be a Drawable( asteroid_image ) + MoveRandomly +
> DamagePlayer.
>
>
I like that idea, but don't really see how it is an advantage over just
having a class. Why not just mix those modules into the Asteroid class, then
when you create a new asteroid, it has all of that functionality without
having to mix those modules into every single asteroid's singleton class (or
however you intend to implement it). Also, you can do this right now, in
Ruby:

module Drawable
  def draw
  end
end

module MoveRandomly
  def move
  end
end

module DamagePlayer
  def damage
  end
end

def asteroid
  Object.new.instance_eval do
    extend Drawable # here it would be nice to be able to say :image =>
"images/asteroid.png"
    extend MoveRandomly
    extend DamagePlayer
    self
  end
end

asteroid.methods.grep(/^(draw|move|damage)$/) # => [:damage, :move, :draw]
(class << asteroid ; self ; end).ancestors # => [DamagePlayer, MoveRandomly,
Drawable, Object, Kernel, BasicObject]





Anyway, good luck with it, but I would consider what changes you want to
make, and whether they really warrant creating an entirely new Ruby-like
language, or if the similarities are strong enough that just using Ruby
itself is satisfactory, and to implement the unique aspects, you could just
create a framework on top of it. For example, everything you said here seems
doable in Ruby, Rails and many test suites have before and after methods /
callbacks, Rails has parameter passing to modules, as I showed above, you
can already create objects by mixing modules into their singleton classes.

As a last thought, you might look into doing what Mirah did, which is modify
Ruby's parser and just map it to their own back end. This is how they got
Java with Ruby syntax. You could save yourself a lot of work by doing
something like that.

--001485f7d33cc33b900499b7bac7--