[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: "static" declaration



Lieven Marchand wrote:
> "Anton van Straaten" <anton@appsolutions.com> writes:
>
> > The design of a properly interface-oriented set of Java classes
> > can be a significant improvement over similar classes in a
> > dynamically-typed OO language.  Support for multiple explicit
> > interfaces on a class allows for decoupling and factoring of
> > designs in ways that make a great deal of sense, but often
> > aren't practical to maintain in dynamically typed languages.
>
> You can do something very similar to interfaces with mixin classes
> in CLOS, or indeed in Flavors which got named for this capability.
> In what circumstances have you found this to be unpractical?

I was thinking of dynamically-typed OO languages that don't support an
explicit multiple-interface-like notion.  Traditional Smalltalk and the
languages which roughly follow its class model - e.g. current Python - allow
multiple interfaces implicitly, but don't provide any explicit features for
managing them, or even just identifying them.  This tends to make any
significant use of interfaces impractical.

I agree that any system with a mixin-like feature will support the same
basic approach - C++ is another example.  I don't have any experience with
big systems that use CLOS, so can't comment on its practicality in that
respect.

I do think that supporting multiple interfaces on objects puts additional
demands on a language.  When an object can have multiple interfaces, it's
helpful to identify which interface you're attempting to use, rather than
expect the reader of code to infer the interface from the operation being
performed.  That argues for some kind of type tagging in the code, even if
it's not full static typing.  But if you're making a point of using
interfaces as distinct entities, static typing seems like a logical step.

Anton