Looking for Killer Metaphor 
Author Message
 Looking for Killer Metaphor

I'm teaching Eiffel and have gotten to the Central Mystery of Eiffel.
(Every religion has a central mystery). How to explain the Central Mystery
to the accolates? We need a Killer Metaphor, which at a glance makes the
whole thing obvious.

The Central Mystery of Eiffel is of course:
---------------------------------------------------
class CME inherit
        B
                rename foo as std_foo end
        B
                redefine foo select foo end
feature
        foo is
        do
                std_foo; some_other_stuff
        end
end

x:B
y:CME
!!y;
x := y
x.foo
------------------------------------------
Here's my best metaphor so far, but you can do better, can't you? Please?

Think of a class as a factory that makes circuit boards that have pins
sticking up that represent the features like the pins under the keys
on a keyboard. The factor also makes keyboards that fit on top of
the pins. The keyboards are variables, and the circuit boards are
the objects. The direct reattachment operator puts the keyboard onto
the pins, and when you press the key labeled "foo", the corresponding
"foo" process is fired in the board.

Different factories make different, incompatible, keyboards. However, some
factories get licenses from others, called inheritance, which allows them
to use the original design. New pins might be added, and the corresponding
keyboard can't be used on the parent object because it has too many keys,
but you can use the parent's keyboard on the child object. You won't be able
to use the new features, but the old keys will still work under their old
names. If the circuitry corresponding to one of the old keys has been
changed (redefinition), the old keyboard foo press fires off the new circuit
(dynamic binding). In the case of the CM, the new factory used two of the
original foo circuits. It modified the old one under the original key foo,
and put a new key on top of the second copy labeled std_foo. The new
foo happens to use the old foo circuit in this example, but it didn't have to.
When a child simply renames a feature without redefinition, it is simply having
a different symbol on the keyboard it makes at that position.

Paul F. Dubois
Chief Computer Scientist
Computational Physics Division
L-472
Lawrence Livermore National Laboratory
Livermore, CA 94550
(510)-423-9080
FAX (510)-423-9969



Tue, 01 Apr 1997 06:44:14 GMT  
 Looking for Killer Metaphor

Quote:

>The Central Mystery of Eiffel is of course:
>---------------------------------------------------
>class CME inherit
>    B
>            rename foo as std_foo end
>    B
>            redefine foo select foo end
>feature
>    foo is
>    do
>            std_foo; some_other_stuff
>    end
>end

>x:B
>y:CME
>!!y;
>x := y
>x.foo
>------------------------------------------
>Here's my best metaphor so far, but you can do better, can't you? Please?

>Think of a class as a factory that makes circuit boards that have pins
>sticking up that represent the features like the pins under the keys
>on a keyboard. The factor also makes keyboards that fit on top of
>the pins. The keyboards are variables, and the circuit boards are
>the objects. The direct reattachment operator puts the keyboard onto
>the pins, and when you press the key labeled "foo", the corresponding
>"foo" process is fired in the board.

>Different factories make different, incompatible, keyboards. However, some
>factories get licenses from others, called inheritance, which allows them
>to use the original design. New pins might be added, and the corresponding
>keyboard can't be used on the parent object because it has too many keys,
>but you can use the parent's keyboard on the child object. You won't be able
>to use the new features, but the old keys will still work under their old
>names. If the circuitry corresponding to one of the old keys has been
>changed (redefinition), the old keyboard foo press fires off the new circuit
>(dynamic binding). In the case of the CM, the new factory used two of the
>original foo circuits. It modified the old one under the original key foo,
>and put a new key on top of the second copy labeled std_foo. The new
>foo happens to use the old foo circuit in this example, but it didn't have to.
>When a child simply renames a feature without redefinition, it is simply having
>a different symbol on the keyboard it makes at that position.

I understood OOP before I read this. :-)


Fri, 04 Apr 1997 22:18:05 GMT  
 Looking for Killer Metaphor
 > I understood OOP before I read this. :-)

I agree.

Why not use the classification system of the animal world as your
metaphor, if you really feel the need for one?  animals species etc etc,
each having the basic characteristics of the level above, but adding it's
own additional characteristics.
I understood OO ideas derive at least partially from the classification
work of people such as Linnaeus.

Dave.



Sun, 06 Apr 1997 04:28:09 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Looking for Modula-2 Killers

2. Design by Metaphor

3. what is the best metaphor for this?

4. Mixed Metaphors (Was: Are Forth Chips RISCs?)

5. Metaphor Revisited

6. LOGO-L> Spatial metaphor for Superturtle

7. Programming Metaphors

8. Oberon windows metaphor shift.

9. metaphor and programming

10. Great metaphor

11. L4: Lifestreams, Living Metaphor, Linda on the Web, LISP

12. replacing the desktop metaphor

 

 
Powered by phpBB® Forum Software