On 7/4/06, Austin Z. [email protected] wrote:
#instance_exec – which does what, exactly?
instance_exec() is instance_eval() with arguments that get passed
through to the block, e.g.
obj.instance_exec(42) {|x| instance_method_do_something_with(x) }
Regards,
Sean
On Wed, Jul 05, 2006 at 04:37:50PM +0900, Yukihiro M. wrote:
|
|??Succinctness.
You also mentioned performance in the past IIRC (on your blog?).
Hi,
In message “Re: About 1.9 #method feature.”
on Wed, 5 Jul 2006 06:26:14 +0900, [email protected] writes:
|> obj.funcall(:foo, 5) # Success. funcall can call private.
|
|what improvement does that give over
|
| obj.instance_eval{ send :foo, 5 }
|
|??
Succinctness.
matz.On Wed, Jul 05, 2006 at 12:35:29AM +0900, Logan C. wrote:
caller, it has to be the last bit of code in a method that uses it,
and it uses continuations (which are slow).
I once wrote another Binding.of_caller that didn’t use continuations and
it
was much faster. But the interface was ugly.
On 7/4/06, [email protected] [email protected] wrote:
|Will #funcall be the way that I can circumvent private?
obj.foo(5) # Throws an error, just as now.
obj.send(:foo, 5) # Throws an error, it’s private.
obj.funcall(:foo, 5) # Success. funcall can call private.
what improvement does that give overobj.instance_eval{ send :foo, 5 }
i mean, what’s the purpose of a public method which can call private methods?
Would obj.instance_eval { send(:foo, 5) } allow the call of private
methods? However, the purpose is that #send (and #send) allow the
call of private methods already. The change in 1.9 is that #send
doesn’t allow, but people depend on that, and it seems to me that
#instance_eval (or #instance_exec – which does what, exactly?) would
be heavier weight than an explicit method.
-austin
Hi –
On Wed, 5 Jul 2006, Yukihiro M. wrote:
|
|??Succinctness.
Until people start saying, “Wait – I thought these things were called
‘methods’ in Ruby. What’s a ‘function’? Is it a method? Is it just
a method without an explicit receiver? And does that mean you can
never ‘funcall’ a setter method, since they always require an
explicit receiver? But when you ‘funcall’ a symbol, you’re not using
method-call syntax anyway, so the idea of an ‘explicit receiver’ is
irrelevant and meaningless. Is there a ‘function’ method, similar to
‘method’ but including private methods? But why are private methods
called ‘methods’ at all, if they’re ‘functions’ in 1.9?..”
Then it gets less succinct 
I’m afraid I still don’t know the
answers to these questions. I do understand the “functional style”
method call (though I don’t understand how it relates to “funcall”,
since funcall isn’t done in a functional style). But I’ve always
thought that functional style was one of these things that grew
organically out of the design of the language, without having to be
named and ingrained at the language level:
method call
= functional style
Now it seems like this:
method call <--------------------------------
% explicitness of receiver ^
------------------------ ^
= whoops – “method” should have been “function” ^
and also:
obj.funcall(:meth)
% if this were a lexical method call,
would the receiver have been explicit?
----------------------------------------
= decision whether “funcall” was calling a method or a function
It all seems so non-linear, doesn’t it?
David
Austin Z. wrote:
Meta.implicit_send(obj, :foo, 5) # succeeds on private
It does seem appropriate that introspection be handled externally. I
sort like the idea of global functions:
$object_id(obj)
$send(obj, :foo, 5)
$funcall(obj, :foo, 5)
That certianly makes it clear one is in the meta programming realm. But
do we need to go so far?
Well, I think something is in order. As it is the meta programmer is
roughing it, with things like you’re binding example. When meta
programming it’s important to have garunteed way to get the object_id
and other such information about an object. It’s also important to be
able to bypass method privacy.
So what if we followed a simple rule that all methods starting with
#object_ or #instance_ were not overridable? And we could add
#object_send and #instance_send. The former always routes to the Object
binding and the later bypasses privacy. With a few other adjustments
(eg. object_class, object_tainted?, etc.) I think that would be an
effective and straight foward solution.
T.
Hi,
In message “Re: About 1.9 #method feature.”
on Wed, 5 Jul 2006 20:00:08 +0900, [email protected] writes:
|Until people start saying, "Wait – I thought these things were called
|‘methods’ in Ruby. What’s a ‘function’? Is it a method? Is it just
|a method without an explicit receiver?
But we already have module_function, which has never been complained
for more than 10 years. I think it’s OK to meet small confusion for
the first timers, if we can use the name with right mnemonic for the
functionality. Probably the reason behind the funcall is my Lisp
background.
matz.On 7/7/06, Yukihiro M. [email protected] wrote:
… I think it’s OK to meet small confusion for
the first timers, if we can use the name with right mnemonic for the
functionality. Probably the reason behind the funcall is my Lisp
background.matz.
How about instance_send (on analogy with instance_eval and
instance_exec)?
Regards,
Sean
Hi –
On Fri, 7 Jul 2006, Yukihiro M. wrote:
for more than 10 years. I think it’s OK to meet small confusion for
the first timers, if we can use the name with right mnemonic for the
functionality. Probably the reason behind the funcall is my Lisp
background.
I’m not a first timer though, and I find it confusing You’re
right about module_function, but it also (in my experience) doesn’t
get used much.
The functionality we’re talking about, as I understand it, is: send a
message to an object, with the stipulation that the object treat the
message indifferently with respect to the access level of the method
(if any) that corresponds to the message.
To me, that leads to things like send! or absolute_send or inner_send
or instance_send (which I think Sean O’Halpin just suggested). It’s
still basically a “send” operation.
The part I don’t understand is why the inclusion of private methods
suddenly makes it something other than a “send” – why it requires a
(basically) new concept, the concept of objects having “functions” and
responding directly to “call” requests.
David
Hi –
On Fri, 7 Jul 2006, Yukihiro M. wrote:
|
|message indifferently with respect to the access level of the method
|(if any) that corresponds to the message.Right, if I understand the work stipulation correctly.
Basically a condition imposed.
invokes a method; “funcall” invokes a function. In Ruby, “send”
invokes a method; “funcall” invokes a method in functional style.
Then it’s not really taken from Lisp
They are short names for mnemonic. There should be official, longer
orthogonal, and exact names for the functionality. I proposed
“invoke_method” and “invoke_functional_method”, but they are not final
decision.
I’m probably going in circles, but I’m not seeing a functional-style
method call here:
obj.funcall(:meth)
funcall itself isn’t being called functionally, and meth isn’t being
called at all – that is, you don’t see this in the program:
meth
and therefore it’s impossible, I think, to talk about the “style” of
the “method invocation”.
If I’m not convincing you, maybe I can suggest:
invoke_method_functionally
instead of invoke_functional_method. I honestly don’t think either of
them is perfect, but it would be probably be better not to introduce
the separate notion of a “functional method”, since the same method
can be invoked in different ways.
David
Hi,
In message “Re: About 1.9 #method feature.”
on Fri, 7 Jul 2006 22:49:11 +0900, [email protected] writes:
|> “send” and “funcall” are both taken from lisp function names; “send”
|> invokes a method; “funcall” invokes a function. In Ruby, “send”
|> invokes a method; “funcall” invokes a method in functional style.
|
|Then it’s not really taken from Lisp
OK, it’s inspired by Lisp functions.
|I’m probably going in circles, but I’m not seeing a functional-style
|method call here:
|
| obj.funcall(:meth)
|
|funcall itself isn’t being called functionally, and meth isn’t being
|called at all – that is, you don’t see this in the program:
|
| meth
|
|and therefore it’s impossible, I think, to talk about the “style” of
|the “method invocation”.
Hmm, I think I understand your point. Let me think about it.
|If I’m not convincing you, maybe I can suggest:
|
| invoke_method_functionally
I agree this is better than invoke_functional_method. I am still
looking for the better name.
|instead of invoke_functional_method. I honestly don’t think either of
|them is perfect, but it would be probably be better not to introduce
|the separate notion of a “functional method”, since the same method
|can be invoked in different ways.
Point taken (about invoke_method_functionally).
matz.Hi,
In message “Re: About 1.9 #method feature.”
on Fri, 7 Jul 2006 21:30:03 +0900, [email protected] writes:
|> But we already have module_function, which has never been complained
|> for more than 10 years. I think it’s OK to meet small confusion for
|> the first timers, if we can use the name with right mnemonic for the
|> functionality. Probably the reason behind the funcall is my Lisp
|> background.
|
|I’m not a first timer though, and I find it confusing You’re
|right about module_function, but it also (in my experience) doesn’t
|get used much.
I think you’re still a first timer to the term “funcall” in Ruby. 
Anyway, my point is whether funcall etc. would work as good mnemonic
or not, after users get used to them.
|The functionality we’re talking about, as I understand it, is: send a
|message to an object, with the stipulation that the object treat the
|message indifferently with respect to the access level of the method
|(if any) that corresponds to the message.
Right, if I understand the work stipulation correctly.
|To me, that leads to things like send! or absolute_send or inner_send
|or instance_send (which I think Sean O’Halpin just suggested). It’s
|still basically a “send” operation.
|
|The part I don’t understand is why the inclusion of private methods
|suddenly makes it something other than a “send” – why it requires a
|(basically) new concept, the concept of objects having “functions” and
|responding directly to “call” requests.
“send” and “funcall” are both taken from lisp function names; “send”
invokes a method; “funcall” invokes a function. In Ruby, “send”
invokes a method; “funcall” invokes a method in functional style.
They are short names for mnemonic. There should be official, longer
orthogonal, and exact names for the functionality. I proposed
“invoke_method” and “invoke_functional_method”, but they are not final
decision.
matz.On 7/7/06, Yukihiro M. [email protected] wrote:
|If I’m not convincing you, maybe I can suggest:
|
| invoke_method_functionallyI agree this is better than invoke_functional_method. I am still
looking for the better name.
This is for an implicit-receiver mechanism, right? Why not:
invoke_method # send in 1.9
invoke_implicit_method # funcall in 1.9
OR:
invoke_method_implicitly # funcall
OR:
invoke_method_with_implicit_receiver
The last is a joke. Mostly.
-austin
On Jul 7, 2006, at 10:23 AM, Yukihiro M. wrote:
|Then it’s not really taken from Lisp
|matz.
Steal another name from lisp?
obj.apply(:meth, 1, 2, 3)
It’s not send, but it’s not funcall either.
obj apply your :meth function to the arguments 1,2,3
Just throwing stuff out there, feel free to ignore me
On Fri, 7 Jul 2006 [email protected] wrote:
I’m probably going in circles, but I’m not seeing a functional-style
method call here:obj.funcall(:meth)
yet one is implied. just as
attr ‘a’
doesn’t show a meta-programming-style method. one can imagine it’s
syntax,
yet meta-programming is done.
nothing in ruby can be purely functional. even if you write everything
as in
this = lambda {
that = lambda {
}
}
you can turn around and do
this.inspect # oops, object call
nonetheless
obj.funcall :meth
says to turn the call into a recieverless message, one in which self is
implied, and thus it looks like a functional call bound in the context
of self
so private calls can be made.
i think it’s fair to say the closest one can come to ‘functional’ style
in
ruby is to use recieveless messages, eg
def foo() bar end
def bar() 42 end
bar # pretend functional. really it’s self.bar of course
it just so happens that this is also the requirement to call private
methods
in ruby so a public interface to accomplish receiverless messages
effectively
gets inside the object and becomes a private ‘send’.
i finally decided that i like funcall because i realized it’s not
only an
instance_eval{ send msg }
but is simply a generic way of doing receiverless calls. there are
other
possible uses for this technique and so a more generic name than
‘instance_send’, etc. is appropriate.
that’s not to say an alias shouldn’t exist, however. why not funcall
and
alias_method ‘send!’, ‘funcall’
or
alias_method ‘instance_send’, ‘funcall’
matz?
funcall itself isn’t being called functionally
indeed. it’s calling ‘meth’ functionally.
, and meth isn’t being called at all – that is, you don’t see this in the
program:meth
that’s a bit weak. as programmers i think we can all agree that tons of
methods get ‘called’ even though we don’t see them. that’s the very
idea
behind abstraction after all - you don’t think people don’t realize that
belongs_to …
actually ‘calls a bunch of stuff’ do you? anyhow, i think that even a
below
average ruby coder has no issue understanding that some methods call
many
others behind the scenes.
and therefore it’s impossible, I think, to talk about the “style” of the
“method invocation”.
but it’s only one layer of abstraction deep? we could easily reason to
ourselves, while coding, that we needed a way to call private methods
and
start using
obj.instance_eval{ send msg }
after we did this three or four times we could abstract it into
funcall = lambda{|obj, msg, *a| obj.instance_eval{ send msg, *a }}
and away we’d go
funcall[ list, :push, 42 ]
now it’s two layers of code reading to say that the style of method
invocation
is receiverless and that’s it’s preciesly that feature, that of having a
receiver, that makes a method call ‘object oriented’. note that’s it’s
also
not a purely procedure call because
send msg, *a
has the notion of context as in
let self = me in
send msg, *a;;
and it’s this context, combined with the lack of an explicit receiver
that
gives a functional flavour.
regards.
-a
Sean O’Halpin wrote:
How about instance_send (on analogy with instance_eval and instance_exec)?
+1
Why make this more complex than it needs to be? #instance_send is
reasonably obvious, #fucncall is not at all and is only menaingful to
lispers and brings in a whole new set of concepts about “functional
style”.
T.
On Fri, 7 Jul 2006, Logan C. wrote:
Steal another name from lisp?
obj.apply(:meth, 1, 2, 3)
It’s not send, but it’s not funcall either.
obj apply your :meth function to the arguments 1,2,3
Just throwing stuff out there, feel free to ignore me
i was just about to suggest that name. still, there is nothing which
implies
are receiverless context sensitive call that can access private methods
with
that name is there? (see my post to david). nonetheless i like this
name.
cheers.
-a
On Fri, 7 Jul 2006 [email protected] wrote:
style".
consider:
harp:~ > cat a.rb
class Object
def funcall(*a, &b) instance_eval{ send *a, &b } end
alias_method ‘instance_send’, ‘funcall’
end
module A
private
def A.m() p 42 end
end
module B
private
def B.m() p ‘forty-two’ end
end
A.funcall ‘m’
B.funcall ‘m’
A.instance_send ‘m’
B.instance_send ‘m’
harp:~ > ruby a.rb
42
“forty-two”
42
“forty-two”
with funcall we can consider modules as namespaces, each of which
defines an
‘m’ method and in whose context ‘m’ can be called. if you’ve been
coding ruby
for a while you can probably easily read over the
A.instance_send ‘m’
B.instance_send ‘m’
lines. but to newbies, or even non-newbies, the
‘modules are instances of a Module class which is a Class which is a
Module
which are both Objects’
circular thinking makes it slightly less than intuitive as to the reason
one
can call ‘instance’ methods on modules or classes.
the receiveless context sensitive paradigm, although a new concept, is
orthoganal to public/private and instance/class/module and can be
expained
rather simply: if one does
obj.funcall :meth, 42
it’s always like being ‘inside’ the object, which means in an
instance
method for instances and insides a class definition for classes, etc,
and
doing
meth, 42
2 cts.
-a
Hi –
On Fri, 7 Jul 2006, [email protected] wrote:
Just throwing stuff out there, feel free to ignore me
i was just about to suggest that name. still, there is nothing which implies
are receiverless context sensitive call that can access private methods with
that name is there?
No – which is why I like it much more than ‘funcall’ and such It
doesn’t introduce the criterion of “receiverlessness” into a situation
where the concept of having or not having a receiver isn’t relevant.
David
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs