Rails - Jan 2011 - Why use send when you can call the method directly?

I am reading through some code in active_record/relation/query_methods - def 
build_where (about line 230); and there are a couple of calls to send. 
 Here''s the first one
[@klass.send(:sanitize_sql, other.empty? ? opts : ([opts] + other))]

and here''s the second one
attributes = @klass.send(:expand_hash_conditions_for_aggregates, opts)

Why do we use send here when we could just call the method directly?
I mean, why is the first call not just
[@klass.sanitize_sql( other.empty? ? opts : ([opts] + other))]

Puzzled.

William

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

William Fisk wrote in post #977984:
> I am reading through some code in active_record/relation/query_methods -
> def
> build_where (about line 230); and there are a couple of calls to send.
>  Here''s the first one
> [@klass.send(:sanitize_sql, other.empty? ? opts : ([opts] + other))]
>
> and here''s the second one
> attributes = @klass.send(:expand_hash_conditions_for_aggregates, opts)
>
> Why do we use send here when we could just call the method directly?
> I mean, why is the first call not just
> [@klass.sanitize_sql( other.empty? ? opts : ([opts] + other))]
>
> Puzzled.
The only reason I could see to do this would be to get around an access 
prohibition.  You can use send in this way to call a private or 
protected method.
>
> William
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Ah, thanks, yes that will probably be the reason.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Thu, Jan 27, 2011 at 4:01 PM, William Fisk
<william.fisk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:
> Ah, thanks, yes that will probably be the reason.

Right... send comes in real handy in testing private methods, use it all the
time
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

David Kahn wrote in post #978011:
> On Thu, Jan 27, 2011 at 4:01 PM, William Fisk
> <william.fisk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:
>
>> Ah, thanks, yes that will probably be the reason.
>
>
> Right... send comes in real handy in testing private methods, use it all
> the
> time
Then you''ve got bigger problems.  You shouldn''t be testing
your private
methods; that''s poking too deeply into an object''s
implementation.  You
should only ever test things that can be called from outside an object.

If a private method is an intermediate value in a computation, just test 
the end result.  If a private method really needs to be tested 
separately, then it''s telling you that it wants to be public.

Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

Sent from my iPhone

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

The @klass variable also could == some_object.class
If this is the case, then it could be a class method call, but still
don''t see the necessity to use #send.
--
Thanks, Ivan Povalyukhin


On Jan 27, 6:39 pm, Marnen Laibow-Koser
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> David Kahn wrote in post #978011:
>
> > On Thu, Jan 27, 2011 at 4:01 PM, William Fisk
> > <william.f...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:
>
> >> Ah, thanks, yes that will probably be the reason.
>
> > Right... send comes in real handy in testing private methods, use it
all
> > the
> > time
>
> Then you''ve got bigger problems.  You shouldn''t be
testing your private
> methods; that''s poking too deeply into an object''s
implementation.  You
> should only ever test things that can be called from outside an object.
>
> If a private method is an intermediate value in a computation, just test
> the end result.  If a private method really needs to be tested
> separately, then it''s telling you that it wants to be public.
>
> Best,
> -- 
> Marnen Laibow-Koserhttp://www.marnen.org
> mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
>
> Sent from my iPhone
>
> --
> Posted viahttp://www.ruby-forum.com/.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Thu, Jan 27, 2011 at 8:39 PM, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>wrote:
> David Kahn wrote in post #978011:
> > On Thu, Jan 27, 2011 at 4:01 PM, William Fisk
> > <william.fisk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:
> >
> >> Ah, thanks, yes that will probably be the reason.
> >
> >
> > Right... send comes in real handy in testing private methods, use it
all
> > the
> > time
>
> Then you''ve got bigger problems.  You shouldn''t be
testing your private
> methods; that''s poking too deeply into an object''s
implementation.  You
> should only ever test things that can be called from outside an object.
>
> If a private method is an intermediate value in a computation, just test
> the end result.  If a private method really needs to be tested
> separately, then it''s telling you that it wants to be public.
>
I disagree -- for me public is what I want to expose to outside access,
regardless of complexity or size, where the private logic may actually be
the most complex, being called by a relatively light public function. Now
this may be a difference between TDD and BDD in pure forms, but for me I
find if I drive my methods, public or private with test first, that the end
resulting code is much more pliable. Also, if I have coverage on what
becomes complex private logic, at a more granular level -- then I have a
much stronger project an also address minute issues closer to the source. I
am sure you have your method of working that works for you, this is what I
have found effective and successful.
>
> Best,
> --
> Marnen Laibow-Koser
> http://www.marnen.org
> marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
>
> Sent from my iPhone
>
> --
> Posted via http://www.ruby-forum.com/.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

