[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

object_* and instance_* methods

Daniel DeLorme

3/1/2007 1:03:00 AM

A while back there was a proposal to use a standard naming scheme for
meta-programming methods. It went like this:

object_id
object_class (instead of class)
object_send (instead of send)
object_method (instead of method)

Then for all the methods that bypass access restrictions:

instance_send (instead of funcall)
instance_eval
instance_exec
instance_variable_get
instance_variable_set
instance_variables

The discussion didn't go much farther then but I'd like to reignite the
bikeshed. Personally I think it's a brilliant idea; sure the method
names are longer but that seems perfectly acceptable to me since
meta-programming should not be used that often. The naming is consistent
and obvious, it avoids ugliness like __send__, it reduces chances of
naming conflict (CgiRequest#method, Email#send), it allows a simple
pattern match to recognize any meta-programming methods, and it's
already half implemented. Are there any other people who support this idea?

Daniel
37 Answers

dblack

3/1/2007 2:51:00 AM

0

Daniel DeLorme

3/1/2007 3:49:00 AM

0

dblack@wobblini.net wrote:
> Why object_method?

1. consistence: it's a meta-programming method
2. avoid collisions: e.g. ActionController::CgiRequest#method

You could even restrict object_method to public methods and use
instance_method to bypass access restrictions. It sounds like a
proliferation of methods but if they are properly isolated under
a namespace, does it really matter how many methods there are?

> I wish there were a way to name these without components to the name
> that you have to "just know". I actually don't know the difference
> between instance_eval and instance_exec, and I suspect I will be
> looking it up frequently in the future :-)

Hey! Same for me! :-D

Daniel

dblack

3/1/2007 11:54:00 AM

0

Trans

3/5/2007 5:35:00 PM

0



On Mar 1, 6:53 am, dbl...@wobblini.net wrote:
> Hi --
>
> On Thu, 1 Mar 2007, Daniel DeLorme wrote:
> > dbl...@wobblini.net wrote:
> >> Why object_method?
>
> > 1. consistence: it's a meta-programming method
>
> They're all just methods, though. I'm uneasy with assigning clusters
> of methods to super-categories. I think the results are better in the
> end if choices are made at a more granular level: find the best name
> for exactly what a given method is purporting to do. Clustering is
> itself a "meta"-thing.

Yet the methods we're talking about in particular are rather "meta"-
things.

Naming convention are very powerful b/c they ease the burden on the
human mind , simplifying complexities, thus easing learning and
allowing for higher abstraction. Case in point I was recently asked to
add Module#instance_method? to Facets. My immediately thought was,
"great idea", since I instantly knew what was being asked by the name
of it. Only thing is, when I went to implement it, I realized we
already had it --it would just be an alias for #method_defined?.
method_defined? is an okay name for this functionality, but
instance_method? is better because it conforms to a recognizable
pattern along with #instance_method and #instance_methods. This may
not seem like much, but many small things can quickly add up.

I think Richard Feynman said it best, "never underestimate the power
of notation", or something like that.

T.

dblack

3/5/2007 6:19:00 PM

0

Trans

3/5/2007 7:59:00 PM

0



On Mar 5, 1:19 pm, dbl...@wobblini.net wrote:
> Hi --
>
> On Tue, 6 Mar 2007, Trans wrote:
> > I think Richard Feynman said it best, "never underestimate the power
> > of notation", or something like that.
>
> I don't underestimate it -- I just don't like the idea of decisions
> being made about naming on the basis of membership in a category like
> "metaprogramming".

I think you are though, becuase beloging to this category isn't the
basis. That just happens to be the case. The basis is the beneficial
effect that the naming would have on coding, in particular the effect
on method_missing and privatizing or removing all methods that don't
start with instance_ and object_, as well as the effect it would have
on one's ability to more easily learn and use Ruby.

T.

dblack

3/5/2007 8:17:00 PM

0

On 3/5/07, Trans <transfire@gmail.com> wrote:
>
>
> On Mar 5, 1:19 pm, dbl...@wobblini.net wrote:
> > Hi --
> >
> > On Tue, 6 Mar 2007, Trans wrote:
> > > I think Richard Feynman said it best, "never underestimate the power
> > > of notation", or something like that.
> >
> > I don't underestimate it -- I just don't like the idea of decisions
> > being made about naming on the basis of membership in a category like
> > "metaprogramming".
>
> I think you are though, becuase beloging to this category isn't the
> basis. That just happens to be the case. The basis is the beneficial
> effect that the naming would have on coding, in particular the effect
> on method_missing and privatizing or removing all methods that don't
> start with instance_ and object_, as well as the effect it would have
> on one's ability to more easily learn and use Ruby.

Have another look at the thread. Daniel was adducing
metaprogramming-ness as a reason for naming methods a certain way, not
something that happens to be the case. I was discussing this and
expressing misgivings about that approach.

In any case, you're talking about metaprogramming operations *on*
method names (removing them, using method_missing), which is different
from the matter of naming methods because what those methods do is
metaprogramming. I think that, too, is a tricky road to travel. I'd
rather see each method have the best possible name, since it's going
to be used more as a method than as a string to be matched for method
removal purposes and so forth. Moreover, it's very hard to predict
exactly which batch of methods someone is going to want to remove;
they may or may not all fall into a secondary category like
metaprogramming.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning...)
(See what readers are saying! http://www.r.../r...)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.r...)

Trans

3/6/2007 1:13:00 AM

0



On Mar 5, 3:17 pm, "David A. Black" <dbl...@wobblini.net> wrote:
> Have another look at the thread. Daniel was adducing
> metaprogramming-ness as a reason for naming methods a certain way, not
> something that happens to be the case. I was discussing this and
> expressing misgivings about that approach.

Yes he was, but as a consequence of other needs, not just because
there is such a category. So that my point: any argument against doing
this based on the fact that it's a catagorization, I feel is missing
the point. No other cataegories are being considered. It's not about a
general pattern of naming methods according to categories. Rather it's
one paticular set of methods that have some special needs/uses that
would be better served by a consistant naming pattern.

> In any case, you're talking about metaprogramming operations *on*
> method names (removing them, using method_missing), which is different
> from the matter of naming methods because what those methods do is
> metaprogramming.

Yes, exactly. And I think this is what Daniel really meant too.

> I think that, too, is a tricky road to travel. I'd
> rather see each method have the best possible name, since it's going
> to be used more as a method than as a string to be matched for method
> removal purposes and so forth.

Well, what is best? That's the very question. Figuring out what is
best means taking into account all the uses. Yes, plain usage is
important, so we don't really want methods that are too long or
esoteric. Is that the criteria you are using? Yet there are other
important considerations. An important one being that "meta" methods
be easily discernable so they can be readuly worked around in
delegators --and delegators are very common in OOP. To me it's just a
big bonus that this works out to a pattern that is already largely
(subconsciously?) followed in Ruby, namely using the prefixes object_
and instance_, and consequently brings all the benefits of quick
recognition and eased learning. So again, what is best?

> Moreover, it's very hard to predict
> exactly which batch of methods someone is going to want to remove;
> they may or may not all fall into a secondary category like
> metaprogramming.

It's quite easy really. Most of the time it's the same ones' b/c most
of the time is for delegation. And in a case of numerous exeptions,
we'd be no worse off then we were before anyway. Surely you must see
that?

T.

Daniel DeLorme

3/6/2007 8:47:00 AM

0

Trans wrote:
>> In any case, you're talking about metaprogramming operations *on*
>> method names (removing them, using method_missing), which is different
>> from the matter of naming methods because what those methods do is
>> metaprogramming.
>
> Yes, exactly. And I think this is what Daniel really meant too.

I meant both, really. I named about 5-6 "problems" that each benefited
from this naming scheme. Even though each of them was pretty small,
taken together I think they have weight. When one solution solves 5-6
problems, that's the smell of good design to me.

Daniel

Rick DeNatale

3/6/2007 8:55:00 PM

0

On 3/6/07, Daniel DeLorme <dan-ml@dan42.com> wrote:
> Trans wrote:
> >> In any case, you're talking about metaprogramming operations *on*
> >> method names (removing them, using method_missing), which is different
> >> from the matter of naming methods because what those methods do is
> >> metaprogramming.
> >
> > Yes, exactly. And I think this is what Daniel really meant too.
>
> I meant both, really. I named about 5-6 "problems" that each benefited
> from this naming scheme. Even though each of them was pretty small,
> taken together I think they have weight. When one solution solves 5-6
> problems, that's the smell of good design to me.

I don't have a dog in this fight, but I'm interested since it seems to
touch on naming and categorization.

I must have missed that list of 5-6 problems, a quick re-read of the
thread doesn't provide an obvious list, but maybe I'm just not reading
it right.

But I have to observe, that the problem with categories is that they
often appear to be universal, but actually turn out to be personal
and/or cultural.
There's an interesting cognitive linguistics book called "Women, Fire,
and Dangerous Things." by George Lakoff with all kinds of evidence of
this.

Maybe it's not a direct analogy to this thread, but the problem gets
more serious when you try to build hierarchical categories. Lakoff
points out that most languages and culture agree about the most basic
categories, rocks are rocks, trees are trees, and birds are birds. But
when those categories get sorted into hierarchies differences emerge.
My interest in this first arose when thinking about the limitations of
statically typed class/type hierarchies which force types into a
particular factoring.

I guess I'm wandering off the topic of this thread, but my reaction to
"When one solution solves 5-6 problems, that's the smell of good
design to me." is maybe, if those are MY 5-6 problems, and it doesn't
interfere with my solving other, possibly more important problems.

I'm not sure that this "Swiss army knife" approach to design is an
unalloyed good.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...