Hi Luke.  Thanks for the reply. 

BTW is there any beef about top-posting in here?  I know some people get all huffy with that.  Having to scroll past a quotation is my beef with bottom posting.  

Yeah the syntax and nomenclature is what's going to bog me down.  Once it's flushed out (as was with my first little project), it's all good.  Type vs. Class, Map vs. Hash, those are the things I have to get syntactic examples down in BBEdit for me to really move forward.  I have to get used to the Core Reference as well. 

Some of those methods are quite useful.  I was writing some kind of Rails for the previous language I was using, and inheritance was a bit of a PITA because abstraction was quite difficult due to the reference of inherited attributes of an object.  So here I am in Rubyland.  


Cheers

_____________
Rich in Toronto

On 2011-10-05, at 10:45 PM, luke gruber wrote:

> In Ruby, the type is not really synonymous with the
> object's class, but has more to do with the methods the object
> responds to.
> 
> So normally Rubyists use class to mean the Class, and 'type'
> is sort of a grey-area word.
> 
> But, more practically, object.methods will return all the methods that bject responds to.
> 
> object.class.instance_methods(false) will return all methods the object
> responds to that were defined in its class but not its class's 
> superclass(es).
> 
> object.respond_to? :methodname will return true/false depending whether 
> or
> not the object responds to that method name.
> 
> object.class.ancestors will return an array of the inheritance chain of 
> the object's class (superclasses and mixed in modules).
> 
> There's also object.is_a? ClassName, which is kind of like the 'type' of
> an object, in that it will respond true if ClassName is a superclass of 
> object's class (or mixed in module).
> 
> And finally, object.instance_of? ClassName checks if ClassName is the irect class, but not superclass, of object.
> 
> Hope that helps!
> (and sorry for the length...)