David Kahn wrote in post #978200:
> On Thu, Jan 27, 2011 at 8:39 PM, Marnen Laibow-Koser
> <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>wrote:
>
>>
>> Then you''ve got bigger problems.  You shouldn''t be
testing your private
>> methods; that''s poking too deeply into an object''s
implementation.  You
>> should only ever test things that can be called from outside an object.
>>
>> If a private method is an intermediate value in a computation, just
test
>> the end result.  If a private method really needs to be tested
>> separately, then it''s telling you that it wants to be public.
>>
>
> I disagree -- for me public is what I want to expose to outside access,
And therefore it is the only thing that is worth testing.  No one cares 
what your private logic is like, because they never see it.
> regardless of complexity or size, where the private logic may actually
> be
> the most complex, being called by a relatively light public function.
Then test the return from the "light" public function, or make your 
private logic public.
> Now
> this may be a difference between TDD and BDD in pure forms, but for me I
> find if I drive my methods, public or private with test first, that the
> end
> resulting code is much more pliable.
No private method should have a test at all.  That''s testing 
implementation, and therefore is bad.  You want to test interface only.
> Also, if I have coverage on what
> becomes complex private logic, at a more granular level -- then I have a
> much stronger project an also address minute issues closer to the
> source.
No!  All you have is brittle, implementation-dependent tests.  What you 
*think* is improving the quality of your code is actually hindering it.
> I
> am sure you have your method of working that works for you, this is what
> I
> have found effective and successful.
But it is neither.  This is a matter of principles, not taste.  Please 
do not handwave away what I am telling you by saying that it is a matter 
of taste -- these are principles you need to understand.  If you want to 
disagree after you understand the principles, I will be interested to 
hear your reasoning.

It is *ineffective* to test private methods because you never care about 
the return value from a private method as such -- if you cared about the 
return value, you''d have made the method public.

It is *unsuccessful* to test private methods because you are tying your 
tests too closely to implementation, which means they will fail if you 
change your implementation -- this despite the fact that one of the 
points of testing is to tell you that your code still works when you 
refactor your implementation.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Jan 28, 2011, at 11:55 AM, David Kahn wrote:
> If a private method is an intermediate value in a computation, just test
> the end result.  If a private method really needs to be tested
> separately, then it''s telling you that it wants to be public.
> 
> I disagree -- for me public is what I want to expose to outside access,
regardless of complexity or size, where the private logic may actually be the
most complex, being called by a relatively light public function. Now this may
be a difference between TDD and BDD in pure forms, but for me I find if I drive
my methods, public or private with test first, that the end resulting code is
much more pliable. Also, if I have coverage on what becomes complex private
logic, at a more granular level -- then I have a much stronger project an also
address minute issues closer to the source. I am sure you have your method of
working that works for you, this is what I have found effective and successful.
I would say that Marnen''s position is very consistent from what I see
from Kent Beck and others on the XP/TDD lists. It took me a while to get used to
the approach, and I think it''s important to clarify that Marnen
isn''t saying not to test complex private methods. He''s just
saying that if they are complex, maybe you''ve discovered another
composed object''s public method. SRP and all that . . .

Best Wishes,
Peter

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Peter Bell wrote in post #978204:
[...]
> I would say that Marnen''s position is very consistent from what I
see
> from Kent Beck and others on the XP/TDD lists.
The XP crowd have been a major influence on my testing philosophy, even 
though I''ve never done XP as such.
> It took me a while to get
> used to the approach, and I think it''s important to clarify that
Marnen
> isn''t saying not to test complex private methods.
Well, I guess I sort of *am* saying that, but only in the sense that you 
probably shouldn''t *have* complex private methods that need their own 
tests -- that is, if your private methods are that complex, they should 
be made public and/or decomposed.
> He''s just saying that
> if they are complex, maybe you''ve discovered another composed
object''s
> public method.
Or the same object''s public method, or a method that is too long...

> SRP and all that . . .
I suppose.  Basically, I think if you have a private method that is 
complex enough that wants to be tested in isolation, then that is a 
symptom of an underlying design problem: your methods are insufficiently 
accessible, or insufficiently atomic, or your code is otherwise 
insufficiently modular (say, by virtue of needing a new class 
introduced).  Fix the underlying problem and the need for 
"so-big-it-needs-its-own-tests" private methods will go away.
>
> Best Wishes,
> Peter
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.