Re: improvements on mixins

> 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.

This is how I want it to be too. So calling 'update' on a game object
might end up calling 10 different update functions that are all set to
be called around the original update method.

> I am curious what this
> method will receive, your example looked like it took parameters, how do
> you
> intend to pass parameters to it?

The parameters passed in are those passed to the method it's hanging
off. So if you call 'obj.foo( 5 )' then that 5 is also passed into the
'before' and 'after' methods in the imported module, before and after
foo is called on the class. One difference to Ruby is that my language
supports method overloading, so foo(a) and foo(a, b) can both exist in a
class and are entirely different methods.

> 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.

I think I fail to quite see what your after. But I do like the idea of
altering method signatures because it could make it easier to get
modules from different sources to match up. Like if one module appends
functionality on the 'update' method whilst another appends onto 'act'.
They don't match up and so you'd want to change say the 'act' to
'update'.

Building in the ability to allow modules to generate methods names based
on a parameter might end up looking like some funky Ruby-template
language; and be both too much work to build and use (especially for
most code).

As my language also allows you to define both 'foo(a)' and 'foo(a, b)'
in a class and module, you might also want to change the signature of a
modules method so again it matches up. Like: 'foo(a)'  to 'foo( a, _ )'
or 'foo( _, a )'.

But as you can reopen modules why not just do:

module Bar
    def act()
        update()
    end

    def foo( a, _ )
        foo( a )
    end
end

What might be nice is if you can apply it to any existing module without
that module needing to be aware that you are doing this. Something like:

class GameObject
    include AI {
        act() => update(),
        foo(a) => foo( a, _ )
    }
end

Then your restricting your changes to only affect it being mixed with
one class whilst not altering the module itself. That could be nice.

> I like that idea, but don't really see how it is an advantage over just
> having a class.

My thinking was that if you took my idea to the extreme then all your
code is built into modules. Classes then just become boiler plate for
mixing and setting up and initializing those modules. Having to write
boiler plate is a bad thing, so I'd like to find a way of avoid this.
But maybe this is leading to feature creep. Unless I can think of a more
natural way to mix modules, I'll skip this one.

> 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

In regards to the 'extend Drawable' bit, an idea is to add constructors
for modules which the compiler can then force the user to initialize,
like:

module Drawable
    def new( img )
        @img = img
    end
end

class Asteroid
    import Drawable

    def new( img )
        Drawable.super( img )
    end
end

> 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, ...

Thanks for all your suggestions. There are also some technical reasons
why I can't use Ruby itself. The main one is that it needs to run 100%
within the browser and your program then compiles to JavaScript. There
are some projects available already that allow you to run Ruby like
this, but most work by sending your code across to a server where it's
compiled and then sent back. Mine doesn't.

After I decided I had to make my own version I then thought I'd give in
and add lots of my own alterations that I'd like. null instead of nil,
'new' for constructors instead of 'initialize', C style comments, this
instead of self, function overloading instead of optional parameters,
and some static analysis and error checking during a compile time. I
used to program heavily in Java.

I'm also planning to add some type inference so you can only call
methods that might exist on the object your working with. With it being
less dynamic then standard Ruby, your program compiles directly to
JavaScript with very little runtime support needed. In theory your
program will run almost as fast as if you had written it in JavaScript.

-- 
Posted via http://www.ruby-forum.com/.