Best name for "this method" ?

[Markus]

a = Object.new
def a.meth; puts "hi"; end
a.method("meth").call # hi

At no point has the message "meth" been sent to the object a -- but
"meth" is still the method's name.

I'm not sure I agree with this. Of course, at one level it is
tautologically true; there is no "object" a and no "messages" are ever
really sent--instead, the whole thing is being simulated by a clever
arrangement of silicon, copper, etc. But if you accept that we are
talking at some level of abstraction from the hardware, enough so that
the analogy of objects and messages works, you are claiming your code
snip does something like this:

* Send Object the message ["new"]; call it's reply a
* Send the message ["def","meth",{ || puts "hi"}] to a--this has
the effect of telling a what to do when it gets the message
"meth".
* Send a the message ["method","meth"] to a, and hold the
result--this is in effect asking a "what would you do if you got
the message 'meth'?"
* Send the result of the last step the message ["call"]--in
effect, saying "do your thing"

If you anthropomorphize the process as I've outlined it, clearly
the object a never gets the message meth. If I asked you "what do you
do when your mailbox is full?" and then logged in as you and did exactly
the steps you specified, it would _not_ be the same as telling you "your
mail box is full."

But I would have to log in as you for the analogy to work. And
what if the process required more than just your log in--what if it
included things like "I'd make a humorous entry in my blog"--so I'd have
to be able to write like you, etc. as well. In fact, it is easy to see
that I might have to _be_ you, for all intents and purposes to care this
off successfully. This analogy maps directly back to you example code.
The method returned and subsequently called executes _as_a_method_of_a_,
with all the context, access rights and restrictions, etc. that that
implies.

So we could look at the last to steps in another in other way; for
example, as:

* Send a the message ["method","meth"] to a, and hold the
result--this is in effect asking a "what would you do if you got
the message 'meth'?"
* Send the result of the last step the message ["call"]--in
effect, saying "send yourself to a with instructions to execute
you (not in the Rozencranz & Guildenstern sense of course)".

No, we still don't have a receiving the message "meth"; instead, we
have it looking up what it would do if it did get the message, and then
doing it. But what happens when an object gets a message? Doesn't it
do exactly these two thing, in this order? So the only difference
between this case and "receiving the message 'meth'" is that in your
example the process is interrupted (potentially indefinitely) while the
caller gets a chance to do stuff.

So, how is this different than what happens in a threaded
application? Should we say that a threaded OOapp works by passing
message, unless a context switch occurs at a certain point, in which
case we use another metaphor?

Or should we say that your example is a case of the object a
receiving the message "meth", but suspending control (as, say, an
iterator does with a yield) in mid stream?

As you can see, I'm not sure I agree with your example.

-- MarkusQ

 

[Robert Klemme]

I don't follow. Help you do what? It would still instantiate the

factory.

But you can't do

def create() @cl() end

That's the whole point of my post.

robert

 

[Robert Klemme]

Sure. I'd rather not clutter up Kernel either. I think its already got too
many methods (why all those string related methods, for instance?)

Because in Ruby there are no functions (as opposed to C++ for example) and
thus Kernel is used as the place to define global "functions".

But in
this case it doesn't really bother me, especially if a missing_method takes
care of it.

Still I don't see the gain in this other than make Ruby resemble other
languages more. In that case you might also want to add

module Kernel
private
def new(cl,*args, &b) cl.new(*args, &b) end
end
=> {}

*shudder*

It might be interesting if () were a "method dispatcher" method itself, then
it could be defined/redefined like [] is. But don't quote me on that, for the
moment it's just a passing thought

You did definitely too much C++.

Cheers

robert

 

[trans. (T. Onoma)]

But you can't do

def create() @cl() end

That's the whole point of my post.

And how does that get any better with Class[] ?

T.

 

[Robert Klemme]

But you can't do

def create() @cl() end

That's the whole point of my post.

And how does that get any better with Class[] ?

It doesn't. I was neither advocating () nor [] but recommend to use the
plain old #new.


robert

 

[trans. (T. Onoma)]

|Also, will a method like this be implemented in future Ruby?

Possible. A good name for it is a must.

matz.

What about 'operator'?

T.

 

[Markus]

What about 'operator'?

I don't like it. "Operator" has a pretty specific set of
connotations, both in math and computer science; they are:

* generally given symbols in preference to names
* parsed according to rules of precedence (e.g. MDAS) and
associativity
* narrow in definition or "algorithmically regular" as it is
sometimes put
* almost never have side-effects

This use would break most of them.
Things like "+" or "grad" (typically represented by a downward
pointing equilateral triangle) are operators. Most methods aren't.

-- Markus

 

[trans. (T. Onoma)]

I don't like it. "Operator" has a pretty specific set of
connotations, both in math and computer science; they are:

* generally given symbols in preference to names
* parsed according to rules of precedence (e.g. MDAS) and
associativity
* narrow in definition or "algorithmically regular" as it is
sometimes put
* almost never have side-effects

This use would break most of them.
Things like "+" or "grad" (typically represented by a downward
pointing equilateral triangle) are operators. Most methods aren't.

Fair enough. How about another:

moniker

T.