42
Combining abstractions
Given the classes
¾
TRAIN_CAR
,
RESTAURANT
how would you implement a
DINER
?
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Combining Abstractions: Implementing Composite Figures through Multiple Inheritance, Papers of Programming Languages
The concept of composite figures and their implementation using multiple inheritance. It provides examples of composite figures derived from simple figures and discusses the notion of composite figures, their features, and merging. The document also covers name clashes and their resolution, as well as the special case of repeated inheritance.
Typology: Papers
Pre 2010
1 / 37
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Combining Abstractions: Implementing Composite Figures through Multiple Inheritance and more Papers Programming Languages in PDF only on Docsity!
Combining abstractions
Given the classes
TRAIN_CAR,
RESTAURANT
how would you implement a
DINER?
Examples of multiple inheritance
Combining separate abstractions:
Restaurant, train car
Calculator, watch
Plane, asset
Home, vehicle
Multiple inheritance: Composite figures
A composite figure
Simple figures
Defining the notion of composite figure
FIGURE
LIST
[
FIGURE
]
FIGURE COMPOSITE_
moverotatehidedisplay
removeputcount
A composite figure as a list
start
item
forth
after
Composite figures
class
COMPOSITE_FIGURE
inherit
FIGURE
redefine
display,
move,
rotate, ...
end
LIST [
FIGURE]
feature
display
is
-- Display each constituent figure in turn.
do
from
start
until
after
loop
item.
display
forth
end
end
... Similarly for
move,
rotate etc. ...
end
Multiple inheritance: Combining abstractions
COMPARABLE
NUMERIC
STRING
COMPLEX
INTEGER
REAL
DOUBLE
deferred class
COMPARABLE [G]
feature
less
alias
"<" (other: COMPARABLE [G]): BOOLEAN
is
enddeferred
end
le
alias
"<=" (other: COMPARABLE [G]): BOOLEAN
is
do
Result
:= Current < other
or
equal (Current, other)
end
ge
alias
">=" (other: COMPARABLE [G])
is …
greater ">" (other: COMPARABLE [G])
is …
Multiple inheritance: Name clashes
A
C
foo
foo
B
Resolving name clashes
A
C
foo
foo
B
rename
foo
as
fog
rename
foo
as
zoo
Feature merging
A
B
C
D
f*
f*
f+
Acceptable name clashes
If inherited features have all the same names, there is no
harmful name clash if:
They all have compatible signatures
At most one of them is effective
Semantics of such a case:
Merge all features into one
implementationIf there is an effective feature, it imposes its
Feature merging: with different names
class
D
inherit
A
rename
g
as
f
end
C B
rename
h
as
f
end
feature
...
end
Feature merging: effective features
A
B
C
D
g
f
h