Proposal: Object#send(nil) -> self

[Gavin Sinclair]

A quick one. I see some sense in Object#send accepting 'nil' as the
message. You send no message, you get the plain object. Does anyone
agree?

#send is clearly useful when you want to vary the message sent to an
object based on some condition. Sometimes the default condition is to
send no message, but that can't be coded as elegantly.

For example:

date_colour_msg =
case Date.today - date
when 0 then :red
when 1 then :yellow
when 2..5 then :green
else
nil # Default: whatever the normal colour is.
end

date_str = date.to_s.send(date_colour_msg)

That example's not too contrived, is it?

Cheers,
Gavin

 

[Robert Klemme]

A quick one. I see some sense in Object#send accepting 'nil' as the
message. You send no message, you get the plain object. Does anyone
agree?

#send is clearly useful when you want to vary the message sent to an
object based on some condition. Sometimes the default condition is to
send no message, but that can't be coded as elegantly.

For example:

date_colour_msg =
case Date.today - date
when 0 then :red
when 1 then :yellow
when 2..5 then :green
else
nil # Default: whatever the normal colour is.
end

# how about
date_str = date.to_s.send(date_colour_msg) if date_colour_msg

OTOH you can do

date_str = case Date.today - date
when 0 then date.to_s.red
when 1 then date.to_s.yellow
when 2..5 then date.to_s.green
else
default_color # Default: whatever the normal colour is.
end

The more OO way would be to use a Hash:

COLORS = {
0 => :red
...
}
COLORS.default= default_color

date_str = COLORS[Date.today - date]

That example's not too contrived, is it?

I found a bit irritating that you send :red, :yellow etc. to a String.

Regards

robert

 

[Joel VanderWerf]

A quick one. I see some sense in Object#send accepting 'nil' as the
message. You send no message, you get the plain object. Does anyone
agree?

#send is clearly useful when you want to vary the message sent to an
object based on some condition. Sometimes the default condition is to
send no message, but that can't be coded as elegantly.

For example:

date_colour_msg =
case Date.today - date
when 0 then :red
when 1 then :yellow
when 2..5 then :green
else
nil # Default: whatever the normal colour is.
end

date_str = date.to_s.send(date_colour_msg)

What about something like this (untested)?

class Object
def myself
self
end
end

date_colour_msg =
case Date.today - date
when 0 then :red
when 1 then :yellow
when 2..5 then :green
else
:myself # Default: whatever the normal colour is.
end

date_str = date.to_s.send(date_colour_msg)

 

[Mark Hubbart]

A quick one. I see some sense in Object#send accepting 'nil' as the
message. You send no message, you get the plain object. Does anyone
agree?

#send is clearly useful when you want to vary the message sent to an
object based on some condition. Sometimes the default condition is to
send no message, but that can't be coded as elegantly.

For example:

date_colour_msg =
case Date.today - date
when 0 then :red
when 1 then :yellow
when 2..5 then :green
else
nil # Default: whatever the normal colour is.
end

date_str = date.to_s.send(date_colour_msg)

That example's not too contrived, is it?

While the example seems *somewhat* contrived , I can see situations
where it would be handy... And since #sending nil currently raises an
error, I doubt it would break anyone's code. I would consider it a good
rcr, myself.

class Object
alias no_nil_send send
def send(*args)
args.first ? no_nil_send(*args) : self
end
end

Something like this, I assume?

cheers,
--Mark

 

[David Alan Black]

Hi --

A quick one. I see some sense in Object#send accepting 'nil' as the
message. You send no message, you get the plain object. Does anyone
agree?

#send is clearly useful when you want to vary the message sent to an
object based on some condition. Sometimes the default condition is to
send no message, but that can't be coded as elegantly.

For example:

date_colour_msg =
case Date.today - date
when 0 then :red
when 1 then :yellow
when 2..5 then :green
else
nil # Default: whatever the normal colour is.
end

date_str = date.to_s.send(date_colour_msg)

I don't like the special-case nature of this. I believe send should
send, not intercept (which is what this comes down to), its message.


David

 

[Gavin Sinclair]

# how about
date_str = date.to_s.send(date_colour_msg) if date_colour_msg

Of course there are plenty of alternatives, but that one (and the one
below) seem more verbose than necessary.

OTOH you can do

date_str = case Date.today - date
when 0 then date.to_s.red
[...]

The more OO way would be to use a Hash:

COLORS = {
0 => :red
...
}
COLORS.default = default_color

