Types, Makers, and Inheritanc

[Mark S. Miller]

At 09:53 PM 10/20/98 , Tyler Close wrote:
>At 05:31 PM 10/20/98 -0700, you wrote:
>>On Tue, 20 Oct 1998, Tyler Close wrote:
>>> I don't see how it's necessary to have Type objects in order to have an
>>> interface to an instance object. In C++, I never had a need or desire for
>>> Type objects.
>>
>>That's because the C++ compiler checks types for you.  In a
>>dynamically-typed language like E (or Python, etc.) it's useful
>>to be able to check and compare the types of things at runtime.
>
>Well, I have to admit that I haven't done a lot of work in untyped
>languages, but I wasn't expecting to change my designs all that much. I
>don't see why I should allow my program to loose track of what kind of
>objects it's dealing with just because the compiler is no longer doing
>static type checking.

[+] You are correct, 
but please see my gui-enhanced command interpreter for a motivating example.


>Are you really suggesting that you want to do stuff like:
>
>if(x getType isa Foo)
>{
>	# do a Foo thing
>}
>else if(x getType isa Bar)
>{
>	# do a Bar thing
>}
>else
>	...
>
>This seems like crappy design to me.

[+] This is an excellent heuristic, but it does have justified exceptions.  
It is also independent of whether you have static type checking.  I
occasionally find a justified use of the equivalent pattern in Java (using
instanceof).  When you control all the code in a system, then any dispatch
like the above can (and usually should) be turned instead into methods on
class Foo and Bar.  However, especially in a distributed system of mutually
suspicious players, you often aren't in a position to change Foo and Bar.