From: Bill Kelly <billk@...>
Date: 2009-11-14T15:23:04+09:00
Subject: Re: Naming conventions -- was: Re: DRYing a Regex


From: "David Turnbull" <dsturnbull@gmail.com>
> On 14/11/2009, at 15:21, James Edward Gray II <james@graysoftinc.com>  
> wrote:
>> I would like to see us move away from considering classes to be  
>> types at all in Ruby.  Who knows what modules an object has mixed  
>> into it and who knows what singleton methods are defined on it.  A  
>> class, which is what people traditionally take for the type, is just  
>> one piece of an object's identity.
> 
> I would still look immediately to the class of the object in order to  
> find out what it's supposed to do. From there, the class definition  
> will probably list it's module inclusions prominently.

A human looking to documentation to find out what an object
of a partiular class is supposed to *do*, is one thing.  But
then there's the programmatic flipside where one could code
a method to select between different behaviors based on the
class-type of a given argument-object.

  def foo(bar)
    if bar.is_a? Array
      do_array_thing(bar)
    elsif bar.is_a? String
      do_string_thing(bar)
    else
      ... # ?
    end
  end

I believe it's (variations on) the above that are viewed
as unreasonably restrictive in ruby.

It's challenging, too, because even :respond_to? can be
misleading.

I like Og (Object Graph), an Object Relational Mapping
library in ruby providing high-level database access.

  require 'og'

  class Address
    property :name, String
    property :company, String
    property :dept, String
    property :addr1, String
    property :addr2, String
    property :city, String
    property :state, String
    property :zip, String
    property :country, String
    belongs_to :order, Order
  end

When Og is initialized, it searches ObjectSpace for
classes like the above, and detects that they are
intended to be Og-managed classes, and imbues them
with certain basic features.  (It also generates the
SQL needed to create the database tables
corresponding to such classes.)

An example is that, given nothing more than the above
Address class declaration... I could now say:

  result = Address.find_by_name_and_state("Bob Jones", "CA")

But..! The Address.find_by_name_and_state doesn't even
exist until the time that it is called.  Part of the
magic with which an Og-managed class is imbued, is
some method_missing logic which looks for particular
method signatures, like /find_by_(.*)/ , and, at the
moment such a method is called, is tested against the
following, behind the scenes:

  def method_missing(sym, *args, &block)
    if match = /find_(all_by|by)_([_a-zA-Z]\w*)/.match(sym.to_s)
      return find_by_(match, args, &block)
    elsif match = /find_or_create_by_([_a-zA-Z]\w*)/.match(sym.to_s)
      return find_or_create_by_(match, args, &block)
    else
      super
    end
  end

(Note: In this case, it appears Og _always_ handles the
request via method_missing.  But I've seen other code
in Og (or maybe Nitro) that did *define* the method when
it was first called, such that on subsequent invocations
the method would now already be existing.)

. . . Anyway, the point being, Ruby is pretty dynamic.

:)


> Python's integrated documentation would be really welcome in this  
> case, i think. :)

I seem to recall mention awhile back on ruby-talk of
a gem or module that integrated `ri` into `irb`, such
that one could pull up the documentation from within
irb.  (I don't have any links for that, sorry.)


Regards,

Bill