To interface or not to interface
jason.james.house at gmail.com
Wed May 26 06:04:10 PDT 2010
Walter Bright Wrote:
> Jason House wrote:
> > Walter Bright Wrote:
> >> Jason House wrote:
> >>> 7. Compiler-assisted verification.
> >> For interfaces, the compile time checking is limited to verifying that
> >> functions with the right signature are supplied. Templates can go
> >> considerably beyond that with the constraint checking.
> > constraints are more powerful, but they have downsides: If a class is
> > incorrectly defined, failure to use a type without a constraint check leads
> > to errors in the code using it instead of the class definition. Usage isn't
> > always guaranteed to be correct either, so the developer must spend extra
> > time diagnosing the real error. If a class is incorrectly, initial usage
> > without a constraint may completely miss the error. Easy examples would be a
> > typo propogated with copy/paste, or neglecting to use save. If a class is
> > incorrectly defined and usage uses a constraint, the developer will simply
> > get an error that there is no matching call. If a constraint is incorrectly
> > defined and usage uses the constraint, the developer will simply get an error
> > that there is no matching call.
> > None of these scenarios are particularly helpful for a developer
> > creating/expanding a family of objects.
> You can also make constraints that give custom error messages, so you can do
> better than the compiler's stab at it. How good they are is up to the designer
> of the type.
So you're favoring an isXXX as well as a requireXXX? Such duplication is both annoying and error prone. Making isXXX use requieXXX under the hood ishigher implementation complexity. I don't know about others, but I was drawn to its simplicity over C++. Many have praised its ability to make template programming simple. This feels like a step backwards.
More information about the Digitalmars-d