About 1.9 #__method__ feature

Ruby
81

Hi –

On Sat, 8 Jul 2006, [email protected] wrote:

It’s not send, but it’s not funcall either.

No – which is why I like it much more than ‘funcall’ and such :slight_smile: It
doesn’t introduce the criterion of “receiverlessness” into a situation
where the concept of having or not having a receiver isn’t relevant.

Just to follow up and clarify:

I’m not saying I think the method name shouldn’t express the fact that
it can call private methods. That’s why I’ve been advocating “send!”
(the “dangerous” version of send). I just think that
“receiverlessness” is a matter of concrete, visible coding style, and
not a language-level concept that has any meaning apart from how
method calls are actually expressed.

David

82

On 7/7/06, [email protected] [email protected] wrote:

It’s not send, but it’s not funcall either.
doesn’t introduce the criterion of “receiverlessness” into a situation
where the concept of having or not having a receiver isn’t relevant.

David

FWIW, I’m already using apply, i.e.:

module Enumerable
def apply(&block)
map {|i| i.instance_eval(&block) }
end
end

which seems more in keeping with its meaning in lisp (though not
really the same).

Regards,
Sean

83

On 7/7/06, [email protected] [email protected] wrote:

I just think that
“receiverlessness” is a matter of concrete, visible coding style, and
not a language-level concept that has any meaning apart from how
method calls are actually expressed.

David

Hi David,

I’m not sure I follow you here. Doesn’t the following show that it’s
not just a matter of coding style?

class Foo
def hi
puts “hi”
end
private :hi
def foo
hi
end
def bar
self.hi # will fail
end
end

f = Foo.new
f.foo
f.bar
#=>private method `hi’ called for #Foo:0x2868198 (NoMethodError)
#f.hi would also fail as expected

Regards,
Sean

84

Hi –

On Fri, 7 Jul 2006, [email protected] wrote:

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

Yes and no. It has the effect as self.bar, but it actually is this:

bar

namely, a bare word, on the screen (or in a file, or whatever) with no
explicit receiver.

‘instance_send’, etc. is appropriate.
I disagree. I don’t think there’s such a thing as a “receiverless
call”, outside of what’s actually visible to the eye. I don’t see any
advantage to stretching the term to mean something other than “a
method call without an explicit receiver”. It’s not even clear what
it would mean.

matz?

funcall itself isn’t being called functionally

indeed. it’s calling ‘meth’ functionally.

I’d say it’s sending the method “meth” to an object symbolically. I
don’t don’t see this as a functional-style call of “meth”. A
functional-style call of meth would look like this:

meth

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.

But that’s the whole issue: how what’s visible relates to what’s
behind the scenes. I like to keep the layers separate, not because we
don’t know that eventually “meth” gets called, but because
understanding it sequentially makes more sense of more cases.

This:

obj.send(:meth)

is, I think, best understood as “sending the message ‘meth’
symbolically to obj”. If you call it “calling the method ‘meth’”,
then you have to back-pedal to deal with things like method_missing,
private methods, and so on.

Yes, it’s convenient to talk about “calling meth on obj” when you do:

obj.meth

But it’s not entirely accurate, and once the layers are splayed out
with symbolic references to method names, I think it becomes quite
important not to collapse message-sending and method-calling.

Again, I’d rather just have simple names for what’s actually there,
rather than decide up front that it has to be called something else
and then decide what the best alternative name is.

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.

But I don’t want to go through two layers when I use a term like
“receiverless”. I want it to mean “without an explicit receiver”, not
“equivalent to what would be without an explicit receiver if it were
being used in a way that required a decision as to the inclusion or
exclusion of a receiver…”

I would say that when you do:

obj.send(:meth)

the “receiver/receiverless” status of the execution of the method
“meth” is undefined. There’s no opportunity for there to be or not be
a receiver; it’s not that kind of operation.

David

85

Hi –

On Sat, 8 Jul 2006, Sean O’Halpin wrote:

end
def bar
self.hi # will fail
end
end

f = Foo.new
f.foo
f.bar
#=>private method `hi’ called for #Foo:0x2868198 (NoMethodError)
#f.hi would also fail as expected

I don’t mean “matter of style” in the sense of “determined by
stylistic choice”. Rather, I mean that the whole concept of a
“receiverless” method call only has meaning with respect to the
actual typography of the language:

meth       # receiverless (implied receiver [self])
obj.meth   # with receiver (explicit receiver)

In fact, no method call is truly “receiverless”; there’s always a
receiver. So we’re using “receiverless” as shorthand for: typed in
the bareword style.

My disagreement with Ara is over whether there’s a notion of
“a receiverless method call” in the language, distinct from the
question of whether there is or is not an explicit receiver present.
I think there isn’t; I think that in a case like this:

obj.send(:meth)

the whole concept of whether or not there is an explicit receiver at
the moment that obj executes meth is meaningless.

That’s why I don’t accept the conclusion that obj.send(:meth)
represents a “functional-style” method call – that is, a bareword
method call. Rather, I believe that what’s happening is that a
message is being sent to an object, symbolically (i.e., at one
symbolic level of remove from the obj.meth mechanism).

If obj.send(:meth) can bypass the access-level mechanism and reach
private methods, it’s not because a receiverless method call has taken
place. It’s because send, like a receiverless method call, is
allowed access to private methods.

Similarly, when I do this:

class C
def b
end
private :b

def a
b
end
end

C.new.a

I do not say, “I have called ‘send’ on a C object and send it the
symbol :b”. In other words, there can be multiple paths to get to a
private method.

So ‘funcall’, intended to mean 'called in a functional (receiverless)
manner, makes no sense to me.

Does that help?

David

86

On Sat, 8 Jul 2006 [email protected] wrote:

I don’t mean “matter of style” in the sense of “determined by stylistic
choice”. Rather, I mean that the whole concept of a “receiverless” method
call only has meaning with respect to the actual typography of the language:

meth # receiverless (implied receiver [self])
obj.meth # with receiver (explicit receiver)

In fact, no method call is truly “receiverless”; there’s always a
receiver. So we’re using “receiverless” as shorthand for: typed in the
bareword style.

agreed.

My disagreement with Ara is over whether there’s a notion of “a receiverless
method call” in the language, distinct from the question of whether there is
or is not an explicit receiver present. I think there isn’t; I think that
in a case like this:

obj.send(:meth)

the whole concept of whether or not there is an explicit receiver at the
moment that obj executes meth is meaningless.

but not for ruby - it’s presisely this distintion that the language, for
better or worse, uses to allow private methods to be called.

If obj.send(:meth) can bypass the access-level mechanism and reach private
methods, it’s not because a receiverless method call has taken place. It’s
because send, like a receiverless method call, is allowed access to
private methods.

but that means there arr two mechanisms for determining access. that’s
complicated. why not keep it simple and explain it thusly:

private means you cannot have a recieve

funcall means you will not have a receiver

seriously, if you want two mechanisms to determine access control
then
that means patching the c code. if we keep one mechanism - receiverless
calls

  • matz is done.

so i ask, what would the exact (in c code terms) mechanism for

obj.send ‘meth’

being able to access private methods be??

end

C.new.a

I do not say, “I have called ‘send’ on a C object and send it the
symbol :b”.

yet i do :wink:

i do not distinguish from ‘calling methods’ and ‘sending message’.
indeed, i
think many from smalltalk or objective-c backgrounds would also not make
this
distiction.

it’s interesting how differently we think isn’t it!? :wink:

cheers.

-a

87

Hi –

On Sat, 8 Jul 2006, [email protected] wrote:

In fact, no method call is truly “receiverless”; there’s always a
in a case like this:
If obj.send(:meth) can bypass the access-level mechanism and reach private
methods, it’s not because a receiverless method call has taken place. It’s
because send, like a receiverless method call, is allowed access to
private methods.

but that means there arr two mechanisms for determining access. that’s
complicated. why not keep it simple and explain it thusly:

private means you cannot have a recieve

funcall means you will not have a receiver

Because that turns “not having a receiver” into a metaphor, instead of
something that’s actually manifest in the code.

i do not distinguish from ‘calling methods’ and ‘sending message’. indeed, i
think many from smalltalk or objective-c backgrounds would also not make this
distiction.

Many from a Ruby background don’t either :slight_smile: I don’t in casual usage,
but at the level where method names are forged based on what’s
happening, I think it plays a key role. That’s why send is send and
not call :slight_smile:

it’s interesting how differently we think isn’t it!? :wink:

Indeed :slight_smile:

David

88

On 7/7/06, [email protected] [email protected] wrote:

receiverless
but not for ruby - it’s presisely this distintion that the language, for

David

–
[snipped shameless self-promotion ;)]

OK - I think I get what you’re saying now. I’ll try to paraphrase (and
please correct me if I get this wrong).

Because in Ruby ~everything~ is an object then ~every~ method
(function, procedure) call is a message sent to an object. Therefore
there is no such thing as a receiverless method, whether or not that
receiver is explicitly specified or implicitly assumed.

So really the distinction is between implicit (unspecified) and
explicit (specified) receiver.

Is that the point you’re making? If so, I wholly agree.

By the way, I think you and Ara are saying the same thing but in
different ways. :wink:

Regards,
Sean

89

Hi –

On Sat, 8 Jul 2006, Sean O’Halpin wrote:

[snipped shameless self-promotion ;)]

Hey, I’m just the messenger :slight_smile:

Is that the point you’re making? If so, I wholly agree.

Yes, essentially. And that an implicit/explicit receiver is a matter
of actual code.

By the way, I think you and Ara are saying the same thing but in
different ways. :wink:

I actually don’t think so. I think we have a pretty different take on
what:

obj.send(:meth) # or funcall or whatever

means. My understanding is that Ara sees “receiverlessness” as the
master or “hub” condition that defines the invocation of a private
method – so that even if there’s no method call, lexically, it’s
still meaningful to refer to there having been a “receiverless method
call” if one can demonstrate that a private method has been executed.

By contrast, I see implicit-receiver method calls as one way to gain
access to private methods, and a programmatic/symbolic facility like
“funcall” as a different way to the same end. When I see this:

obj.funcall(:meth)

I know that a private method may be executed, but I don’t consider the
question “Was there an explicit receiver?” to be meaningful, any more
than the question “How many spaces are there after the method name
when obj calls it?” to be meaningful.

David

90

On Fri, Jul 07, 2006 at 11:58:34PM +0900, [email protected] wrote:

style".

T.

+2

I would like #send! too, or similiar variations. I don’t like #funcall
because even with lispers it may lead to wrong associations. Sure
people will get used to it, but why confound them in the first place?

And as mentioned elsewhere often enough, no method call (or message
sent) is really receiverless, it just may be without an explicit
receiver.

-Jürgen

91

On Jul 7, 2006, at 12:43 PM, Sean O’Halpin wrote:

that name is there?

Regards,
Sean

I disagree, yours is not especially closer to the Lisp meaning of
apply. The only difference (AFAIK) between Lisp’s funcall and Lisp’s
apply is how the argument list is expressed:

