Re: OCP and Java

From: Thomas Gagne (tgagne_at_wide-open-west.com)
Date: 02/08/05

  • Next message: stevenwurster_at_lycos.com: "Re: OCP and Java" 
    Date: Tue, 08 Feb 2005 09:13:33 -0500

    stevenwurster@lycos.com wrote:
    > Ilja Preuß wrote:
    >
    >>Steve, I actually still agree with almost anything you write.
    >>
    >>Let me just ask you one final question, though:
    >>
    >>If I understand you correctly, you are saying that Java "doesn't
    >
    > support the
    >
    >>OCP" because the language in some cases (when inheriting a private
    >
    > method)
    >
    >>doesn't allow to redefine the behaviour at a scale that would be most
    >>reasonable to the developer.
    >>
    >>On the other hand, you seem to support the notion that, for example,
    >
    > Eiffel
    >
    >>"does support the OCP", even though there are still (other) cases in
    >
    > which a
    >
    >>developer cannot redefine the behaviour at a scale most reasonable to
    >
    > him.
    >
    >>Is that your position?
    >>
    >>Curious, Ilja
    >
    >
    > Effectively, yes. The cases in Eiffel where a feature cannot be
    > redefined are either because the feature is frozen, or when it was
    > originally an attribute and the descendant wants to make it into a
    > routine.
    >
    > The first one is present in Java in the form of final (although you
    > said there are workarounds for that), and I don't have a problem with
    > the notion of a developer stating that nobody can ever redefine a
    > routine. It should be extremely rare, but still possible.

    Until Dionne Warwick and her psychic friends network start programming, I have
    a hard time imagining any programmer with the clairvoyance required to make
    anything /final/. It is mistaken to believe anything we write is so perfect
    that it can't be improved upon or that future situations won't require it to
    do something different -- however subtle. Better to comment the code and
    recommend that anyone tinkering with it be extremely cautious.

    >
    > I believe the second issue (redefining an attribute into a routine) is
    > being looked into by the Eiffel committee so that it would be possible
    > in the future.

    Variables and functions don't have different namespaces in Eiffel? If this
    kind of flexibiliy is valuable there are already programming languages without
    those namespace issues.

    Programming languages have a taxonomy of their own, similar to species and
    class hierarchies. At the top are most general, then as languages add
    features they become more specialized. Some of these specializations get in
    the way of adaptability. Just like animals, too much specialization and a
    language is difficult to adapt to new habitats. It contributes to some
    animals' inability to be domesticated, survive in zoos, or adjust to climate
    changes.

    If languages can be so arranged, then some of their genetic material is
    present in the programs we create with them. When a programmer defines
    something as "final" they've engineered a beast, or at least a trait of the
    beast, that cannot be adapted to new situations. Presenting these features in
    a program neuters it (or parts of it) from reproducing usful offspring in the
    future. Calico cats are fun, but the feature biologically neuters the males.
      In some cases the specializations are necessary (embedded systems) and in
    others they are simply symptoms of engineering short-sightedness (accidental)
    or arrogance (deliberate).

    OO languages are interesting in that the included a genetic taxonomy of their
    own from which animals are created. Given the need to manipulate a collection
    of stuff programmers can choose either a specialized trait (a string) or a
    more generalized one (ordered collection). If they don't need ordering an
    even less specialized "bag" trait may be sufficient.

    I don't know if any of the classic OO literature comes out and says it, but
    using the least specialized traits with the most applicable protocol for what
    needs to be done seems like it might be a good guideline. If this is a good
    thing does it make sense to apply similar guidelines to the languages we
    choose to build our programs with?

  • Next message: stevenwurster_at_lycos.com: "Re: OCP and Java"

    Relevant Pages

    • Re: detab utility challenge.
      ... The preprocessor cannot redefine how the maths work, and it cannot redefine how the standard C library works. ... I've used macro assemblers, languages supporting OO, functional programming languages... ... So far today I have only used 6 different programming languages for different tasks because different languages were appropriate. ...
      (comp.lang.c)
    • Re: compiler for Chinese development language
      ... This relates to the development of vernacular ... Indian vernacular display, OS and programming languages. ... Bangla and other vernaculars. ...
      (comp.compilers)
    • Re: Head-in-the-Sand Liberals (LA Times Columnist)
      ... You claimed to have known several computer languages, ... If you lie about knowing computer languages, ... of the programming loop for a functional ... You also don't know Java. ...
      (rec.org.mensa)
    • Re: Is there a mainframe skills shortage?
      ... That's because the author of the article is comparing it to standard SQL. ... and material around Lamdas and functional programming. ... obvious which languages were the ones to learn. ... stick to writing system software and leave applications to the COBOL ...
      (comp.lang.cobol)
    • Re: GoTo in Java
      ... Scripting languages are programming languages; ... override the method.via an interface, or write a new method in the wrapper. ...
      (comp.lang.cobol)