Re: what's an object?

Fair enough.  The link even cites the Ruby spec to indicate that
methods, technically, are not/do not have to be an object.

However, there is much to support that it is not at all a conceptual
error to consider a method an object, even if the technical
implementation is different.

Consider that Ruby is a dynamically-typed language, frequently described
as duck-typed.  If a Method object has attributes, such as #arity and
even #class, and methods like #call or #to_s, it sure looks like an
object to me.  Also consider that Ruby by design is intended not to get
in the programmer's way, the way a language like PHP or Perl might,
because of its dynamic features and flexibility.  

One does not need to know the internal details - such as "the 4th and
5th paragraphs of Section 6.1 of the Ruby Language Specification (lines
29-34 and 1-5 on pages 5 and 6)" - to be an effective programmer in
Ruby.  Does knowing those details give a programmer more options and a
better understanding of the source-to-machine connection and the
physical operation of their code?  Absolutely.  But does assuming that
methods look like an object, and act like an object, and ignoring the
underlying mechanisms (the black box effect), make a Ruby programmer
less capable or likely to introduce bugs?  Probably not.

In fact, I would reference Russ Olsen's excellent "Design Patterns in
Ruby" at this point.  In Ch.2 of a very heavily abstracted, conceptual
text (yet also quite practical, but I digress...), he states explicitly
that everything is an object.  He also says that, in the case of numeric
assignment like 'x = 44', that "...x receives a reference to an object
that happens to represent the number after 43."  That seems to be
remarkably similar to what happens in the case of the Method class,
where the user doesn't really need to know what's going on, and can
readily accomplish their task without concerning themselves with how 44
is referenced or represented or how Method wraps a method.

Great knowledge for interpreter hackers, but would assuming methods are
objects and getting on with it be problematic?  Would not knowing that
subtraction is accomplished through addition also be problematic?

I see there's some later posts now, so I'll hit send now.

Regards,


________________________________________________________________________

Alex Stahl | Sr. Quality Engineer | hi5 Networks, Inc. | [e-mail]
|  

On Thu, 2010-11-11 at 01:51 -0600, Y. NOBUOKA wrote:

> > Not that I know the internals of the language well enough to debate the
> > internal representation of a method, everything I've read suggests that,
> > at a conceptual level, they can be regarded as such.  Otherwise, how
> > would we reconcile this description from the Method class link?
> > (http://ruby-doc.org/core/classes/Method.html)
> >
> > meth == other_meth => true or false
> > "Two method objects are equal if that are bound to the same object and
> > contain the same body"
> >
> > Couldn't methods be considered specialized proc objects bound to a
> > particular instantiation of an object?
> 
> A Method object (= an instance of the Method class) is an object.  But
> it is not a method.  It can be considered as a wrapper of the method
> which is bound to an object.
> 
> We should think that a Method object is a thing that is different from
> a method.
> 
> Please see also:
> http://stackoverflow.com/questions/2602340/methods-in-ruby-objects-or-not
> 
> ---
>  Methods are a fundamental part of Ruby's syntax, but they are not
> values that Ruby programs can operate on.  That is, Ruby's methods are
> not objects in the way that strings, numbers, and arrays are.  It is
> possible, however, to obtain a Method object that represents a given
> method, and we can invoke methods indirectly through Method objects.
> --- From "The Ruby Programming Language" [
> http://www.amazon.com/dp/0596516177/ ]
>