![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
http://roots.iai.uni-bonn.de/research/darwin/delegation
This is the sort of abstract nonsense where it makes a difference. :-)
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> http://roots.iai.uni-bonn.de/research/darwin/delegation
Maybe not completely related, but I find it curious how some
object-oriented concepts talk about inheritance about one class/object
extending another, while others talk about specializing, although they
are technically speaking usually the same thing.
However, conceptually there's a difference. "Extensions" means,
conceptually, that a class has all the same properties as another class
plus new properties of its own. Thus the inherited class has more features
than the base class, and thus it's an extension of the base class. Some
object-oriented languages even go so far as using the keyword "extends"
to denote inheritance.
In some inheritance hierarchies "extension" is a rational concept. For
example, if you have a base class named Image, and you inherit from it a
derived class called PNGImage, which is an Image with PNG reading/writing
support, you are conceptually extending the base class: It supports
everything that Image supports, plus more: Reading and writing PNG data.
However, with other inheritance hierarchies you hit some conceptual
difficulties. For example, if you have a base class named Animal and
you inherit a class named Dog from it, can you say that "Dog extends
Animal"? Is a Dog something which does more than an Animal? Technically
speaking, at the class level, this may be the case, but conceptually it
makes less sense.
This is where the concept of specialization kicks in. It doesn't make
too much sense to say "Dog extends Animal", but it makes a whole lot more
sense to say "Dog is a special kind of Animal". In other words, Dog
specializes Animal. Animal is a more generic, more abstract concept,
while Dog is a more specific, more concrete concept.
Personally I think specialization is the better concept in object-oriented
inheritance because it can be better applied to almost all (well-designed)
inheritance situations, while extension can't. For example, you can
perfectly well say that "PNGImage is a special kind of Image" (ie. one
which supports PNG reading/writing), in other words, specialization can
be used at a conceptual level also in this example, while the other way
around it made less sense.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Warp" <war### [at] tag povray org> wrote in message
news:49a876d4@news.povray.org...
> In some inheritance hierarchies "extension" is a rational concept. For
>example, if you have a base class named Image, and you inherit from it a
>derived class called PNGImage, which is an Image with PNG reading/writing
>support, you are conceptually extending the base class: It supports
>everything that Image supports, plus more: Reading and writing PNG data.
>
> However, with other inheritance hierarchies you hit some conceptual
> difficulties. For example, if you have a base class named Animal and
> you inherit a class named Dog from it, can you say that "Dog extends
> Animal"? Is a Dog something which does more than an Animal?
Sure, dog is to animal as PNGImage is to Image. Dog can do things (other)
animals cannot, such as barking. Thus dog extends animal.
PNGImage extending or "descending from" (I seem to like this term better,
more neutral) Image should be as strange (or natural, take your pick) as Dog
descending from Animal. I think the "problem" here is that many people think
of the term "animal" as sum of instances and descendents, rather than the
common denominator. If I tell you that I saw an animal this morning, you
probably come up with mental images of dogs, cats, horses... etc, instead of
mental image of something alive that moves.
> Personally I think specialization is the better concept in
object-oriented
> inheritance because it can be better applied to almost all (well-designed)
> inheritance situations, while extension can't. For example, you can
> perfectly well say that "PNGImage is a special kind of Image" (ie. one
> which supports PNG reading/writing), in other words, specialization can
> be used at a conceptual level also in this example, while the other way
> around it made less sense.
Yes, it seems to make sense until you get to multiple inheritance and start
thinking about context.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
somebody wrote:
> Yes, it seems to make sense until you get to multiple inheritance and start
> thinking about context.
Or until you start looking at the type system mathematically (like Liskov
substitutability and such), where the term you use is irrelevant compared to
the semantics.
But the term one uses for making a subclass can certainly be different
depending on the real-world relationship the classes are supposed to
correspond to.
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 2/27/2009 3:27 PM, Warp wrote:
> However, with other inheritance hierarchies you hit some conceptual
> difficulties. For example, if you have a base class named Animal and
> you inherit a class named Dog from it, can you say that "Dog extends
> Animal"? Is a Dog something which does more than an Animal? Technically
> speaking, at the class level, this may be the case, but conceptually it
> makes less sense.
And then you realize that, although we call them "objects," they are
really just abstract representations of certain pieces of information,
and not really the objects we think of them as :)
--
...Chambers
www.pacificwebguy.com
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp <war### [at] tag povray org> wrote:
> Maybe not completely related, but I find it curious how some
> object-oriented concepts talk about inheritance about one class/object
> extending another, while others talk about specializing, although they
> are technically speaking usually the same thing.
As these terms are commonly used, yes. It can be defined more strictly though,
to show the differences:
"Extending" can be defined as *adding* to an interface, where "specializing" can
be defined as *modifying* the implementation of an interface.
Both are an example of polymorphism; however, only the former requires runtime
type checking, while only the latter requires runtime method lookup.
So they are in fact orthogonal, and any sane OO language supports both -
although they often use either of the two terms in the broader synonymous
sense.
I like C# in this respect, as it requires you to be clear about which methods
you add (= extending) and which you override (= specializing). If that doesn't
match up with the base class, C# will force you to stop and rethink about it.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chambers <ben### [at] pacificwebguy com> wrote:
> And then you realize that, although we call them "objects," they are
> really just abstract representations of certain pieces of information,
> and not really the objects we think of them as :)
.... yet the "objects" (some also refer to them as "instances", which may be a
more fitting term) are more concrete than the "classes" (or "types", as some
call them) - which again are more concrete than the "interfaces" (sometimes
known as "abstract classes" or "abstract types" in languages that don't
explicitly support the notion of interfaces) they implement...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka wrote:
> I like C# in this respect, as it requires you to be clear about which methods
> you add (= extending) and which you override (= specializing). If that doesn't
> match up with the base class, C# will force you to stop and rethink about it.
But that's really more for the whole "fragile base class" problem than it is
a "stop and think" kind of thing. In other words, it really only kicks in
when you modify the base class after you've already compiled derivative classes.
(It's that sort of forward-looking feature that convinces me C# is very well
thought out in many ways.)
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |