Types, Makers, and Inheritanc
Mark S. Miller
Wed, 11 Nov 1998 13:41:20 -0800
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
>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.