date_str = COLORS[Date.today - date]

I'm not so sure about that. That's an data-based approach; no active
objects in sight. You can't use a range for a key in that particular
hash either.

I found a bit irritating that you send :red, :yellow etc. to a String.

That's the way ANSI highlighting works in whatever RAA package I was
using two years ago when that example was current.

I had a minor "need" for this behaviour yesterday, but the example
above is perhaps more easily understood.

Cheers,
Gavin

 

[Gavin Sinclair]

Hi --

I don't like the special-case nature of this. I believe send should
send, not intercept (which is what this comes down to), its message.

I (generally) don't like special cases either, but this doesn't strike
me as such. The way 'date_str.send(nil)' reads to me is literally
"send no message to date_str".

I really like the message-passing paradigm, but sometimes ... you've
just gotta *not* pass a message

Gavin

 

[David Alan Black]

Hi --

I (generally) don't like special cases either, but this doesn't strike
me as such. The way 'date_str.send(nil)' reads to me is literally
"send no message to date_str".

I would say "no message" is a very special case of "a message"
Also, for what it's worth, the way it reads to me is "send the message
nil to date_str".

I really like the message-passing paradigm, but sometimes ... you've
just gotta *not* pass a message

There's a meta-thing going on here, though. You are passing a message
-- namely "send", which to me has a very strong semantic thrust. The
use of nil you're proposing feels to me like "send(no, actually
pretend I didn't say that)" or something, which just doesn't seem like
a good substitute for checking conditions and deciding whether sending
a message (i.e., name of method to be called) is appropriate (or not)
in the given situation.


David

 

[Gavin Sinclair]

I would say "no message" is a very special case of "a message"

OK, I can't argue with that

There's a meta-thing going on here, though. You are passing a message
-- namely "send", which to me has a very strong semantic thrust. The
use of nil you're proposing feels to me like "send(no, actually
pretend I didn't say that)" or something, which just doesn't seem like a
good substitute for checking conditions and deciding whether sending a
message (i.e., name of method to be called) is appropriate (or not) in
the given situation.

Good points. What about RCR #294, then? (I know there's a specific forum
for discussing that, but I'd like to know your thoughts in this context.)

Instead of sending (nil) to get the object, what about sending :self or
:identity (if :self is a problematic choice of name). As in (I'll go with
:identity for now):

class Object
def identity
self
end
end

So:

msg =
case rand(3)
when 0 then :upcase
when 1 then :reverse
when 2 then :identity
end

puts str.send(msg)

Forget the triviality of the example. Is that a good paradigm?

# I know the example could be recoded in a million different ways, but
# those approaches become ugly as the code gets larger. This is a
# message-passing language, after all.

Cheers,
Gavin

 

[Sascha Doerdelmann]

Instead of sending (nil) to get the object, what about sending :self or
:identity (if :self is a problematic choice of name).

If you really need a method returning self, please name it #yourself.

[OT:
The common usage for #yourself in Smalltalk is at the end of a message
cascade:

^anObject
messageWithParam: param;
messageWithoutParam;
anotherMessageToAnObject;
andSoOn: untilYouLike;
yourself

The ^ is a return. I've added it to indicate that anObject will be
used later on. I think I've seen proposals for this kind of syntactic
sugar in this group before. One of the main differences between my
code in Ruby and in Smalltalk is that I use more temporary variables
in Ruby.
]

Cheers
Sascha

 

[Hal Fulton]

It's a great paradigm, in the sense that the "identity" function is quite a
basic fundamental case in the set of all transformation functions.

I have seen arguments that it does not belong in Ruby core, but I would be
quite happy if it were.

Well, I can see that; but I don't accept the idea that nil should
indicate this.

It seems acceptable to me for every object to have a 'self' reader.
(I'm not sure that's doable in current Ruby, and I'm too lazy at the
moment to try it.)

But the basic problem I had with this idea was that even if there is
a "non-message message" (which as DAB pointed out, is itself a message),
I don't see that it should return the value of the object.

I suppose it makes sense if you think of 'obj.x' and then imagine
stripping off the '.x' -- but in the explicit sense of sending a message
via #send, it seems counter-intuitive. Why shouldn't obj.send(nil) just
return nil, for instance? The typical message sent to an object does not
result in that same object or even an object of that class (yes,
sometimes, but not always).

Anyhow, I can see that obj.sendself) might make a kind of sense, but
I don't know that it would help the original poster. (Was that you??)


