rubynew.page

---
title   : RubyWorks Projects
stencil : rhtml
layout  : page

--- html

<div class="title">Ruby.new</div>

--- markdown

I love Ruby. It is no doubt the best programming language I've had the priviledge to write-in.
Yet there are some aspects that I feel can be imporved. I guess that's a sentiment of any
programmer. This section outlines an evolving set of notions about what I would like to see
changed. Perhaps they will find there way into Ruby one day; perhaps they will end up defining
a new programming language based on Ruby, or perhaps, more likely, they will just keep sitting
here on this page ;) In any case, do me a favor and don't judge them too harshly. Some are little
more than thinking aloud.

# Class/Module Unification

I beleive the distinciton between class and module in Ruby is completely disadvantgeous
to the language. For starters, the distinciton is arbitrary. There is literally conditional
code in Ruby that prevents the instaniation of a module or including a class. Remove these
conditions and Ruby will basically continue to work regardless.

In addition, the distinction makes it impossible for our programs to use namespace freely.

--- coderay.ruby

    class SomeSpace::Foo
      ...
    end

--- markdown

Will blow up in your face if SomeSpace is not defined. If classes and modules were effectively
the same it would not longer matter, and SomeSpace could be auto-instanitated.

Have you ever run into the issue of requiring a library that uses the namespace defined by the
file you requiring from? Frustratingly you have to put the requires at the bottom of the script.

# Using @ and @@ like a Hash

An object's collection of instance variables is essentially a Hash. And at times it's
convenient to deal with it as such. But this requires many little tricks using
instance_variable_get and friends. Why not allow instance variables the full Hash behavior?

--- coderay.ruby

    class Foo
      def same?
        @[:a] == @a
      end

      def ivars
        @.map{ |k,v| k }
      end
    end

--- markdown

# Method and Variable Isomorphics

It would be nice if method definitions amounted to little more than assigning a Proc to a variable.
Thus a Proc and a Method are no longer distinct, and the #call method becomes generally unnecessary.
Also the kernel method Proc itself could be depricated and -> { } always stand for a proc/method.
For example:

--- coderay.ruby

    class Foo
      bar = -> { |x| puts x }
    end

--- markdown

Is the same as:

--- coderay.ruby

    class Foo
      def bar(x)
        puts x
      end
    end

--- markdown

# Method definitions for $, @ and @@

One thing Ruby lacks that could be useful in some case are class-private methods. These
methods would not visible outside their immediate class. Of course the difficulty is
how to notate these. At one point in occured to me that @ provided the perfect notation.

--- coderay.ruby

  class X
    def @x
      "I can only be seen by X."
    end
    def show
      @x
    end
  end

--- markdown

Naturally this leads one to the same conclusion for @@ and $. Global methods... interesting.

--- coderay.ruby

  def $intersting
    "Down with global lambdas!"
  end

--- markdown

# Margin Controlled Strings using %l and %L

Respective to %q and %Q, will provide a margin controlled literal string constructor.

--- coderay.ruby

    x = %L|This
          | is
          |  margin
          |   controlled

--- markdown

Like %q and %Q other deliminators can be used.


# NackClass

A NackClass is the same as NilClass except for any method it does not recognize, it return
the instance of itself.

--- coderay.ruby

  nack.nack.nack.nack  #=> nack

--- markdown

Note I used to call this <code>NullClass</code>, but "nack" seems a little more fitting
a term. I can go either way though.


# Object's can be True or False

All Ruby objects except <code>nil</code> and <code>false</code> always evaluate to true
in a conditional. It would be quite powerful if we could override this behavior.
In fact it would allow us to define the previously mentioned NackClass ourselves.


# DateTime

Oh lord, this is really a biggy. Ruby's current handling of Dates and Times is all over the map. We have Date,
Time, DateTime, ParseDate, and more, not to mention all the other common extensions running around
out there. Ruby needs an improved class that incorporates them all. If memory servers there a library out there 
called <code>Chronos</code> that might do the trick. 

# Infinity

Err.. Where is a real Infinity?

I'll end it there with that little joke.