Alex N. wrote in post #1105332:
Correct me if i’m wrong, but since when ruby 1.9 uses “name” for class
name? I always though that it’s Class.new.class.name or Class.class.name
that gives proper result.
As Jesus said: “The object x that is passed into the block is the class
that is being created by Struct.”
E.g.:
irb(main):001:0> Foo = Struct.new(:a) {|x| p [x, x.class] }
[#Class:0x0000000287a5a8, Class]
=> Foo
So my x is the actual Foo class object, not an instance of it. Thus
the following are effectively equivalent:
Foo = Struct.new(:a) do |x|
def x.bar
“#{name}bar”
end
end
class Foo
attr_accessor :a
def Foo.bar
“#{name}bar”
end
end
You can see that name is being called on the object on which the
method bar is defined, which is the object Foo, which is an instance
of
Class.
“Jesús Gabriel y Galán” [email protected] wrote in post
#1105307:
On Thu, Apr 11, 2013 at 7:38 PM, Love U Ruby [email protected]
wrote:
As you can see the class Customer has a name method.
If you create a class without assigning it to a constant, it doesn’t
have a name:
1.9.2p290 :009 > c = Class.new
=> #Class:0x00000002519990
1.9.2p290 :010 > c.name
=> nil
on the other hand:
1.9.2p290 :011 > C = Class.new
=> C
1.9.2p290 :012 > C.name
=> “C”
Really a new lesson for me. thank you very much for such an great
explanation. At least an impressive difference between c=Class.new and
C=Class.new object instantiation technique.
Hello,
the method is defined as x.greeting, which makes self in it reference
the object x - which is the class itself. And since the call to name is
with an implicit receiver, self is used. So the call to name is sent to
the class object, which returns the class’ name (through constant magic
the class’ name is set to “Customer”). Class.new.class.name is similar
in that we get the class of the new object and call it’s name method.
However, Class.class.name would not give the same result since we’d get
the class of the class object, which name is “Class” (because all
classes are instances of the class Class).
Hope I could help.
Regards,
Calvin
Julian L. wrote in post #1105341:
That’s a very worthy cause! 
The alternative is you could get and consume (thoroughly) the following
books which I think are absolutely excellent. The Ruby P.ming
Language, The Ruby Way and The Well-Grounded Rubyist.
I am done with the “The Well-Grounded Rubyist.” . As you suggest I will
start now with the other two of-course.
The reason I suggested real working code is that you need to engage your
feelings in the process otherwise things just won’t stick in your
memory, and stories are more emotive than examples. Stories have more
feeling, and real working code involves a story, whereas an example
doesn’t.
Thanks for writing the above.
The other thing I’d suggest is to look at the ruby spec. This will give
you an unfathomably deep understanding of ruby. IMHO.
Couldn’t get the upper line. 
That’s a very worthy cause!
Okay, in that case might I suggest for you to build it up yourself with
your own self reliance rather than asking questions.
Use IRB a LOT, and inspect the hell out of your variables and try to
understand things really well. Before you do this process you’re
undertaking, you might want to read up about Ruby metaprogramming and
understand it quite thoroughly at a low and deep level, because the
level of questions you’re asking are quite clearly outstripping your
capability (otherwise you wouldn’t have so many questions). Perhaps
that’s just exacerbated by the Struct class, I’m not sure.
A better way to do this might be to write some Ruby Koans for
yourself and the community, and in the process, you’ll be forced to
clearly and cleanly understand why and how things do what they do.
I guess you’re trying to understand the intent without truly
understanding the language at a deep level.
The alternative is you could get and consume (thoroughly) the following
books which I think are absolutely excellent. The Ruby P.ming
Language, The Ruby Way and The Well-Grounded Rubyist.
The reason I suggested real working code is that you need to engage your
feelings in the process otherwise things just won’t stick in your
memory, and stories are more emotive than examples. Stories have more
feeling, and real working code involves a story, whereas an example
doesn’t.
The other thing I’d suggest is to look at the ruby spec. This will give
you an unfathomably deep understanding of ruby. IMHO.
Julian
On Thu, Apr 11, 2013 at 7:12 PM, Love U Ruby [email protected]
wrote:
But I am making myself
educated on each class and the methods of that class. Otherwise I have
seen sometimes I write a complex code to get something,but ruby has a
built function to do that. Thus I think it is good to touch all the
methods at-least. So that wright things can be used at wright time.
Whatever “wright time” is. That approach won’t work well. You better
search for adequate implementations when you need them. Then you can
immediately use them and the learning effect will be much better -
unless
you have a photographic memory.
My 0.02 EUR
robert
Am 12.04.2013 08:47, schrieb Love U Ruby:
The other thing I’d suggest is to look at the ruby spec. This will give
you an unfathomably deep understanding of ruby. IMHO.
Couldn’t get the upper line. 
http://rubyspec.org/
Love U Ruby wrote in post #1105300:
===============================
Customer = Struct.new(:name, :address) do |x|
def x.greeting
“Hello #{name}!”
end
end
p Customer.greeting #=> “Hello Customer!”
You probably intended to write:
Customer = Struct.new(:name, :address) do
def greeting
“Hello #{name}!”
end
end
This will create a method named “greeting” on ALL of your Customer
structs. It’s a neat trick, since the method won’t be seen as a member
of the struct.
I like even more that you can include a module:
module Greeter
def greeting
“Hello #{name}!”
end
end
Customer = Struct.new(:name, :address) do
include Greeter
end
On Thu, Apr 18, 2013 at 11:41 PM, Scott S.
[email protected]wrote:
I like even more that you can include a module:
In other words: Struct generated classes are ordinary classes and the
block
passed to Struct.new is a class body as is the one passed to Class.new -
no
surprises here. 
irb(main):001:0> c=Class.new do
irb(main):002:1* def foo; 123 end
irb(main):003:1> end
=> #Class:0x8335bb4
irb(main):004:0> c.new.foo
=> 123
Kind regards
robert