Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Circle/Ellipse dilemma

Expand Messages
  • Bill de hÓra
    ... Are you talking about the range and domain of a type? ... Ok, but sorting is not indicative of a type, it s indicative of an algorithm. That how a sort is
    Message 1 of 120 , Dec 2, 2003
    • 0 Attachment
      robertdw26 wrote:


      > Types typically include a behavioural contract, especially if you're
      > into design-by-contract. However, they don't specify the
      > implementation technique.

      Are you talking about the range and domain of a type?


      > Sorting's a classic. The implementation of a sort is irrelevant to the
      > client, although consequences of it may not be (e.g. using a bubble
      > sort to order 1000000 records probably isn't a good idea).

      Ok, but sorting is not indicative of a type, it's indicative of an
      algorithm. That how a sort is implemented is irrelevant, is in turn
      irrelevant. You'll tie yourself up in knots defining a sort
      algorithm in terms of types :)


      > If all your type has is method names, then I agree that's too weak.
      > But as long as the (possibly implied) behavioural contract is adhered
      > to, caring about types should be sufficient.

      I still think this is not the case. Type theory is simply not
      sufficient in my experience to describe sofware programs, and I
      think there is a body of academic literature (especially in symbolic
      AI) and programming lore that would concur with my experience. Hence
      we tend to rely on empirical testing, not proof.

      Bill de hÓra
    • Keith Ray
      ... example of bad OO: class point { float x, y (and methods...) }; class circle extends point { float radius; (methods treat inherited x,y as center) };
      Message 120 of 120 , Dec 2, 2003
      • 0 Attachment
        On Tuesday, December 2, 2003, at 05:08 PM, Amir Kolsky wrote:

        >> Indeed, the data structure that represents an ellipse has too many
        > variables to efficiently represent a circle.
        >
        > Yup, and by virtue of the bad smell, we should know that there's
        > something immutably wrong with even trying to get to a circle by
        > subclassing ellipse...

        example of "bad" OO:

        class point { float x, y (and methods...) };

        class circle extends point { float radius; (methods treat inherited x,y
        as center) };

        class ellipse extends circle { point secondLocus; (methods treat
        inherited x,y as first locus) };

        class square extends point { float sidelength; (methods treat inherited
        x,y as top-left of square) };

        class rectangle extends square { float otherSideLength; (ad nauseum) };

        --
        C. Keith Ray
        <http://homepage.mac.com/keithray/blog/index.html>
        <http://homepage.mac.com/keithray/xpminifaq.html>
        <http://homepage.mac.com/keithray/resume2.html>
      Your message has been successfully submitted and would be delivered to recipients shortly.