Re: syntax suggestion for concepts

On Mar 5, 7:55 pm, "W Karas" <wka...@yahoo.com> wrote:


There is a short write-up of the differences (at a feature level)
here:

 http://www.generic-programming.org/faq/?category=paradigms#object-ori...


Well, one obvious answer is any example of the Binary Method Problem.
Say you have some Shape interface and you want to be able to compare
Shapes with an isEqual method... I'll write it in Java, because I'm
less likely to mangle the syntax:

  interface Shape {
    boolean isEqual(Shape other);
  }

Now, a Triangle is a Shape:

  class Triangle implements Shape {
      private int base;
      private int height;

      public boolean isEqual(Triangle other)
      {
          return base == other.base && height == other.height;
      }
  }

In Java, this doesn't work and the compiler will complain because
Triangle's isEqual takes a Triangle whereas Shape's isEqual accepts a
shape. To get around Java's static type system, we use explicit casts
and write Triangle's isEqual like this:

    public boolean isEqual(Shape other_shape)
    {
        Triangle other = (Triangle)other_shape;
        return base == other.base && height == other.height;
    }

Similarly, we can define a Circle that also implements Shape and has
its own isEqual method. We can then trigger a run-time error by trying
to compare a Circle to a Triangle:

  Shape a = new Triangle(...);
  Shape b = new Circle(...);
  a.isEqual(b); // exception: run-time cast failed

Here's one of the earlier discussions of the binary method problem in
Smalltalk, which focuses on the double-dispatching issue: if you have
different kinds of graphical objects, and different kinds of display
ports, how can you write methods that display each kind of graphical
objects differently on each display port?

 http://portal.acm.org/citation.cfm?id=28732

In the concepts world, Shape would be a concept with an isEqual
function, e.g.,

  concept Shape<typename T> {
    bool isEqual(T, T);
  }

Note that we're using parametric polymorphism to describe concepts,
not subtype polymorphism: that's problem the single, most important
theoretical difference between OO and GP.

To say that Triangle is a Shape, we write an externally-defined
concept map:

  concept map Shape<Triangle> {
    bool isEqual(Triangle a, Triangle b) {
      return a.base == b.base && a.height == b.height;
    }
  }

We would do the same for Circle.

The static type system prevents us from ever getting into trouble with
isEqual: Triangle meets the requirements of Shape, and Circle meets
the requirements of Shape, but that does not imply anything about the
relationship between Triangle and Circle. For example:

  template<typename T>
  where Shape<T>
  bool equal_shapes(T a, T b) {
    return isEqual(a, b);
  }

  Triangle a;
  Circle b;
  equal_shapes(a, b); // compile-time error: T=Triangle in first arg,
T=Circle in second arg.

Parametric polymorphism, as in templates, retains the identity of
types. Subtype polymorphism, as in object-oriented languages, loses
type identity. To write the equivalent of the Java Shape's isEqual
method with parametric polymorphism in a constrained template, we'd
effectively be saying:

  template<typename T, typename U>
  where Shape<T> && Shape<U>
  bool equal_shapes2(T a, U b) {
    return isEqual(a, b);
  }

The real types T and U vary independently, but both are Shapes. When
this is done in a OO world, the type-checking is pushed to run time,
inside the body of isEqual (whose interface says that *any* two shapes
can be compared). In a GP world (and with C++ concepts), the isEqual
call inside equal_shapes2 would fail at compile time: the Shape
concept says that a T can be compared with itself, rather than saying
that it can be compared against any Shape.

If you want to say that any Shape can be compared against any other
Shape (say, in a hasSameArea function), you would use more parametric
polymorphism:

  concept ShapeWithArea<typename T> : Shape<T> {
    double area(T);

    template<typename U> where Shape<U> bool hasSameArea(T, U);
  }

  Cheers,
  Doug

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ:http://www.comeaucomputing.com/csc/faq.html ]- Hide quoted text -

- Show quoted text -

- It again mixes object-oriented and generic programming ideas in a
way that will lead to confusion. I guarantee that, after showing an
example like the above to an audience, I will get two questions: (1)
why can't I just use ':' to inherit from C? and (2) can I declare a
variable of type C*? Neither question would arise without the
assumption that concepts are just another take on object-oriented
programming (they aren't), and we need to be very careful not to give
the impression that they are.