[ruby-core:32132] Re: Ruby 2.0 Wiki/Wish-list?

On Sep 8, 2010, at 12:37 AM, Yukihiro Matsumoto wrote:

> Hi,
>=20
> In message "Re: [ruby-core:32117] Re: Ruby 2.0 Wiki/Wish-list?"
>    on Wed, 8 Sep 2010 11:12:44 +0900, Joshua Ballanco =
<[e-mail]> writes:
>=20
> |-- "def" returns a lambda instead of nil
>=20
> "def" defines a method, which is slightly different in Ruby, so that
> returning a lambda would not be a good choice.  Some suggested to make
> "def" to return a symbol of the defining method.

This seems like a good place to start.

> |-- adding parens "()" to a lambda has the effect of calling it (i.e. =
my_lambda.() --> my_lambda() )
>=20
> I have tried but couldn't make it possible.  If you have an idea, I am
> open to hear.

I don't yet, but I will take this as a personal challenge!

> |-- named parameters
>=20
> Keyword arguments will be available on 2.0.

Excellent. Looking forward to that.

>=20
> |-- full access to subclass from metaclasses (i.e. allow =
prototype-style inheritance)
> |-- true namespacing (i.e. adding a layer to const lookup without =
adding a class/metaclass)
>=20
> I have no idea on above two.  Could you elaborate?

Sure.

-- full access to subclass from metaclasses

Essentially, I'd like to be able to do the following:

>> a =3D 'hello, world'
=3D> "hello, world"
>> class<<a
>>   def my_awesome_method
>>     self.length ** 2
>>   end
>> end
=3D> nil
>> a.my_awesome_method
=3D> 144
>> a.class
=3D> String
>> b =3D a.singleton_class.new
=3D> ""
>> b.class
=3D> String
>> b << 'test'
=3D> "test"
>> b.my_awesome_method
=3D> 16

As it is now, calling "a.singleton_class.new" raises an error. The idea =
of doing this would be to create a new object with all the same methods =
but without copying the properties. i.e. Prototype-based inheritance. =
The key, here, is that we can add methods to an instance of a class, and =
create new instances of that class without needing to create a subclass =
just to do so. I feel that, used properly, this feature might reduce =
some of the "polution" of core types that certain Ruby libraries suffer =
from, as people would be less tempted to open core classes just to add a =
few methods.


-- true (or, let's call it "lightweight") namespacing

A very common idiom in Ruby today is to pull all of the classes/modules =
of a project inside an "umbrella" module like so:
---
> cat my_first_class.rb
module MyModule
  class MyFirstClass
    def a_method
      ...
    end
  end
end

> cat my_second_class.rb
module MyModule
  class MySecondClass
    def another_method
      ...
    end
  end
end
---
There are two problems I see with this approach. First, the programmer =
is creating *and* reopening a module, perhaps many times, just to gain a =
level of scope. This module is not intended to be used as a mix-in, so =
all of the internal datastructures and mechanisms that enable mixing-in =
need to be set-up, but they are never used. Second, in the results of =
Object#constants there will be an entry for MyModule, but again MyModule =
is only being used to add a layer of scope. So, what I would like is a =
"namespace" keyword which adds to the constant resolution chain, but =
does not actually create a module for mix-ins and does not appear as an =
independent constant. It is lightweight in that it is only affecting =
lookup. Also, when someone does not want to have to always type =
"MyModuleName::MyClassName", currently the only option is to do "include =
MyModuleName", but this is doing a mix-in when all the programmer wanted =
to do was to remove a layer of constant resolution.

Cheers,

Josh=