Lambda the Ultimate

inactiveTopic circle "is-a" ellipse: round 42
started 7/26/2001; 2:20:05 PM - last post 7/28/2001; 9:39:12 AM
paul jensen - circle "is-a" ellipse: round 42  blueArrow
7/26/2001; 2:20:05 PM (reads: 1168, responses: 4)

[for any of you still reading] I thought I'd trot out this link to dbdebunk, a site I find interesting where Chris Date and Fabian Pascal talk (authoritatively!) about relational databases.

There's an interesting article by Date there now regarding type inheritance, using the venerable circle-ellipse example.

The controversy seems to stem from the fact that while circles in the real world are not mutable, in software, circle "objects" are often expected to be. So, as Date says, we've got to distinguish between variables (which can change) and values (which can't).

As I was reading this article, I was thinking to myself that in a pure FP language such as Haskell, this shouldn't be an issue, since variables aren't allowed to change the values they contain.

Cheers,
Paul

PS: Of course, after reading this article, I realized that Date's article is cited in the Wiki already. Anyhoo, I think it's worth singling out as a worthwhile read.

Ehud Lamm - Re: circle "is-a" ellipse: round 42  blueArrow
7/27/2001; 2:52:31 AM (reads: 1220, responses: 0)
The Date article is indeed interesting. I didn't give it the attention it deserves, so I think I am going to read it carefuly, now that you mentioned it here. Thanks.

I am among those who think that using the notion of inheritance currently found in OOP languages, circle should not be derived from ellipse, nor the other way around.

We must remember that inheritance is about behaviour - not about structural relationships. This is part of the problem I have with the notion of inheritance. Inheritance is used to represent in programs, many kinds of different relations in the real world. Alas, all these different relations are different, so unifying them using one programming construct is bound fail .

paul jensen - Re: circle  blueArrow
7/27/2001; 8:40:01 AM (reads: 1212, responses: 0)

While I read the wiki discussion on this, I find myself asking questions like

  • What does it mean to say a circle or rectangle 'behaves' a certain way?

  • Do values in a FP language have 'behaviour'?

When I pose questions like this to my coworkers, they often give me a disturbed look, as though the answers are obvious. But I find these questions interesting and challenging, and I like thinking about them.

Cheers,
Paul

Ehud Lamm - Re: circle  blueArrow
7/27/2001; 10:55:45 AM (reads: 1213, responses: 0)
Well, such questions may be too vague at times...

I think it is useful to restrict concepts like 'behaviour' to an oop context, when studying this specific problem. (But do read the Liskov paper to get more perspective).

A Circle type will not support the same operations an Ellipse type has, or if we insist on supporting the same operations, we'll have to change the (implicit or explicit) contract.

Chris Rathman - Re: circle  blueArrow
7/28/2001; 9:39:12 AM (reads: 1199, responses: 0)
What does it mean to say a circle or rectangle 'behaves' a certain way?
From an OO perspective, a circle or rectangle class would encapsulate behavior such as "draw me", "fill me" or "resize me". Whether such behavior translates into the language of Euclidean geometry is not really relevant. What's relevant is that such behavior can be encapsulated within the object which is mimicking the geometric shape.

Do values in a FP language have 'behaviour'?
Object oriented programming can be done in practically any language. It's really of question of how you organize and think about the data and behavior. As Lisp has taught us, the distinction between functions and data is a gray one.

That said, FP languages are designed to reward a certain type of programming style. Trying to use behavior as the basis for organization in an FP language can be torturous - akin to writing Functional style programs in an assembly language.

The controversy seems to stem from the fact that while circles in the real world are not mutable, in software, circle "objects" are often expected to be. So, as Date says, we've got to distinguish between variables (which can change) and values (which can't).
Interestingly, since variables are write-once (immutable) in functional style languages, the use of inheritance doesn't pose the problem in causing the mutation to a different class.

More generally, though, I would think that the theoretical foundations about the theory of types is not something that is complete. How one uses taxonomy to define a series of types is somewhat influenced about the need to have a theoretically solid basis for such classification. But more importantly, it's a question of utilitarianism - does it make life simpler for the engineer that is faced with using that structure.

Inheritance may not be the be all scheme, but over time, it can lead to a useful hierarchy of classes. That's why in languages that have the luxory to evolve and mature the base libraries (like Smalltalk) are useful. Whereas immature libraries tend to cause grief.

Speaking of Smalltalk, it has long been commented in ST circles that one should not be prematurely forced into elaborate hierarchies for development. Specifically, languages like Java and Eiffel require you to figure out the hierarchy of classes up front. The dynamic languages like ST, however, let you write a flat structure of classes - Type is really determined by the ability of an object to respond to a message. This let's you use inheritance as convenience mechanism rather than a requirement for establishing the pecking order of types.