Hello
def self.mymeth
'yes'
end
alias yesmeth mymeth # error
How can I make an alias for a class method or a method in another class/namespace?
How do I adress the main-Namespace (in which class / namespace are the methods not defined inside any class?)
thanks,
Opti
def self.mymeth
'yes'
endalias yesmeth mymeth # error
How can I make an alias for a class method
class << self
def mymeth
'yes'
end
alias yesmeth mymeth
end
or a method in another class/namespace?
Eek. You can't use alias to do that AFAIK and it would be really confusing if you could? I'd hate to have to debug that code.
OTOH if you have a class Foo with a method 'one' which you want to call 'two' inside class Bar:
class Bar
def initialize(foo); @foo = foo; end
def two; @foo.one; end
end
How do I adress the main-Namespace (in which class / namespace are the
methods not defined inside any class?)
Again, this sounds like a terrible idea to me -- I don't want the code I require to be altering the main namespace. I'm sure someone here can/will come up with a way to do it, but I really think you should find a better way to do what you want.
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>
Sorry for a brief reply (I'm on my phone). How about something like this?
~~~
class << self
def mymeth
'yes'
end
alias yesmeth mymeth
end
~~~
Try looking up "singleton class" if you want to research it yourself.
Cheers
Matty
On 09/11/2016, Die Optimisten <inform@die-optimisten.net> wrote:
Hello
def self.mymeth
'yes'
endalias yesmeth mymeth # error
How can I make an alias for a class method or a method in another
class/namespace?
How do I adress the main-Namespace (in which class / namespace are the
methods not defined inside any class?)thanks,
OptiUnsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
Matthew Kerwin
http://matthew.kerwin.net.au/
Hello,
What is the name of the Class/Namespace if not having defined any?
(what does self reference to, if working on the top, without class MyClass end ? )
thanks,
Opti
Hi Opti,
Am 11.11.2016 um 13:13 schrieb Die Optimisten <inform@die-optimisten.net>:
What is the name of the Class/Namespace if not having defined any? (what does self reference to, if working on the top, without class MyClass end ? )
I think it should be Object:
~~~
2.3.1 :001 > self
=> main
2.3.1 :002 > self.instance_of?(Object)
=> true
~~~
Cheers,
Michael
I think it should be Object:
~~~
2.3.1 :001 > self
=> main
2.3.1 :002 > self.instance_of?(Object)
=> true
~~~
As you can see from your own example, it's 'main'. Object is the not-quite-final parent of all other objects. But then things get weird. The idea of a class hierarchy breaks up a little right at the top.
[13] pry(main)> Object.ancestors
=> [Object, PP::ObjectMixin, Kernel, BasicObject]
[14] pry(main)> Kernel.ancestors
=> [Kernel]
[15] pry(main)> BasicObject.ancestors
=> [BasicObject]
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>
Weird indeed:
Am 11.11.2016 um 14:45 schrieb Andy Jones <Andy.Jones@jameshall.co.uk>:
As you can see from your own example, it's 'main'. Object is the not-quite-final parent of all other objects. But then things get weird.
~~~
2.3.1 :001 > self.class
=> Object
~~~
Weird indeed:
~~~
2.3.1 :001 > self.class
=> Object
~~~
You are assuming that the top-level namespace in which the object hierarchy runs is itself an object in that hierarchy. I suppose ideally that would be the case. But I don't think it's true in fact.
You can traverse the object hierarchy upwards, sure, but that doesn't mean you will find that main object.
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>
Weird indeed:
~~~
2.3.1 :001 > self.class
=> Object
~~~You are assuming that the top-level namespace in which the object hierarchy runs is itself an object in that hierarchy. I suppose ideally that would be the case. But I don't think it's true in fact.
Let's see
irb(main):001:0> Object.instance_method :abcd
NameError: undefined method `abcd' for class `Object'
from (irb):1:in `instance_method'
from (irb):1
from /usr/bin/irb:11:in `<main>'
irb(main):002:0> def abcd; end
=> :abcd
irb(main):003:0> Object.instance_method :abcd
=> #<UnboundMethod: Object#abcd>
irb(main):004:0> Object.private_instance_methods.grep /abcd/
=> [:abcd]
So the top level namespace is Object. Since Object is a class it is
also an instance of itself:
irb(main):005:0> Object.class
=> Class
irb(main):006:0> Object.class.ancestors
=> [Class, Module, Object, Kernel, BasicObject]
irb(main):007:0> Object.is_a? Object
=> true
irb(main):008:0> Object === Object
=> true
It's a bit mind boggling - but just if you think about it too long. 
You can traverse the object hierarchy upwards, sure, but that doesn't mean you will find that main object.
Especially since there is a class hierarchy only and not an object
hierarchy. 
Cheers
robert
On Mon, Nov 14, 2016 at 10:24 AM, Andy Jones <Andy.Jones@jameshall.co.uk> wrote:
--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/
So the top level namespace is Object. Since Object is a class it is
also an instance of itself:
Yes, that's the top of the object hierarchy, but not the 'main object'. Main is an instance *of* Object (?) ... but then, so is everything else.
You might want to look at this discussion on SO: program entry point - What is "main" in Ruby? - Stack Overflow
Or this one: metaprogramming - Inconsistency about ruby 'main' object - Stack Overflow
Or this blog post: Ruby's Top Self Object — SitePoint
Especially since there is a class hierarchy only and not an object
hierarchy.
If that were true then you would not have been able to type 'self.class' as you did.
Or, indeed:
[1] pry(main)> class Foo; end
=> nil
[2] pry(main)> module Bar; end
=> nil
[3] pry(main)> x = Foo.new.extend(Bar)
=> #<Foo:0x000000037df598>
[4] pry(main)> x.class
=> Foo
[5] pry(main)> x.class.ancestors
=> [Foo, Object, PP::ObjectMixin, Kernel, BasicObject]
[6] pry(main)> x.singleton_class
=> #<Class:#<Foo:0x000000037df598>>
[7] pry(main)> x.singleton_class.ancestors
=> [#<Class:#<Foo:0x000000037df598>>, Bar, Foo, Object, PP::ObjectMixin, Kernel, BasicObject]
Classes are also objects. There is a hierarchy of objects, some of which are classes...
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>
So the top level namespace is Object. Since Object is a class it is
also an instance of itself:Yes, that's the top of the object hierarchy, but not the 'main object'. Main is an instance *of* Object (?) ... but then, so is everything else.
Only classes and modules constitute namespaces in Ruby. And, as I have
shown, any method defined on top level is a private instance method of
Object. So if anything, Object is the namespace.
But we are not actually invoking a method on top level as
Object::meth() and actually we can't. Methods defined on top level are
made available to almost all (because of BasicObject) instances via
inheritance.
You might want to look at this discussion on SO: program entry point - What is "main" in Ruby? - Stack Overflow
Or this one: metaprogramming - Inconsistency about ruby 'main' object - Stack Overflow
Or this blog post: Ruby's Top Self Object — SitePoint
Especially since there is a class hierarchy only and not an object
hierarchy.If that were true then you would not have been able to type 'self.class' as you did.
I am able to execute "self.class" because #class is an instance method
of Kernel which is included by Object. So all instances of Object and
sub classes inherit this method via the class / module hierarchy.
Of course, you can create arbitrary hierarchies of objects by
establishing references between them. For the sake of inheritance
there is only a class / module hierarchy.
Or, indeed:
[1] pry(main)> class Foo; end
=> nil[2] pry(main)> module Bar; end
=> nil[3] pry(main)> x = Foo.new.extend(Bar)
=> #<Foo:0x000000037df598>[4] pry(main)> x.class
=> Foo[5] pry(main)> x.class.ancestors
=> [Foo, Object, PP::ObjectMixin, Kernel, BasicObject][6] pry(main)> x.singleton_class
=> #<Class:#<Foo:0x000000037df598>>[7] pry(main)> x.singleton_class.ancestors
=> [#<Class:#<Foo:0x000000037df598>>, Bar, Foo, Object, PP::ObjectMixin, Kernel, BasicObject]Classes are also objects.
Yes.
There is a hierarchy of objects, some of which are classes...
That statement does not make sense to me as indicated above. The
hierarchical relationship between classes is an inheritance
relationship via #superclass. The relationship between objects and
classes is that of instantiation via #instance_of?.
Cheers
robert
On Mon, Nov 14, 2016 at 2:19 PM, Andy Jones <Andy.Jones@jameshall.co.uk> wrote:
--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/
That statement does not make sense to me as indicated above.
I think perhaps our mental models of Ruby are incompatible. One final thought.
The
hierarchical relationship between classes is an inheritance
relationship via #superclass. The relationship between objects and
classes is that of instantiation via #instance_of?.
What, then, is this?
[1] pry(main)> class Foo; end
=> nil[2] pry(main)> module Bar; end
=> nil[3] pry(main)> x = Foo.new.extend(Bar)
=> #<Foo:0x000000037df598>[...]
[7] pry(main)> x.singleton_class.ancestors
=> [#<Class:#<Foo:0x000000037df598>>, Bar, Foo, Object, PP::ObjectMixin, Kernel, BasicObject]
When Ruby tries to find a method, it walks up a **single hierarchy** of objects. It starts with the current object, then looks in the singleton class of the object, then the parents of that singleton class, then the parent class of the object, then the singleton class of that class and so on: one hierarchy involving the current object and any other number of classes, modules, singleton classes and (admittedly this would be pretty weird?) other objects.
You can, of course, view things in terms of a separate class inheritance hierarchy if you wish. In other languages this is literally true. But really, Ruby isn't _quite_ working like that.
Admittedly the difference is a subtle one, and most of the time it's not important. Unless you are mucking around with the singleton class (aka "eigenclass") it probably doesn't matter at all.
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>
That statement does not make sense to me as indicated above.
I think perhaps our mental models of Ruby are incompatible. One final thought.
I am suspecting it is rather different usage of terms.
The
hierarchical relationship between classes is an inheritance
relationship via #superclass. The relationship between objects and
classes is that of instantiation via #instance_of?.What, then, is this?
[1] pry(main)> class Foo; end
=> nil[2] pry(main)> module Bar; end
=> nil[3] pry(main)> x = Foo.new.extend(Bar)
=> #<Foo:0x000000037df598>[...]
[7] pry(main)> x.singleton_class.ancestors
=> [#<Class:#<Foo:0x000000037df598>>, Bar, Foo, Object, PP::ObjectMixin, Kernel, BasicObject]When Ruby tries to find a method, it walks up a **single hierarchy** of objects. It starts with the current object,
No. It starts with the singleton class. If you look at
rb_search_method_entry() you'll notice that obtaining the class is the
first thing the method does:
https://github.com/ruby/ruby/blob/trunk/vm_eval.c#L526
If you are interested how I got there:
1. find -type f -name \*.c -exec egrep 'rb_define_method.*send' {} +
./vm_eval.c:2205: rb_define_method(rb_mKernel, "send", rb_f_send, -1);
2. rb_f_send() in vm_eval.c
https://github.com/ruby/ruby/blob/trunk/vm_eval.c#L979
3. rb_send_internal() in vm_eval.c
https://github.com/ruby/ruby/blob/trunk/vm_eval.c#L899
4. rb_call0() in vm_eval.c
https://github.com/ruby/ruby/blob/trunk/vm_eval.c#L331
then looks in the singleton class of the object, then the parents of that singleton class, then the parent class of the object, then the singleton class of that class and so on: one hierarchy involving the current object and any other number of classes, modules, singleton classes and (admittedly this would be pretty weird?) other objects.
The method lookup is more like this:
1. Look in singleton class of instance
2. Look in modules included in singleton class of instance in reverse
inclusion order
3. Look in super class of singleton class which happens to be the
"official" class of the instance
4. Look in modules included in class of instance in reverse inclusion order
5. loop to step 3 with the super class of the current class looked at
until method or end of class hierarchy found
Actually steps 1 and 3 and 2 and 4 are the same so you could condense
this to three steps. Just listed for more clarity. You can see this
order by doing obj.singleton_class.ancestors - that gives you the
order in which classes and modules are traversed.
With refinements things get more complicated.
http://ruby-doc.org//core-2.2.0/doc/syntax/refinements_rdoc.html
You can, of course, view things in terms of a separate class inheritance hierarchy if you wish. In other languages this is literally true. But really, Ruby isn't _quite_ working like that.
The fact that anything is an object in Ruby (which is good and allows
to do quite some cool things, btw.) does not mean that mere objects
which are not instances of Class or Method are part of the inheritance
hierarchy. There is no generic object hierarchy that plays a role in
method lookup. It's all classes and modules.
Cheers
robert
On Mon, Nov 14, 2016 at 4:14 PM, Andy Jones <Andy.Jones@jameshall.co.uk> wrote:
--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/