Re: Static vs. Dynamic typing

From: Dave Harris (brangdon_at_cix.co.uk)
Date: 07/24/04 

Date: Sat, 24 Jul 2004 19:54 +0100 (BST)

mchristoff@sympatico.caREMOVETHIS (Michael N. Christoff) wrote (abridged):
> If you call methods with an expectation of their semantics (ie: you
> expect that when you call a particular draw() method your video game
> gun fighter will draw his gun), why is it such a burden to use a
> GunFighter interface?

Because there may be things other than GunFighters which can draw() with
the correct semantics.

Let's say we have GraphicObject with draw(), rotate(), translate(),
recolour() and so forth. If all we want to do is draw them, then demanding
those other methods is over-specification. It prevents the code from
working with objects which are drawable but not rotatable.

> > This issue of the granularity of semantics specifications is
> > orthogonal to the issue of when those specifications are checked.
>
> I agree - it seems much more like an application design issue. Do I
> make draw() part of the GunFighter interface or do I have have a
> generic Drawable interface and use interface inheritance, or...?
> You seem to be advocating including all this static type information
> and then not checking it at compile time simply because it can be
> done efficiently at runtime.

The efficiency thing was dismissing an argument against it, not giving an
argument in favour of it.

First I'm saying there are two views of type, producer and consumer, and
their needs are different. For the producer side (ie the person
implementing a type) there's no problem with coarse granularity. I have to
implement all of the GunFighter methods so I don't mind if my type
specifies them all. (This view more or less conforms to Smalltalk's
classes.)

>From the consumer's point of view (ie a routine which accepts a GunFighter
as argument), I want to call just a handful of methods on it. For maximum
flexibility, I want a type which specifies exactly that handful and no
more. The full GunFighter interface is bigger than I need.

The core of the problem is that there are /lots/ of consumers, all wanting
a different subset of the GunFighter interface. It just isn't worth the
effort of explicitly reifying each useful subset as a named type; there
are too many. But mainstream static checking requires a named interface to
check against, so consumers end up reusing GunFighter even though that's a
massive over-specification.

> In effect taking the extra time required for specifying static
> types while not using a main benefit of them.

I'm agreeing with you that it's a good thing to specify the semantics of
methods, and to check their use against their specification. I'm arguing
against explicitly bundling such methods up into big interfaces and then
doing type conformance between interfaces explicitly, because that's what
produces the problem of over-specification. Everything explicit,
everything hard-wired and rigid, everything over-specified.

Mainstream dynamic checking is a win here because the conformance is
implicit. You could have a static language in which conformance was also
implicit, and still checked at compile-time. That would be fine as far as
this sub-thread is concerned. That's why I'm saying this is not really
about static versus dynamic. What I'm disagreeing with is your assertion
(as I read it) that semantics can only be specified and checked at
coarse-grained scale, and hence only statically. If it's done at the scale
of individual messages, then semantics can be checked dynamically too.

(Actually it might be best to specify semantics at the coarse
class/interface scale, but use and check them at the fine, individual
message scale. You just have to know which version of draw() the caller
intended. Which you do with selector namespaces.)

-- Dave Harris, Nottingham, UK

Relevant Pages

  • Re: Static vs. Dynamic typing
    ... > If you call methods with an expectation of their semantics (ie: ... > GunFighter interface? ... I want a type which specifies exactly that handful and no ...
    (comp.programming)
  • Re: Interface freeloading on a superclass - is it good practice?
    ... > Who's talking about changing any method signatures? ... > the subject of any interface contracts written by the same authors of the ... any future changes to the *precise semantics* of the methods ... Because Sun don't know or care about your interface's rigid semantic ...
    (comp.lang.java.programmer)
  • Re: Tell, Dont Ask
    ... The whole point was for Range to ensure its own invariant. ... Here my solution was constrained by separate setHigh and SetLow interface methods in the original example. ... If that is all of the semantics of Range that is relevant to the problem in hand, then I would probably provide setValueand let Range determine whether its internal High or Low gets set based on the invariant. ... The 'require' in Range enforces an invariant that is implicit in the semantics of a 'range'. ...
    (comp.object)
  • Re: Classes as units of reuse
    ... One can see this in something as simple as a String class where different libraries will provides somewhat different interfaces for basically the same semantics. ... This is manifested during reuse when a client in a new reuse context wants to access the object semantics using a different interface than the one provided by the object's class. ... However, such overhead is usually not excessive at larger scales, such as subsystems because it is small compared to the subsystem functionality. ... The high level view enabled us to deal with high level control in a quite elegant fashion because at that level of abstraction we didn't care what the individual data element values were; we just needed to manipulate the aggregate. ...
    (comp.object)