UML uses the convention that any arrow will point in the direction of a
dependency. So A->B implies that A depends on B (in some way). As
Chris points out, there are many different kinds of dependencies
(represented in UML as different kinds of arrows, e.g. open arrowhead,
dashed lines).
Following this convention, we would have …
File → IO
Array → Enumerable
etc
Of course, your diagram isn’t UML, but the convention is a good one to
follow.
···
On Wed, 2003-04-23 at 18:16, Hal E. Fulton wrote:
Maybe I should just reverse the arrowheads? On the other
hand, the only other red arrow is IO → File. Maybe I
could reverse that one instead.
OK, I see. So my blue arrows already follow that convention,
but the File-IO arrow does not.
What’s your take on the circularity at the top? Chris says
that Object doesn’t take anything from Class. I thought it
did. I’ll have to think about that tomorrow.
Maybe I could use magenta arrows with heads at both ends.
Hal
···
----- Original Message -----
From: “Jim Weirich” jweirich@one.net
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, April 23, 2003 9:25 PM
Subject: Subject: Re: [ANN] Ruby.shop
On Wed, 2003-04-23 at 18:16, Hal E. Fulton wrote:
Maybe I should just reverse the arrowheads? On the other
hand, the only other red arrow is IO → File. Maybe I
could reverse that one instead.
UML uses the convention that any arrow will point in the direction of a
dependency. So A->B implies that A depends on B (in some way). As
Chris points out, there are many different kinds of dependencies
(represented in UML as different kinds of arrows, e.g. open arrowhead,
dashed lines).
Following this convention, we would have …
File → IO
Array → Enumerable
etc
Of course, your diagram isn’t UML, but the convention is a good one to
follow.
What’s your take on the circularity at the top? Chris says
that Object doesn’t take anything from Class. I thought it
did. I’ll have to think about that tomorrow.
dave[Work/rubybook 1:59:09] irb
irb(main):001:0> Object.class
=> Class
I had to fire up IRB to investigate this. Remember, there are different
kinds of dependencies/relationships. There is the releationship between
a specific instance and its class (Fido is a Great Dane). There is also
the relationship between a class and a more general class (Great Dane
are a subclass of Dog). In Ruby, the first (object=>class) relationship
is represented by the “class” method. The second (subclass=>superclass)
by the “superclass” method.
Since Classes are Objects in Ruby, every class will have an
(object=>class) as well as a (subclass=>superclass) relationship.
For example …
class Dog; end
class GreatDane < Dog; end
fido = GreatDane.new
fido.class => GreatDane
GreatDane.class => Class
GreatDane.superclass => Dog
NOTE: I used a cheap UML drawing tool that rendered <> into
?class? when generating a JPEG file. Yuck.
The open head arrows (eg. from Class to Module) represent the
(subclass=>superclass) relationship. The arrows marked ?class? are the
(object=>class) relationship. As you can see, every class object in
the diagram has a class pointer to Class (even Class itself). All of
the white boxes in your diagram should have a class pointer to Class.
Since you are using color (White boxes for classse, blue for modules),
including the class arrow in your diagram would be redundant, I think I
would omit it. That would remove the apparent circularity from Object
to Class. If you decided to leave it in, then I would consider adding all the class relationships, otherwise you leave the impression that
there is something unique about Object.
I also put Kernel into the diagram. Since the Kernel object is not a
Class, but a Module, its ?class? arrow points appropriately at Module.
I also show an ?includes? arrow from Object to Kernel. There you get an
interesting circularity where each link in the circle is a different
kind of link.
Does this help?
···
On Wed, 2003-04-23 at 23:10, Hal E. Fulton wrote:
What’s your take on the circularity at the top? Chris says
that Object doesn’t take anything from Class. I thought it
did. I’ll have to think about that tomorrow.
Maybe I could use magenta arrows with heads at both ends.
Sure, the class of Object is Class… or
in other words, Object is an instance of
class Class… but that’s not saying that
Object inherits from Class.
In fact I suppose it’s the opposite:
irb(main):014:0> Class < Object
true
irb(main):015:0> Object < Class
false
This always confuses me. I guess there is
a failure in the circularity once you go
all the way around… otherwise in a
circular dependency with three items, you
could show X < Y for any X, Y.
Perhaps the bottom line is that my red
arrows are all backward?
Hal
···
----- Original Message -----
From: “Dave Thomas” dave@pragprog.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, April 23, 2003 10:31 PM
Subject: Re: Subject: Re: [ANN] Ruby.shop
Hal E. Fulton wrote:
What’s your take on the circularity at the top? Chris says
that Object doesn’t take anything from Class. I thought it
did. I’ll have to think about that tomorrow.
dave[Work/rubybook 1:59:09] irb
irb(main):001:0> Object.class
=> Class
What’s your take on the circularity at the top? Chris says
that Object doesn’t take anything from Class. I thought it
did. I’ll have to think about that tomorrow.
dave[Work/rubybook 1:59:09] irb
irb(main):001:0> Object.class
=> Class
irb(main):001:0> Module.class
=> Class
irb(main):002:0> Class.class
=> Class
irb(main):003:0> File.class
=> Class
What are you trying to say by this? There is no line from Module to Class,
or from File to Class (or from Class to itself). I think Hal is trying to
show inheritance, and while Object is a Class, objects are not classes.
What’s your take on the circularity at the top? Chris says
that Object doesn’t take anything from Class. I thought it
did. I’ll have to think about that tomorrow.
dave[Work/rubybook 1:59:09] irb
irb(main):001:0> Object.class
=> Class
Object is a class, yes. But objects are not classes. Are you documenting
Object, or are you documenting objects?
Perhaps the bottom line is that my red
arrows are all backward?
No. Here’s what I think about your arrows:
First, change all blue arrows to red, since they basically mean the same
thing (objects of class A get functionality from class/module B).
Second, switch your IO → File arrow to be File → IO. You just made a
mistake there.
Third, either get rid of the Object → Class arrow (since, as you pointed
out, Object does not inherit from Class), or change it to a blue line. A
blue line would mean “point to your class”. Every class (Object, Module,
and even Class itself) should have a blue line pointing to Class, if you
decide to include blue lines at all; likewise, every module would have a
blue line pointing to Module. This is the only line from Object to Class.
Why include it unless you are also including the blue line from Class to
itself? Or from Module to Class?
I wouldn’t suggest putting in the blue lines at all unless you are going to
include some non-class/module objects in the picture; otherwise, all of your
blue lines just point to Class or Module, and it creates a lot of clutter.
But, if you wanted, you could have “hello” → String and 5 → Fixnum (both
blue lines, exactly like Object → Class, and totally unlike Fixnum →
Integer).
There’s a lot of confusion about this, and there doesn’t need to be. If you
are going to include a line from Object to Class, please consider that
that relationship is no different from Module → Class, or File →
Class, or Class → Class. Why include one line and not the others?
What are you trying to say by this? There is no line from Module to Class,
or from File to Class (or from Class to itself). I think Hal is trying to
show inheritance, and while Object is a Class, objects are not classes.
Chris:
FWIW, I understand that
You two were getting into knots because the wording being used wasn’t
precise. Hal said “Object doesn’t take anything from Class”, but clearly
it does. It takes its class.
A suggestion for this thread: I don’t think you even need to consider
“kind_of?” style relationships for the main diagram. The main diagram is
all about superclasses (direct and implicit via ‘include’). Keep it
simple that way.
The Object.is_a? Object diagram is totally different, and shouldn’t be
confused with the first. It’s all to do with metaclasses. Different
notations should apply.
Perhaps the bottom line is that my red
arrows are all backward?
No. Here’s what I think about your arrows:
First, change all blue arrows to red, since they basically mean the same
thing (objects of class A get functionality from class/module B).
Second, switch your IO → File arrow to be File → IO. You just made a
mistake there.
Third, either get rid of the Object → Class arrow (since, as you pointed
out, Object does not inherit from Class), or change it to a blue line.
A
blue line would mean “point to your class”. Every class (Object, Module,
and even Class itself) should have a blue line pointing to Class, if you
decide to include blue lines at all; likewise, every module would have a
blue line pointing to Module. This is the only line from Object to
Class.
Why include it unless you are also including the blue line from Class to
itself? Or from Module to Class?
I wouldn’t suggest putting in the blue lines at all unless you are going
to
include some non-class/module objects in the picture; otherwise, all of
your
blue lines just point to Class or Module, and it creates a lot of clutter.
But, if you wanted, you could have “hello” → String and 5 → Fixnum
(both
blue lines, exactly like Object → Class, and totally unlike Fixnum →
Integer).
There’s a lot of confusion about this, and there doesn’t need to be. If
you
are going to include a line from Object to Class, please consider that
that relationship is no different from Module → Class, or File →
Class, or Class → Class. Why include one line and not the others?
Hmmmm. Well, I have always perceived some circularity
in Ruby’s object model, and I guess I wanted to see
an explicit loop in the drawing.
I guess this perception can be said to stem from the fact
that classes are objects. If you came from C++ and Java,
as I did, you can see this would seem esoteric.
Apparently the loop in Matz’s original drawing shows that
the circularity is not entirely in my head… but can I
omit the singleton classes and still depict that loop?
Hal
···
----- Original Message -----
From: “Chris Pine” nemo@hellotree.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, April 24, 2003 12:10 AM
Subject: Re: Subject: Re: [ANN] Ruby.shop
I know; I learned it from you. Your words carry a lot of weight around
here, but that email had so few, I was worried that it might not be clear to
someone else what you were saying. I thought (and was right) that you were
saying “there is a relationship between Object and Class, but you still
should not include that arrow”. I wasn’t sure that was clear from your
brief post.
A suggestion for this thread: I don’t think you even need to consider
"kind_of?" style relationships for the main diagram. The main diagram is
all about superclasses (direct and implicit via ‘include’). Keep it
simple that way.
Amen! So no arrow from Object to Class, and all arrows the same color.
(And File points to IO.)
Properly understood, there isn’t a loop in the class',superclass’, or metaclass' relationships; it's confusing, but you want your poster to *eliminate* that confusion. Thekind_of?’ relationship has loops all over
the place, but it is also a one-to-many relationship, so it’s hard to draw
those arrows. However, a picture with class and superclass relationships
clearly drawn makes figuring out `kind_of?’ easy.
However, I agree with Dave; leave out the class and metaclass arrows.
There’s only so much you can do with one picture.
I guess this perception can be said to stem from the fact
that classes are objects. If you came from C++ and Java,
as I did, you can see this would seem esoteric.
Yep, it sure is easy when the sets of objects and classes are disjoint!
(Plus, no metaclasses.) In that case, even though the relationships are
still just as different as in Ruby, you can relax about it because everyone
has only one arrow, anyway; what difference the color?
Apparently the loop in Matz’s original drawing shows that
the circularity is not entirely in my head… but can I
omit the singleton classes and still depict that loop?
(I’m going to assume there’s a method `metaclass’ which will return a
class’s metaclass; it’s singleton class.)
There are two paths from Object to Class:
Object.class == Class
Object.metaclass.superclass == Class
These are totally different; in any case, since you are showing `superclass’
everywhere else (which is also what goes on behind the scenes when you
include a module into a class), I would say stick with that. After all:
Object.superclass != Class
And metaclass is not the same as superclass.
Aside from the very messy, one-to-many relationship if kind_of?', there is only one loop which exists for any of the relationships is this one for theclass’ relationship:
Class.class == Class
I don’t think you need a loop in your picture, because there really isn’t
one.
Properly understood, there isn’t a loop in the class',superclass’, or metaclass' relationships; it's confusing, but you want your poster to *eliminate* that confusion. Thekind_of?’ relationship has loops all over
the place, but it is also a one-to-many relationship, so it’s hard to draw
those arrows. However, a picture with class and superclass relationships
clearly drawn makes figuring out `kind_of?’ easy.
However, I agree with Dave; leave out the class and metaclass arrows.
There’s only so much you can do with one picture.
I guess this perception can be said to stem from the fact
that classes are objects. If you came from C++ and Java,
as I did, you can see this would seem esoteric.
Yep, it sure is easy when the sets of objects and classes are disjoint!
(Plus, no metaclasses.) In that case, even though the relationships are
still just as different as in Ruby, you can relax about it because everyone
has only one arrow, anyway; what difference the color?
Apparently the loop in Matz’s original drawing shows that
the circularity is not entirely in my head… but can I
omit the singleton classes and still depict that loop?
(I’m going to assume there’s a method `metaclass’ which will return a
class’s metaclass; it’s singleton class.)
There are two paths from Object to Class:
Object.class == Class
Object.metaclass.superclass == Class
These are totally different; in any case, since you are showing `superclass’
everywhere else (which is also what goes on behind the scenes when you
include a module into a class), I would say stick with that. After all:
Object.superclass != Class
And metaclass is not the same as superclass.
Aside from the very messy, one-to-many relationship if kind_of?', there is only one loop which exists for any of the relationships is this one for theclass’ relationship:
Class.class == Class
I don’t think you need a loop in your picture, because there really isn’t
one.
Properly understood, there isn’t a loop in the class',superclass’, or metaclass' relationships; it's confusing, but you want your poster to *eliminate* that confusion. Thekind_of?’ relationship has loops all over
the place, but it is also a one-to-many relationship, so it’s hard to draw
those arrows. However, a picture with class and superclass relationships
clearly drawn makes figuring out `kind_of?’ easy.
However, I agree with Dave; leave out the class and metaclass arrows.
There’s only so much you can do with one picture.
I guess this perception can be said to stem from the fact
that classes are objects. If you came from C++ and Java,
as I did, you can see this would seem esoteric.
Yep, it sure is easy when the sets of objects and classes are disjoint!
(Plus, no metaclasses.) In that case, even though the relationships are
still just as different as in Ruby, you can relax about it because everyone
has only one arrow, anyway; what difference the color?
Apparently the loop in Matz’s original drawing shows that
the circularity is not entirely in my head… but can I
omit the singleton classes and still depict that loop?
(I’m going to assume there’s a method `metaclass’ which will return a
class’s metaclass; it’s singleton class.)
There are two paths from Object to Class:
Object.class == Class
Object.metaclass.superclass == Class
These are totally different; in any case, since you are showing `superclass’
everywhere else (which is also what goes on behind the scenes when you
include a module into a class), I would say stick with that. After all:
Object.superclass != Class
And metaclass is not the same as superclass.
Aside from the very messy, one-to-many relationship if kind_of?', there is only one loop which exists for any of the relationships is this one for theclass’ relationship:
Class.class == Class
I don’t think you need a loop in your picture, because there really isn’t
one.
So you still get the loop but with the arrow from Object to Class being
of a different colour.
We have the “representation problem” because classes are objects, so you
have to find some way to distinguish between the properties of classes
and their instances.
···
On Thu, Apr 24, 2003 at 05:43:08PM +0900, Hal E. Fulton wrote:
Apparently the loop in Matz’s original drawing shows that
the circularity is not entirely in my head… but can I
omit the singleton classes and still depict that loop?
However, I agree with Dave; leave out the class and metaclass arrows.
There’s only so much you can do with one picture.
I guess this perception can be said to stem from the fact
that classes are objects. If you came from C++ and Java,
as I did, you can see this would seem esoteric.
Yep, it sure is easy when the sets of objects and classes are disjoint!
(Plus, no metaclasses.) In that case, even though the relationships are
still just as different as in Ruby, you can relax about it because
everyone
has only one arrow, anyway; what difference the color?
I see your point about not confusing the class and superclass
relationships. And I never intended to depict metaclass
relationships.
And yes, the arrow from Object to Class is simply
erroneous.
But as for arrow color: Is it not worthwhile distinguishing
between “X inherits from Y” and “X mixes in Y”? Of course,
I already distinguish between modules and classes by putting
them on opposite sides of the diagram (and by using different
background colors). Thoughts? I don’t want to prolong this
thread forever, though.
Hal
···
----- Original Message -----
From: “Chris Pine” nemo@hellotree.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, April 24, 2003 9:29 AM
Subject: Re: Subject: Re: [ANN] Ruby.shop
It doesn’t seem important to me either way, so I would leave them all the
same color by default. The two concepts are so similar… as I understand
it, when X mixes in Y, X is just inheriting from Y’s proxy class.
I think of these arrows as saying, “These are the methods you can call this
kind of object.” In that light, it makes no difference if it is getting
them from a class or from a module.
But as for arrow color: Is it not worthwhile distinguishing
between “X inherits from Y” and “X mixes in Y”?
It doesn’t seem important to me either way, so I would leave them all the
same color by default. The two concepts are so similar… as I understand
it, when X mixes in Y, X is just inheriting from Y’s proxy class.
I think of these arrows as saying, “These are the methods you can call
this
kind of object.” In that light, it makes no difference if it is getting
them from a class or from a module.
True. I’m still inclined to distinguish on the
basis that when you inherit, you (can) get instance
data, whereas when you mix in, you typically don’t.
As I think about this, though, even that may be a
false distinction. What do you think?
Hal
···
----- Original Message -----
From: “Chris Pine” nemo@hellotree.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, April 24, 2003 11:39 AM
Subject: Re: Subject: Re: [ANN] Ruby.shop
On the Ruby side of things, I think the distinction is false. Modules are
basically a form of multiple inheritance. They can do anything with
instance data that classes can.
On the human side of things, however, there’s an important distinction.
Matz made modules and disallowed multiple inheritance. These are largely
(only?) conceptual distinctions, but that doesn’t mean they aren’t
important. Even if modules are just classes without `new’ (which, BTW, we
could easily add), we use them differently.
So, on the Ruby side, the distinction seems false. On the human side, the
distinction seems important. It seems to me (just one guy’s opinion) that
coloring modules a different color, but making the arrows all the same
color, expresses this well.