[1]> (funcall #’+ 1 2)
3
[2]> (apply #’+ '(1 2))
3

Of course this probably means we should have #funcall and #apply

obj.funcall(:meth, 1, 2)
obj.apply(:meth, [1, 2])

92

Yukihiro M. wrote:

It’s not conjunction with send etc. but with FILE and
LINE. Besides that, I am no longer fond of send and id,

I’m with you, ditch send and id. But why not ditch all the
__‘s if they are ugly, including FILE, LINE? What’s wrong with
globals: $LINE, $FILE, $METHOD, or better yet $line, $file, $method?
After all we use globals for lots of current things like $’ and
$stdin, and $FILENAME.

I’d rather like to remove them if it’s possible. Use invoke_method
and object_id respectively instead.

Please consider #object_send. The “object_” prefix indicates that it
something best left alone -ie. this is defined by object/kernel and you
override it only at your own peril! I think this is a great mnemonic
device. I also think #class ought to become #object_class (which would
also free us from having to use the receiver: self.class) That would
give us:

object_id
object_class
object_send

Then for the all methods that bypass access resitrictions:

instance_send
instance_eval
instance_exec
instance_variable_get
instance_variable_set
instance_variables

That way it’s consistant, intuitive, easy to use and easy to learn.

The only exceptions is #instance_of? But that’s moot if you ask me b/c
it’s safer to ask the class anyway. So preferably we would have
Class#class_of?(obj) plus a word alias for Module#=== like
Module#ancestor_of?(obj).

T.

93

On Sat, 8 Jul 2006 [email protected] wrote:

instance_variable_set
instance_variables

That way it’s consistant, intuitive, easy to use and easy to learn.

The only exceptions is #instance_of? But that’s moot if you ask me b/c
it’s safer to ask the class anyway. So preferably we would have
Class#class_of?(obj) plus a word alias for Module#=== like
Module#ancestor_of?(obj).

why not simply

send
send!

eval
eval!

exec
exec!

etc.

i like the idea - but those are long names! :wink:

-a

94

On 7/8/06, [email protected] [email protected] wrote:

object_send
That way it’s consistant, intuitive, easy to use and easy to learn.

+1

Sean

95

[email protected] wrote:

instance_variable_set
instance_variables

I agree with that proposal, and I think it underlines a fundamental
dichotomy
that I’ve been seeing in the discussion. Basically some people approach
this as
users; they want the names to reflect how the methods are used. And some
people
approach it as language designers; they want the names to reflect what
is
actually going on inside the interpreter. I think the first approach is
the
correct one; an interface is not supposed to reveal all the ugly or
complicated
or subtle details of the architecture within.

Daniel

96

On 7/8/06, Logan C. [email protected] wrote:

Steal another name from lisp?
which implies

obj.apply(:meth, [1, 2])

Don’t forget lisp is receiverless :wink: AFAIK apply is usually used to
apply a lambda with arguments to a list. So I think of apply as being
more like:

module Enumerable
def apply(*args, &block)
map{|x| x.instance_exec(*args, &block)}
end
end

But that’s only my interpretation.

Regards,
Sean

97

[email protected] wrote:

Maybe Sean was right that you and I are really saying the same thing
in different ways :slight_smile: At least, we seem to have converged on “send!”.

But Matz want’s to get away from #send, and for good reason – it’s too
likely to be overriden, which is the whole reason we ended up with
send. So by it’s very nature it needs to be more unique and there
are only two ways to achieve that: make it longer or make it esoteric.
I prefer longer.

T.

98

Hi –

On Sat, 8 Jul 2006, [email protected] wrote:

instance_exec

etc.

i like the idea - but those are long names! :wink:

Maybe Sean was right that you and I are really saying the same thing
in different ways :slight_smile: At least, we seem to have converged on “send!”.

David

99

On Sat, 8 Jul 2006 [email protected] wrote:

Maybe Sean was right that you and I are really saying the same thing
in different ways :slight_smile: At least, we seem to have converged on “send!”.

indeed - ‘instance_send’ gives me carpal tunnel just thinking about it!
:wink:

-a

100

On Sun, 9 Jul 2006 [email protected] wrote:

I prefer longer.
that seems to be pretty silly logic to me because there is always a
method
name that will collide with someone’s design. rather than cater to
those 5%
of cases why not simply allow them to alias send to whatever they want?
it’s
pretty easy to do

class Object
alias_method ‘super_secret_send’, ‘send’
end

alternatively we could stash all the methods that need to be hidden
under a
special object or name, something like

obj.internal :send, ‘msg’, ‘arg’

or

obj.internal{ send 'msg, ‘arg’ }

or, given that it’s actually a valid identifier

_(obj){ send ‘msg’, ‘arg’ }

obviously these are just ideas, and probably bad ones, but it just seems
to be
a waist of time to come up with 42 methods that won’t collide with
people’s
own code. why not just come up with one single way of entering an
object’s
stash of ‘super special and shouldn’t/can’t be overridden methods’ and
use it
for them all? then the issue is solved generically and consistently.

2cts.

-a