Little Things

[Martin DeMello]

You can generally tell from the semantics of the method name. For
example, Array#pop has no possible non-destructive meaning. (A
non-destructive pop would just be array[-1] with an incomprehensible
name.) There are a couple of cases where you do have to learn it...

Array#peek, perhaps, or Array#top. I'm actually strongly in favour of
this (I even submitted an RCR some years ago), since I feel the stack
and queue methods should be capable of being used, as a group, without
having to remember which end is the stack top and which the queue
front.

martin

 

[ara.t.howard]

Hi --

(A non-destructive pop would just be array[-1] with an incomprehensible
name.)

Array#last

OK; it would just be Array#last with an incomprehensible name

What I was getting at was that there's no point having pop and pop!
since a non-destructive method called "pop" makes no sense.

i never thought of this, but in cases like pop/delete the bang version could
be used to return self:

#
# ejects last element
#
# hop = on.pop
#
def pop
...
end

#
# ejects last element and returns self, eg
#
# a.pop!.size
#
def pop!
ignored = pop
self
end


the 'dangerous' bit here is that the value is thrown in the bit bucket. not
that i disagree with you - i just happen to have this thought...

-a

 

[dblack]

Hi --

You can generally tell from the semantics of the method name. For
example, Array#pop has no possible non-destructive meaning. (A
non-destructive pop would just be array[-1] with an incomprehensible
name.) There are a couple of cases where you do have to learn it...

Array#peek, perhaps, or Array#top. I'm actually strongly in favour of
this (I even submitted an RCR some years ago), since I feel the stack
and queue methods should be capable of being used, as a group, without
having to remember which end is the stack top and which the queue
front.

See my reply to James; I didn't mean that there's no good way to refer
to a given item, just that pop/pop! doesn't make sense.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Tom Pollard]

You are right especially for operators <<!, looks terrible but
would be
necessary if one wanted to follow the rationale.

"A foolish consistency is the hobgoblin of little minds." (Emerson).
Rigid consistency to convention doesn't magically produce a more
readable API. I kind of like Matz's interpretation of '!' as meaning
'dangerous', rather than 'mutating'.

TomP

 

[Martin DeMello]

Hi --

You can generally tell from the semantics of the method name. For
example, Array#pop has no possible non-destructive meaning. (A
non-destructive pop would just be array[-1] with an incomprehensible
name.) There are a couple of cases where you do have to learn it...

Array#peek, perhaps, or Array#top. I'm actually strongly in favour of
this (I even submitted an RCR some years ago), since I feel the stack
and queue methods should be capable of being used, as a group, without
having to remember which end is the stack top and which the queue
front.

See my reply to James; I didn't mean that there's no good way to refer
to a given item, just that pop/pop! doesn't make sense.

Ah - yes, I see what you mean. #pop does have the destructiveness
built into the name, I agree.

martin

 

[Trans]

On Thu, 4 Jan 2007, [ISO-8859-1] Paulo K=F6ch wrote:

On 2006/12/31, at 07:38, Rob Sanheim wrote:
obj.sendfoo) # will call only public
obj.send!foo) # will bypass private/protected, like the current se= nd.

+1

++

Come on guys. Has anyone read my critique? You can "plus one" til the
cow's come home, but you totally ignore the issues. Show me you know
something about the issue, tell me _why_. Otherwise your +1's are
littel more than cooy feelings.

Do you understand that #send is tantamount to a keyword?

yes. but it's only keword-like without a receive and

send! 'private_method'

is fine since

private_method

is fine too.

But it's the public use that actually causes the most trouble. It's
keyword-like in that it a method that is too important to override. So
we end up with __send__ or __send, which is ridiculous. Might as well
drop #send altogether and just have the ugly shadow method. Please, ask
yourselves, why do we have __send__?

T=2E

 

[ara.t.howard]

But it's the public use that actually causes the most trouble. It's
keyword-like in that it a method that is too important to override. So
we end up with __send__ or __send, which is ridiculous. Might as well
drop #send altogether and just have the ugly shadow method. Please, ask
yourselves, why do we have __send__?

T.

hmmm. there is no way around this kind of thing unless the operation of
sending a message to an object is removed from the object's interface. so we
could have something like

Pervasives.send obj, message, *args, &block

here Pervasives is an object that cannot be changed - even by changing
Object#send.

this also allows

Pervasives.object_id obj

etc.

thoughts?

-a

 

[dblack]

Hi --

hmmm. there is no way around this kind of thing unless the operation of
sending a message to an object is removed from the object's interface. so we
could have something like

Pervasives.send obj, message, *args, &block

here Pervasives is an object that cannot be changed - even by changing
Object#send.

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.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[ara.t.howard]

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.

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__

are examples. by moving the essential methods outside of the object itself an
into a frozen introspector

Introspector.object_id obj

we can elimnate this gotcha and this code

class BlankSlate
instance_methods.each{|m| remove_method unless m[/__/]}
end

can be reduced (and made more robust) to

class BlankSlate
instance_methods.each{|m| remove_method m}
end

make sense?

-a

 

[Gregory Brown]

On 12/31/06, Devin Mullins <[email protected]> wrote:

What about:

obj.sendfoo) # will call only public
obj.send!foo) # will bypass private/protected, like the current send.

+1. This sounds great. (sorry for the late reply)

 

[dblack]

Hi --

+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

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[dblack]

Hi --

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.

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__

are examples. by moving the essential methods outside of the object itself
an
into a frozen introspector

Introspector.object_id obj

we can elimnate this gotcha and this code

class BlankSlate
instance_methods.each{|m| remove_method unless m[/__/]}
end

can be reduced (and made more robust) to

class BlankSlate
instance_methods.each{|m| remove_method m}
end

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. In practice, has the name conflict issue with send
actually been much of a problem?


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Trans]

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:

1) There should be a unalterable means of dynamically sending a message
to an object. PERIOD. That seem reasonable, but...

2) 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.

 

[matt]

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

 

[dblack]

Hi --

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

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[ara.t.howard]

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

 

[Gregory Brown]

Hi --



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.

 

[ara.t.howard]

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

http://en.wikipedia.org/wiki/Object_(computer_science) 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]

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.

 

[Trans]

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 Fugal'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 Vanbroekhoven on how
Ruby's public vs. private and method_missing are not wholey consistant.

Thanks!
T.