Loose type checking in E

[shap@eros.cis.upenn.edu]

> Maybe I should also point out that an object with "dozens" of
> methods is an exceptionally poor idea.

Nonsense.

Even in the context in which you made the comment, I don't think I
agree.  Buttons are windows, and windows are extremely complicated
objects (semantically speaking).

Setting arbitrary limits on interface size is misguided.  Simple
objects should have simple interfaces.  More complex objects may have
(and *need*) more complex interfaces.

I therefore prefer the view that an object's interface should be as
big as it needs to be to capture the complexity of the object -- but
no bigger.  Also, objects should be as simple as possible.

Before anyone winges about factoring, not all complex objects are
factorable.  Processes, for example, have a large amount of subtly
intertwingled state that really does need to be manipulated in many
variations.  You could factor the process, but you'ld then discover
that the factored objects had incestuous circular pointer
relationships.  This is an example in which making objects with
smaller interfaces did not equate to making simpler objects.

It has been my experience that when objects have incestuous circular
pointer relationships they have almost always been factored
excessively.  The *only* principled exception I know about is
container classes, wherein it is sometimes convenient for an object to
know its container.  The other exceptions I have seen in C++ are cases
where what you really wanted was interfaces and the language didn't
give you that.



shap