Hal

 

[Gavin Sinclair]

I suppose it makes sense if you think of 'obj.x' and then imagine
stripping off the '.x' -- but in the explicit sense of sending a message
via #send, it seems counter-intuitive. Why shouldn't obj.send(nil) just
return nil, for instance? The typical message sent to an object does not
result in that same object or even an object of that class (yes,
sometimes, but not always).

Anyhow, I can see that obj.sendself) might make a kind of sense, but
I don't know that it would help the original poster. (Was that you??)

Original poster was me, and I accept that #self(nil) is unpopular, and
I agree there's something wrong with it. And yes, #sendself) would
help me, and appeals to me aesthetically as well. But I doubt the
name is acceptable. So what about (courtesy of Sascha)

class Object
def yourself
self
end
end

...

xyz.sendyourself)

# and of course

xyz.yourself

I don't care much for the name, but it's a Smalltalk thing, and
unless Smalltalk people think it sux, then it probably grows on you.
At least it is unlikely to conflict with a user's class; who has ever
created a method called 'yourself'?

So, OP is satisfied, and we can probably wrap this thread up now

Cheers,
Gavin

 

[daz]

Original poster was me, and I accept that #self(nil) is unpopular, and
I agree there's something wrong with it. And yes, #sendself) would
help me, and appeals to me aesthetically as well. But I doubt the
name is acceptable. So what about (courtesy of Sascha)

class Object
def yourself
self
end
end

...

xyz.sendyourself)

# and of course

xyz.yourself

I don't care much for the name, but it's a Smalltalk thing, and
unless Smalltalk people think it sux, then it probably grows on you.
At least it is unlikely to conflict with a user's class; who has ever
created a method called 'yourself'?

So, OP is satisfied, and we can probably wrap this thread up now

Cheers,
Gavin

'yourself' sux from reflexivity (I know what I mean but I think
your solution is cute. I shall use it in this form:


class Object
def ego
self
end
end

p "The answer is: %d".ego % 42.sendego)

 

[daz]

Perhaps ... see http://rcrchive.net/rcr/RCR/RCR249

Just looked (and voted in favour) assuming that what
your requesting is Object#to_self.

I just re-read the thread and didn't see that suggested
anywhere.

If you resubmitted with the more ruby-like name,
it might be more obvious that your request is reasonable.

Even more strongly, I wonder why it's not in Ruby now.


daz

 

[Hal Fulton]

:




Just looked (and voted in favour) assuming that what
your requesting is Object#to_self.

I just re-read the thread and didn't see that suggested
anywhere.

If you resubmitted with the more ruby-like name,
it might be more obvious that your request is reasonable.

Even more strongly, I wonder why it's not in Ruby now.

I'm not entirely sure I see a need for it, but I don't
object to it.

As for the name, personally I don't see that "self" would
conflict anywhere. You wouldn't be calling it from within
the object's methods, and if you did, well... you would
just get the "self" we have always had.

"self" with a receiver, obj.self, does not currently have
any meaning I'm aware of.


Hal

 

[Gavin Sinclair]

I'm not entirely sure I see a need for it, but I don't
object to it.

As for the name, personally I don't see that "self" would
conflict anywhere. You wouldn't be calling it from within
the object's methods, and if you did, well... you would
just get the "self" we have always had.

"self" with a receiver, obj.self, does not currently have
any meaning I'm aware of.

So, given this:

class Object
def self
self
end
end

Would the marked line below be using the method 'self' or the special
variable 'self'?

class X
def foo
self.bar # This one.
end
def bar
5
end
end

Furthermore, is the definition of Object#self above recursive?

Gavin

 

[nobu.nokada]

Hi,

At Thu, 13 May 2004 15:45:16 +0900,
Gavin Sinclair wrote in [ruby-talk:100083]:

Would the marked line below be using the method 'self' or the special
variable 'self'?

"self" is a keyword, so it cannot be a method name unless
preceeded by "." or "def".

 

[Hal Fulton]

Hal wrote:


So, given this:

class Object
def self
self
end
end

Would the marked line below be using the method 'self' or the special
variable 'self'?

class X
def foo
self.bar # This one.
end
def bar
5
end
end

Furthermore, is the definition of Object#self above recursive?

Excellent points.

Those are only issues if you implement it in Ruby. If you put the
logic in the parser/interpreter, that can be resolved, I think.

But why am I saying this? I haven't felt a need for this feature
personally.



Cheers,
Hal