On 12/31/06, Rob S. [email protected] wrote:
On 12/31/06, Devin M. [email protected] wrote:
What about:
obj.send(:foo) # will call only public
obj.send!(:foo) # will bypass private/protected, like the current send.
+1. This sounds great. (sorry for the late reply)
Hi –
On Thu, 4 Jan 2007, [email protected] wrote:
T.
this also allowsPervasives.object_id obj
etc.
thoughts?
I’m afraid I’m lost. What’s wrong with send, other than its
commonness as a name (which is dealt with by send)? If it’s too
much trouble to explain, that’s OK.
David
Hi –
On Thu, 4 Jan 2007, Gregory B. wrote:
On 12/31/06, Rob S. [email protected] wrote:
On 12/31/06, Devin M. [email protected] wrote:
What about:
obj.send(:foo) # will call only public
obj.send!(:foo) # will bypass private/protected, like the current send.+1. This sounds great. (sorry for the late reply)
BTW the earlier discussion of this, for those interested, starts at:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/153833
So everyone be careful not to add your +1 if it’s already there 
David
Hi –
On Thu, 4 Jan 2007, [email protected] wrote:
Object#send.
commonness as a name (which is dealt with by send)? If it’s too
are examples. by moving the essential methods outside of the object itselfcan be reduced (and made more robust) to
class BlankSlate
instance_methods.each{|m| remove_method m}
endmake sense?
It seems a bit drastic to flip things around into that less OO style.
I’m not too worried if something like BlankSlate has to jump through a
hoop or two. In practice, has the name conflict issue with send
actually been much of a problem?
David
So everyone be careful not to add your +1 if it’s already there
What is the meaning of “+1” and “+” ? This list seems to use it
extensively
[email protected] wrote:
this also allows
Pervasives.object_id obj
etc.
thoughts?
I’m afraid I’m lost. What’s wrong with send, other than its
commonness as a name (which is dealt with by send)? If it’s too
much trouble to explain, that’s OK.
Precisely right – both of you – it just depends on your viewpoint:
There should be a unalterable means of dynamically sending a message
to an object. PERIOD. That seem reasonable, but…
one can argue #1 is rather non-OOP like and if someone wants to
monkey with the “send” method then that’s their silly business.
So we have a choice, do we deviate from strict OOP, or do accept the
dangers of overridablity and recognize that generalized meta-code which
we except to work in all cases certainly will not.
Presently Ruby has adopted the 2nd approach, and uses the #send method
to do it. Unfortunately this method makes the danger of overridablity
even worse b/c, as David points out, it is also a rather common word.
So what happens? To mitigate the danger we get #send. This gives
some reassurance of guaranteed sendability while still being
overridable if absolutely necessary. Right? Unfortunately NO! It just
exacerbates the issue further. Not only is there’s really no point to
using #send since all assurance rests in send, but the assurance
itself is an illusion b/c send can be overridden. We’ve gained
nothing by this but additional complexity.
So we have a choice. Either pick option #1 instead. Or stick with #2
and choose a single method name that is relatively uncommon.
If Ruby sticks with #2 were actually in luck, there’s already a
unspoken precedence for important meta-methods to stay out of the way
of common names, namely those prefixed with object_ (as in object_id)
and instance_ (as in instance_variable_get) One for public sending
(object_send) and one for private sending (instance_send) --at least in
MHO.
One last thing. Has anyone considered a magic dot notation to act as
sort of a window to private space? Eg. something like:
obj.private.message
T.
Hi –
On Thu, 4 Jan 2007, matt wrote:
So everyone be careful not to add your +1 if it’s already there
What is the meaning of “+1” and “+” ? This list seems to use it
extensively
It basically means “I agree”, or “Add me to the list of people who
support this.”
David
On Thu, 4 Jan 2007, matt wrote:
So everyone be careful not to add your +1 if it’s already there
What is the meaning of “+1” and “+” ? This list seems to use it
extensively
we are voting for, as opposed to against, the idea.
cheers.
-a
On 1/3/07, [email protected] [email protected] wrote:
obj.send!(:foo) # will bypass private/protected, like the current send.
+1. This sounds great. (sorry for the late reply)
BTW the earlier discussion of this, for those interested, starts at:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/153833
David, thanks for linking this. It’s good to see this has come up
before and have some additional context.
On Thu, 4 Jan 2007 [email protected] wrote:
make sense?
It seems a bit drastic to flip things around into that less OO style. I’m
not too worried if something like BlankSlate has to jump through a hoop or
two.
i wouldn’t say it’s less OO. according to wikipedia
in fact, it’s quite OO: Pervasives (Introspector or whatever we might
call it)
is the object that sees through to the pristine unalterable state of any
other
object. it interacts with these other objects by sending messages.
this is
quite inline with any OO i’ve ever heard of, for instance
we might as well say something like
Guru.send student, message, :compassion
Object (computer science) - Wikipedia seems to
agree
somewhat
“In the programming paradigm, object-oriented programming, an object
is an
individual unit of run-time data storage that is used as the basic
building
block of programs. These objects act on each other, as opposed to a
traditional view in which a program may be seen as a collection of
functions, or simply as a list of instructions to the computer. Each
object
is capable of receiving messages, processing data, and sending
messages to
other objects. Each object can be viewed as an independent little
machine
or actor with a distinct role or responsibility.”
i understand the sentiment. still, what we after is a methodology which
ensures that some aspects of objects can always be reached. it’s quite
OO to
delegate the responsibility of locating and preserving that aspect to
another
object. syntactically one might prefer
reveal{ object }.send msg
but the impl would obviously be the same since, here, we’ve just popped
up to
(Kernel|Object).reveal
remember that much of ruby works this way: puts, fork, exit, raise, etc
are
all hung off of Kernel|Object.
In practice, has the name conflict issue with send actually been much of a
problem?
yes. and the related object_id, instance_eval, instance_variable_get,
etc.
the fact that some, but not all, methods of an object are required for
it to
function at a reasonble level, and that those same methods are not
protected
or separated from ‘normal’ methods in any way has frequently been an
issue for
the few metaprogramming libs i’ve written such as traits, attributes,
xx, etc.
regards.
-a
Trans wrote:
One last thing. Has anyone considered a magic dot notation to act as
sort of a window to private space? Eg. something like:obj.private.message
Duh… I did!
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/154169
T.
[email protected] wrote:
BTW the earlier discussion of this, for those interested, starts at:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/153833
Wow. That’s a great thread! I esspecially liked the idea of #send as
the methodized form of the dot. And Jacob F.'s insight that if send
called private and obj.send only prublic then
class Object
def instance_send( … )
send( … )
end
end
can be used to bypass privacy.
The thread ends with a great analysis by Peter V. on how
Ruby’s public vs. private and method_missing are not wholey consistant.
Thanks!
T.
On 1/3/07, [email protected] [email protected] wrote:
obj.send!(:foo) # will bypass private/protected, like the current send.
+1. This sounds great. (sorry for the late reply)
BTW the earlier discussion of this, for those interested, starts at:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/153833So everyone be careful not to add your +1 if it’s already there
David
Huh - I’m glad to see you had the idea first, David. I guess I get
good ideas at least once in awhile :).
On Jan 3, 2007, at 7:33 PM, Trans wrote:
If Ruby sticks with #2 were actually in luck, there’s already a
unspoken precedence for important meta-methods to stay out of the way
of common names, namely those prefixed with object_ (as in object_id)
and instance_ (as in instance_variable_get) One for public sending
(object_send) and one for private sending (instance_send) --at
least in
MHO.
We’re not sending an object though, we’re sending a message. Perhaps
send_message() would be a less clashed name, but I doubt it.
James Edward G. II
James Edward G. II wrote:
We’re not sending an object though, we’re sending a message. Perhaps
send_message() would be a less clashed name, but I doubt it.
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/232167
Besides that would be “foo.send_object”, not “foo.object_send”.
T.
[email protected] wrote:
in fact, it’s quite OO: Pervasives (Introspector or whatever we might call it)
ensures that some aspects of objects can always be reached. it’s quite OO to
all hung off of Kernel|Object.
regards.
you make a strong argument ara. i know we’ve discussed this particular
question before, i forget what we came up with then. i’ll have to
search for it. but at the moment it would be nicer with a shorter
notation. what about some type of alternate “dot” that demands the Guru
module definition:
obj$send message
or something. (Hmm… didn’t someone suggest using the dollar sign in a
similar syntax before? What was that about?)
T.
On 1/3/07, Trans [email protected] wrote:
So what happens? To mitigate the danger we get #send. This gives
If Ruby sticks with #2 were actually in luck, there’s already a
unspoken precedence for important meta-methods to stay out of the way
of common names, namely those prefixed with object_ (as in object_id)
and instance_ (as in instance_variable_get) One for public sending
(object_send) and one for private sending (instance_send) --at least in
MHO.
How is this better then having send and the __send alias, along with
the corresponding bang methods? It seems to me having one method that
means “send a message”, and then having one version be the “dangerous”
version is much more obvious then having object_send and
instance_send.
If a ruby newbie tried “send” and saw it fail due to a private method,
I bet once they saw “send!” in the docs or in irb they would
immediately know how it works. Its aligns perfectly with many other
things in the std lib, and fits perfectly with POLS.
As for protecting from people overriding it, I think having the
underscore forms is enough. YSYEO (“You’ll shoot your eye out.”) I’m
sure there are programs were object_id and other meta-methods are
overridden. All you can do is warn people against doing it, test your
code, and of course choose libraries that behave well.
On Thu, 4 Jan 2007, Rob S. wrote:
I bet once they saw “send!” in the docs or in irb they would
immediately know how it works. Its aligns perfectly with many other
things in the std lib, and fits perfectly with POLS.
agreed.
As for protecting from people overriding it, I think having the
underscore forms is enough. YSYEO (“You’ll shoot your eye out.”) I’m
sure there are programs were object_id and other meta-methods are
overridden. All you can do is warn people against doing it, test your
code, and of course choose libraries that behave well.
alternatively, it can be externalized so no matter how hard you muck
about
with objects you cannot break certain unalienable behvaiours we desire
them to
have.
regards.
-a
[email protected] wrote:
so long as we have to rely on objects responding to certain methods certain
constructs, such as those that meta-programming cut to, can be made
difficult
since the very methods we require to operate can be over-ridden. this
is why
we have
id
send
Hrm. I thought the reason id and send where there was because id
and send are fairly common names and useful for custom methods in, say,
ActiveRecord::Base and Socket.
are examples. by moving the essential methods outside of the object
itself an
into a frozen introspectorIntrospector.object_id obj
Another option is to make __id, __send, and __send! impervious to
metaprogramming. Say, they are listed in #methods because that’s useful
for irb-learning, but remove_method and the like are no-ops when called
on __id, __send, and __send!. That way you can have your BlankSlate and
eat it, too. Thoughts?
Devin
Devin M. wrote:
and send are fairly common names and useful for custom methods in, say,
on __id, __send, and __send!.
Again, there would be no point in having #object_id, #send and #send!
in that case. If given a choice between a method that works and one
that might work, which one would you choose?
That way you can have your BlankSlate and
eat it, too. Thoughts?
id ought to be deprecated. we have object_id.
T.
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