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
“Gavin Sinclair” gsinclair@soyabean.com.au schrieb im Newsbeitrag
news:1431045619661.20040512020216@soyabean.com.au…
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
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
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
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
···
On May 11, 2004, at 9:04 AM, Gavin Sinclair wrote:
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
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.
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
···
On Wednesday, May 12, 2004, 8:23:52 AM, David wrote:
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.
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 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
···
On Wednesday, May 12, 2004, 8:23:52 AM, David wrote:
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.
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”
OK, I can’t argue with that
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.
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
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.
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?
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.
]
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):
Forget the triviality of the example. Is that a good paradigm?
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.
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?
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.
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):
Forget the triviality of the example. Is that a good paradigm?
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.send(:self) 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, #send(:self) 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.send(:yourself)
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
···
On Thursday, May 13, 2004, 1:10:03 AM, Hal wrote:
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.send(:self) might make a kind of sense, but
I don’t know that it would help the original poster. (Was that you??)
, I can see situations