top-level object? top-level methods?
itsme213
called 'main' in irb?
Is so, why are top-level methods not made singleton-methods on this object,
instead of being pulled in as instance methods on the Object class itself
(and hence into all other classes i.e. more namespace pollution than is
usually intended). This would still allow top-level methods to call other
top-level methods. And if the top-level object were referred to by some
constant like Main, then those methods could be called from anywhere with
Main.method(...).
Yukihiro Matsumoto
In message "Re: top-level object? top-level methods?"
on Tue, 25 Jan 2005 12:30:50 +0900, "itsme213" <itsm...@hotmail.com> writes:
|Is there a top-level object in any executing Ruby program? Is it the thing
|called 'main' in irb?
Yes and yes.
|Is so, why are top-level methods not made singleton-methods on this object,
|instead of being pulled in as instance methods on the Object class itself
|(and hence into all other classes i.e. more namespace pollution than is
|usually intended). This would still allow top-level methods to call other
|top-level methods. And if the top-level object were referred to by some
|constant like Main, then those methods could be called from anywhere with
|Main.method(...).
Do you really wish to type "Main.print" everywhere?
matz.
Matt Mower
<ma...@ruby-lang.org> wrote:
> |Is so, why are top-level methods not made singleton-methods on this object,
> |instead of being pulled in as instance methods on the Object class itself
> |(and hence into all other classes i.e. more namespace pollution than is
> |usually intended). This would still allow top-level methods to call other
> |top-level methods. And if the top-level object were referred to by some
> |constant like Main, then those methods could be called from anywhere with
> |Main.method(...).
>
> Do you really wish to type "Main.print" everywhere?
>
Shouldn't #print really be in a module somewhere and then included
when I want to be able to "print"..?
M
--
Matt Mower :: http://matt.blogs.it/
ts
M> Shouldn't #print really be in a module somewhere and then included
M> when I want to be able to "print"..?
Well, in this case do you want to always write
Main.require, Main.exit, Main.eval, Main.proc, ...
Guy Decoux
Matt Mower
Maybe I've gotten the wrong end of the stick about the original question.
From my perspective, if I
require 'pp'
I can then refer to 'pp' without prefixing. I'm not clear why print
(and much of the other stuff globbed into Object) should be any
different since it arguably clutters the namespace.
A require 'convenience' could, imo, emulate the current situation
without requiring the clutter.
But, as I say, perhaps I didn't grasp the original point.
Matt Mower
> without requiring the clutter.
>
It occurs to me that, as well as being a bad pun, this isn't clear.
What I meant was you could add all the convenience methods using a
"convenience" module which could be required when necessary. This
module in turn might require other, fine grained, modules where
independent functionalities like "print" could live.
I guess, philosophically, I'm of the Ruby Facets mindset. I'd rather
have smaller, finegrained, functionalities that could be bound in when
I need them (as long as it's still convenient when I do, and I think
that it is).
Regards,
Matt
ts
M> require 'pp'
Hey, you can't write this :-)
You must write
Main.require 'pp'
Guy Decoux
Matt Mower
Well I did say "much" of the stuff in object, not all ;-)
Pit Capitain
I think the original poster asked why
def do_something
p "hi"
end
becomes a private method of Object instead of a singleton method of a top-level
object/module called "Main". He didn't want to prefix all Object/Kernel methods
with Main.
Why should, after the definition above, the following be legal as it is today:
Time.send :do_something # => "hi"
("Time" is just an example. You can substitute any other object.)
The suggested behavior would be
Time.send :do_something # => NoMethodError
Main.do_something # => "hi"
I like this proposal. Would there be any drawbacks?
Regards,
Pit
Yukihiro Matsumoto
In message "Re: top-level object? top-level methods?"
on Wed, 26 Jan 2005 00:07:19 +0900, Pit Capitain <p...@capitain.de> writes:
|I like this proposal. Would there be any drawbacks?
1. Compatibility. It would break a lot of code, which assume
top-level def can be seen from everywhere.
2. Mindset. I feel above assumption is natural.
matz.
itsme213
"Yukihiro Matsumoto" <ma...@ruby-lang.org> wrote in message
> Hi,
>
> In message "Re: top-level object? top-level methods?"
> on Wed, 26 Jan 2005 00:07:19 +0900, Pit Capitain <p...@capitain.de>
writes:
>
> |I like this proposal. Would there be any drawbacks?
>
> 1. Compatibility. It would break a lot of code, which assume
> top-level def can be seen from everywhere.
A compatibility mode perhaps :-)
class Object
def method_missing sym, *args, &block
if Main.respond_to? sym
Main.send sym, *args, &block
else normal_method_missing_stuff
end
end
> 2. Mindset. I feel above assumption is natural.
With the option of using modules and includes, I am not sure the namespace
pollution is worth it. I do fully agree with one of the original goals of
making procedural programmers quite at home, and don't think this approach
would sacrifice that goal.
I find myself throwing in top-level methods when in a rush, when it is
convenient, I don't need multiple instances, etc. But I don't think I ever
throw them in with the _intent_ of calling them from anywhere. Of course,
because they are currently callable from anywhere, code will end up using it
that way.
Pit Capitain
> on Wed, 26 Jan 2005 00:07:19 +0900, Pit Capitain <p...@capitain.de> writes:
>
> |I like this proposal. Would there be any drawbacks?
>
> 1. Compatibility. It would break a lot of code, which assume
> top-level def can be seen from everywhere.
>
> 2. Mindset. I feel above assumption is natural.
Oh, now I see. Seems I've never mixed procedural and OO code, so I hadn't
thought of any use for this "feature". Thanks for the clarification. I should
have known you chose this implementation for a reason.
Regards,
Pit
Csaba Henk
> Is so, why are top-level methods not made singleton-methods on this object,
> instead of being pulled in as instance methods on the Object class itself
> (and hence into all other classes i.e. more namespace pollution than is
> usually intended). This would still allow top-level methods to call other
> top-level methods. And if the top-level object were referred to by some
> constant like Main, then those methods could be called from anywhere with
> Main.method(...).
* If you are in an interactive session, or create a 10-line script to
parse stdin which looks like sanitized perl, you don't care about
namespace pollution.
* If you write a "proper" ruby program, you encapsulate your code into
Classes/Modules anyway.
So I think the toplevel namespace pollution is not an issue...
Csaba
itsme213
>
> In message "Re: top-level object? top-level methods?"
> on Wed, 26 Jan 2005 00:07:19 +0900, Pit Capitain <p...@capitain.de>
writes:
>
> |I like this proposal. Would there be any drawbacks?
>
> 1. Compatibility. It would break a lot of code, which assume
> top-level def can be seen from everywhere.
A compatibility mode perhaps :-) Don't know is something like this is a good
idea, but ...
class Object
def method_missing sym, *args, &block
if Main.respond_to? sym
Main.send sym, *args, &block
else normal_method_missing_stuff
end
end
Old code that relied on main methods being in Object should still run (I
think, have not tested). New code that relies on main methods being in Main
will still run, except for certain #method_missing cases that made it all
the way up to Object. Sounds ok to me.
> 2. Mindset. I feel above assumption is natural.
I fully agree with the goal of making procedural programmers at ease. This
approach does not sacrifice that goal. But it does affect existing OO +
procedural code, hence a compatibility mode for this change? Someone
knowingly combining OO and procedural code can always use modules and
includes if they need to approximate the old behavior. So I am not sure the
namespace pollution is worth it.
I typically throw in top-level methods for short scripts, when in a rush,
when it is convenient, I don't need multiple instances, or just being sloppy
Mark Hubbart
>
> "Yukihiro Matsumoto" <ma...@ruby-lang.org> wrote in message
> > Hi,
> >
> > In message "Re: top-level object? top-level methods?"
> > on Wed, 26 Jan 2005 00:07:19 +0900, Pit Capitain <p...@capitain.de>
> writes:
> >
> > |I like this proposal. Would there be any drawbacks?
> >
> > 1. Compatibility. It would break a lot of code, which assume
> > top-level def can be seen from everywhere.
>
> A compatibility mode perhaps :-) Don't know is something like this is a good
> idea, but ...
>
> class Object
> def method_missing sym, *args, &block
> if Main.respond_to? sym
> Main.send sym, *args, &block
> else normal_method_missing_stuff
> end
> end
>
> Old code that relied on main methods being in Object should still run (I
> think, have not tested). New code that relies on main methods being in Main
> will still run, except for certain #method_missing cases that made it all
> the way up to Object. Sounds ok to me.
It already behaves this way, except for the lack of the Main object.
def read
puts "Once upon a time..."
end
==>nil
Object.new.send(:read)
Once upon a time...
==>nil
File.new("/etc/hosts").send(:read)
==>"##\n# Host Database\n#\n# localhost is used to configure the
loopback interface\n# when the system is booting. Do not change this
entry.\n##\n127.0.0.1\tlocalhost\n255.255.255.255\tbroadcasthost\n::1
localhost \n\n"
> > 2. Mindset. I feel above assumption is natural.
>
> I fully agree with the goal of making procedural programmers at ease. This
> approach does not sacrifice that goal. But it does affect existing OO +
> procedural code, hence a compatibility mode for this change? Someone
> knowingly combining OO and procedural code can always use modules and
> includes if they need to approximate the old behavior. So I am not sure the
> namespace pollution is worth it.
>
> I typically throw in top-level methods for short scripts, when in a rush,
> when it is convenient, I don't need multiple instances, or just being sloppy
> etc. But I don't think I ever throw them in with the _intent_ of calling
> them from anywhere. Of course, because they are currently callable from
> anywhere, code will end up using it that way.
I'm not sure what the problem is. Top level def methods are private,
so they don't affect #respond_to?. Methods of the same name defined in
Object's subclasses will mask those messages. When you talk about
polluting, it makes it sound like they get in the way, and cause all
manner of problems; I don't see how this could be possible. Is there a
reason for changing it, other than to make Ruby more pure?
I'm not trying to give the idea the smackdown, but since I only see a
semantic difference between the two ways of doing it, I feel that
pollution is perhaps a bit too strong a word.
cheers,
Mark
Aredridel
> so they don't affect #respond_to?. Methods of the same name defined in
> Object's subclasses will mask those messages. When you talk about
> polluting, it makes it sound like they get in the way, and cause all
> manner of problems; I don't see how this could be possible. Is there a
> reason for changing it, other than to make Ruby more pure?
>
> I'm not trying to give the idea the smackdown, but since I only see a
> semantic difference between the two ways of doing it, I feel that
> pollution is perhaps a bit too strong a word.
+1.
Don't break it -- not all problems are OO-shaped, no need to make ruby
less suitable for programs that aren't OO.
Besides, all the one-liners and such (which I write every day) rely on
this: it's a feature, not a bug.
Gavri Fernandez
> I fully agree with the goal of making procedural programmers at ease. This
> approach does not sacrifice that goal. But it does affect existing OO +
> procedural code, hence a compatibility mode for this change? Someone
> knowingly combining OO and procedural code can always use modules and
> includes if they need to approximate the old behavior. So I am not sure the
> namespace pollution is worth it.
It was just a couple of days back that I commented on a post
(http://www.livejournal.com/users/premshree/39574.html) in Live
journal where I said that Ruby is so cool because it is completely
object-oriented, yet allows for procedural programming.
+1 for keeping things as they are.
What does a top-level object mean anyway? I never understood that. If
someone would care to explain........ ( C++, Java background here)
Thank you,
Gavri