Various Topics on Ruby

.... ..De..

On Monday 21 June 2004 11:58, Sam Sungshik Kong wrote:
> Hi, Lennon!
>
> If I understand correctly, one can't call a private method via object name
> (receiver).
> Private methods can be called only with self.
>
> So the following code will cause an error (at the top level).
>
> def foo #->this is a private instance method of Object
> ...
> end
>
> obj = Object.new
>
> obj.foo #->Error, but in irb, it's ok.
>
> Best explanation so far is that irb makes an exception for debugging
> purpose.
>
>
> While trying to find the answer, I met more confusing statements in the
> Programming Ruby (Cl***es and Objects chapter).
>
> <snip>
> At the top level, we're executing code in the context of some predefined
> object. When we define methods, we're actually creating (private) singleton
> methods for this object. Instance variables belong to this object. And
> because we're in the context of Object, we can use all of Object's methods
> (including those mixed-in from Kernel) in function form. This explains why
> we can call Kernel methods such as puts at the top level (and indeed
> throughout Ruby): these methods are part of every object.
> </snip>
>
> Is the above explanation correct?
> Do I create a singleton method if I define a method at the top level?
>
> I'm getting more and more confused...
> Before I started Ruby, I thought I understood OOP concepts very clearly
> (with Java, C#, even Python).
> But Ruby puts me in a deep confusion with singleton methods, somewhat
> different concept of private/protected accessibility, metacl***, etc...
> But I like Ruby very much.
> I'm sure that if I overcome the difficulties, I will be a better
> programmer...

Ruby implements global space in a unique way. It secretly puts everything in
the top level into the cl*** definition of Object. Try this experiment:

@@testvar = "asd"

def testvar
@@testvar
end

h = Hash.new

p h.send(:testvar)

Both testvar and @@testvar are part of the cl*** definition of Object, and
Object is the base of all other objects, so that last line of code prints out
"asd".

Ruby treats everything at the top-level as though it were wrapped by the cl***
definition of Object:

cl*** Object
# top-level code here
end


Sean O'Dell

.... ..tche..

--- Sam Sungshik Kong <ssk@chol.nospam.net> wrote:
> Hi, Lennon!
>
> If I understand correctly, one can't call a private method via object name
> (receiver).
> Private methods can be called only with self.

You can also call a private method via send:

cl*** A
private
def f
99
end
end

puts A.new.send(:f)
# => 99

>
> So the following code will cause an error (at the top level).
>
> def foo #->this is a private instance method of Object
> ...
> end
>
> obj = Object.new
>
> obj.foo #->Error, but in irb, it's ok.
>
> Best explanation so far is that irb makes an exception for debugging
> purpose.
>
>
> While trying to find the answer, I met more confusing statements in the
> Programming Ruby (Cl***es and Objects chapter).
>
> <snip>
> At the top level, we're executing code in the context of some predefined
> object. When we define methods, we're actually creating (private) singleton
> methods for this object. Instance variables belong to this object. And
> because we're in the context of Object, we can use all of Object's methods
> (including those mixed-in from Kernel) in function form. This explains why
> we can call Kernel methods such as puts at the top level (and indeed
> throughout Ruby): these methods are part of every object.
> </snip>
>
> Is the above explanation correct?
> Do I create a singleton method if I define a method at the top level?

I would say the book explantion is not correct,

# courtesy dblack
module Kernel
def singleton_cl***
cl*** << self
self
end
end
end

def *****
88
end

puts self.cl*** == Object
# => true
puts self.cl***.private_instance_methods.include?("nake d")
# => true
puts self.singleton_cl***.private_instance_methods.incl ude?("*****")
# => true

If the method was added only to the singleton cl***, as the book ***erts, then
first "include?" check would give false.





__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

..l ..lt..

Sam Sungshik Kong wrote:
> If I understand correctly, one can't call a private method via object name
> (receiver).
> Private methods can be called only with self.
>
> So the following code will cause an error (at the top level).
>
> def foo #->this is a private instance method of Object
> ...
> end
>
> obj = Object.new
>
> obj.foo #->Error, but in irb, it's ok.
>
> Best explanation so far is that irb makes an exception for debugging
> purpose.

No, I don't think that's quite right. My guess would be that when
you're in an irb session, you're not really at the top level.

Imagine something like:

obj.instance_eval do
# User commands...
end

In other words, I think it's a side effect of the way irb works --
neither a bug nor a feature as such, and not a special exception
deliberately built in.

That's just my impression. I haven't proved it.


Hal

..m.. ..i..

Sam Sungshik Kong wrote:
> I'm getting more and more confused...
> Before I started Ruby, I thought I understood OOP concepts very clearly
> (with Java, C#, even Python).
> But Ruby puts me in a deep confusion with singleton methods, somewhat
> different concept of private/protected accessibility, metacl***, etc...


Java and (to the best of my knowledge) C# have a particular philosophy
of OO that differs from Ruby (and probably Python).

My understanding of OO tends to center on the notion of sending messages
to receivers; the receiver may or may not know how to handle the
message. The receiver may have originated from a cl*** derived from
one or more other cl***es, but, once created, may have acquire new or
altered behavior not found in any of the base cl***(es). Messages sent,
and methods implemented in the receiver, should not have to map to one
another; how an object responds to a message is up to that particular
object. The default behavior for handling unknown messages tends to be
an exception, but that should be left to the object (i.e., the
developer), not hard-coded into the language.

By analogy, think of a web site. Pages generally map to specific URLs.
Many web sites simply toss back a 500 or 404 when given an unknown
request, but the smarter sites know how to map all URLs to something
useful. Now imagine if a web site was operationally prevented from
handling unknown URLs. Or if a user could not even *try* to request a
page without knowing the full, correct URL in advance. (The
statically-typed Web?)

This view of OO runs counter to statically typed languages such as Java
and C#, where behavior tends to be set in stone early on, and object
behavior is defined by method invocation rather than message handling.

The idea that one object may be able to respond to messages that another
object of the same cl*** cannot is alien in Java, but normal in Ruby.

Likewise, the idea that cl***es and objects are malleable during runtime
is largely foreign in Java, but an essential fact of Ruby.

I'm not sure how much any of this helps you with your actual problem ;
I'm not even sure how accurate it is*. Getting your head around Ruby
is may be an adventure if you're coming from Java/C#.

There's also a good take on what constitutes various flavors of OO on
Paul Graham's site [0]. (There's lot's of other good stuff on his site,
BTW. I particularly like his comments on Arc and OO [1])



James

* I'm trusting somebody here will promptly correct me where I'm wrong.
But no flamewars, please.

[0] http://www.paulgraham.com/reesoo.html
[1] http://www.paulgraham.com/noop.html

..m ..ngsh.. ....

James, thanks you so much for your elaborate answer.
Yes, there's a lot to learn yet...:-)
Ruby is a new world and a pleansant challenge to me.
Paradigm shifting is always difficult but eventually worthwhile.

I'll check out the links.

Thanks again.

kong

"James Britt" <jamesUNDERBARb@neurogami.com> wrote in message
news:40D741E9.2000903@neurogami.com...
> Sam Sungshik Kong wrote:
> > I'm getting more and more confused...
> > Before I started Ruby, I thought I understood OOP concepts very clearly
> > (with Java, C#, even Python).
> > But Ruby puts me in a deep confusion with singleton methods, somewhat
> > different concept of private/protected accessibility, metacl***, etc...
>
>
> Java and (to the best of my knowledge) C# have a particular philosophy
> of OO that differs from Ruby (and probably Python).
>
> My understanding of OO tends to center on the notion of sending messages
> to receivers; the receiver may or may not know how to handle the
> message. The receiver may have originated from a cl*** derived from
> one or more other cl***es, but, once created, may have acquire new or
> altered behavior not found in any of the base cl***(es). Messages sent,
> and methods implemented in the receiver, should not have to map to one
> another; how an object responds to a message is up to that particular
> object. The default behavior for handling unknown messages tends to be
> an exception, but that should be left to the object (i.e., the
> developer), not hard-coded into the language.
>
> By analogy, think of a web site. Pages generally map to specific URLs.
> Many web sites simply toss back a 500 or 404 when given an unknown
> request, but the smarter sites know how to map all URLs to something
> useful. Now imagine if a web site was operationally prevented from
> handling unknown URLs. Or if a user could not even *try* to request a
> page without knowing the full, correct URL in advance. (The
> statically-typed Web?)
>
> This view of OO runs counter to statically typed languages such as Java
> and C#, where behavior tends to be set in stone early on, and object
> behavior is defined by method invocation rather than message handling.
>
> The idea that one object may be able to respond to messages that another
> object of the same cl*** cannot is alien in Java, but normal in Ruby.
>
> Likewise, the idea that cl***es and objects are malleable during runtime
> is largely foreign in Java, but an essential fact of Ruby.
>
> I'm not sure how much any of this helps you with your actual problem ;
> I'm not even sure how accurate it is*. Getting your head around Ruby
> is may be an adventure if you're coming from Java/C#.
>
> There's also a good take on what constitutes various flavors of OO on
> Paul Graham's site [0]. (There's lot's of other good stuff on his site,
> BTW. I particularly like his comments on Arc and OO [1])
>
>
>
> James
>
> * I'm trusting somebody here will promptly correct me where I'm wrong.
> But no flamewars, please.
>
> [0] http://www.paulgraham.com/reesoo.html
> [1] http://www.paulgraham.com/noop.html
>
>
>