Lambda the Ultimate

Is this one of those "debatable" points? It appears that the author argues for deep and narrow class hierarchies, because they indicate reuse - through inheritance. However, I've always favored delegation over inheritance - implementation inheritance tends to a fragile system. In fact, the longer I develop software, the more I focus on stronger and more flexible typing and the less I lean towards reuse through inheritance.

On the other hand there are cases when changing just one or two methods in a subclass is sufficient and introducing a new component for that purpose would complicate the code.

With regards to typing, I'd really like "protocol typing", and not "class typing", so in the parameter list of a method I could say this parameter must implement method foo(). I'm sure this exists in some languages (Java interfaces don't do the trick for me - I don't want to specifiy the constraint in the class of the objects, but in the method where I use these objects.)

Yeah, I've been thinking some about this lately - especially in terms of generics. Named conformance can be arbitrarily restricting and the cause of a proliferation of meaningless types and adapters, while structural conformance can be the cause of accidental conformance. I had pondered a type system where types are named and methods declare which types they accept (as usual), but you can optionally declare whether the types must conform in name in addition to structure.

For example,

constraint T {
  foo(); // A T must have method foo - any return type
}


// Nothing conforms to U, unless it explicitly names U.
named constraint U {
  foo();
}


class A { // Conforms to T (structurally).
  public Float foo();
}


class B : public T {  // Conforms to T (named).
  public String foo();
}


class C : public U {  // Conforms to T (structurally), and U (named)
  public Int foo();
}


class X {
  // Accepts A, B, and C
  public void bar( T t ) {
    t.foo();
  }
  // Only accepts B
  public void bar( named T t ) {
    t.foo();
  }
  // Only accepts C
  public void bar( U u ) {
    t.foo();
  }
}

You can get this sort of affect in C++ with templates - By default, template parameters conform structurally, but you can get named conformance by casting the template parameter to a subtype that you want the template parameter to conform to in name.

I don't think it's necessary to be able to declare constraints in method declarations (ala PolyJ where clauses), as long as you are able to declare constraints in an "inner" scope (ala Java nested interfaces). That's one serious shortcoming of C++ templates as they stand now.

void someMethod(param has-methods foo(), bar()) {
     ...
}

This should mean that param can be any type as long as it has the methods foo() and bar().

The problem I have with it, is it leads towards duplication and verbosity (typing the constraints foo(), bar(), etc... over and over for each use of that parameter in different methods), and the tendency towards a loss of abstraction - should there really be a new type to describe a parameter that has foo(), bar(), etc... methods - probably.

I think you've re-stated my point for me. "OnceAndOnlyOnce" is all about preventing duplication. Where clauses encourage duplication of constraint information.

> Well, I use that object OnceAndOnlyOnce... (I meant initialize instead of use)