Lambda the Ultimate

yes, perhaps we need type classes in more languages. It's never been clear to me why this feature hasn't caught on more.

It will soon be in more languages, namely C++. Of course, they call it concepts (= classes) and concept maps (= instances), and it seems rather unlikely that error messages will be anything like better.

Type traits are half like virtual functions (in that they are statically-checked, but dynamically dispatched) and half like concepts (in that they can be retroactively mapped to types). Furthermore, they offer a type of specialization that, if done dynamically, would require multi-methods.

The other comments suggest lots of good related work. Without looking more closely at your proposal, I'm not sure which is most applicable, although I would suggest taking a look at Scala's structural typing and implicit conversions. Regarding type classes, you say that they're "more similar to generics in Java or C#". This is not true, and I suspect that you may misunderstand type classes somewhat. Regular, plain-old polymorphism in Haskell is very similar to generics, while type classes are really an entirely different thing.

You are right, that's my mistake.
After receiving very similar solutions for current concern, it's good if someone could points out the advantage and disadvantage of them.

I respectfully disagree.

Basic structural typing is consistent across all types. Making interfaces behave different from views, which are different than classes is (at least to me) harder to understand. And I don't see how you're getting more features out of it.

The common usage for this feature is not necessarily as variable storage, but as the required parameter of a method. Doing a cast into every method, and then a null check in ever method and every parameter is annoying.

Programmers don't use annoying features.

Also, it should be noted that hard-casts into an interface exists for C# in library form.

When designing an architecture with specific domain concern, using this technique could make the an OO design harder to understand and maintain.

Maybe. Not enough code has been written in the technique to say. Honestly though, I believe that the option to use type-checked implicit conversions to an interface is a good thing. Enough safety and descriptiveness to help the programmer while being flexible enough to not impede them.

First things first, hitting 'reply' to a post will make your post a reply to it so that things thread properly.

Honestly, as I said, I don't have an enough clear definition of interface so ,to myself, comparing it with view may be not obvious (Please give me it).

Sure, let's see if I can't do that. We'll assume C# for the sake of discussion.

A C# interface is a set of signatures. A class may inherit from any number of interfaces, but since there's no implementation to an interface, there's nothing really to inherit. What does happen at compile time is a check to make sure that the class satisfies the interface's requirements. If it doesn't, error. The class is then hard-coded as a sub-type of the interface in the type-graph.

Your view from what I can see does the same check for satisfied requirements during the 'as' cast at runtime without requiring the type-graph. Sure, it could be checked to a degree at compile time, but why the explicit cast then?

"and then a null check in ever method and every parameter is annoying." - Honestly, I didn't understand this clause fully (You said that every method has to be checked missing or not and so on parameters?)

In my experience, the best place for the view isn't as a variable type (like in your example). It is as a parameter type. If your method is expecting a view (because that's all it needs) and you want to pass in a concrete type then you'll need to do a cast (as far as I can tell from examples).

So instead of:

DoStuff( CalculatorInstance );

you end up doing

VCalculator viewCalc = CalculatorInstance as VCalculator;
if( viewCalc != null ){
    DoStuff( viewCalc );
}

or delegating that null check into the method to deal with as it wants (and pretty much has to since everything is cast into a view, and thus is more likely to be null). It's a lot of extra code that doesn't really do anything except provide an opportunity for the programmer to foul something up.

It's annoying. Unless of course I'm misinterpreting your examples?

That definition is not complete (such as when a class implement an interface, it must implement all methods described in the interface, please give me a cite note).
About your example, I don't know why you wrote it like that. If you want a simple version, we just call

DoStuff( CalculatorInstance );

And in DoStuff

void DoStuff(VCalculator vCalculator)
{
   if (vCalculator) //for safety
   {
     //do something;
     return;
   }
}

It's more generally that we check parameter in the method than outside (may lead to double check). Even if we use dynamic, duck-typing or structural subtyping, checking or try-catch are needed for safety. If the conversion is implemented, it can be used like that.

There are some situations that could be to do that.If you want, you may want to read many examples about duck-typing. For instance, with C#, the classes we want to used could be either the public part of the assemply (.NET type or others) or even internal part (that's when we want to use reflection, to fix some bug we may need to do that).
Look like the dicussion won't going well so it should be end here. Thanks you for all replies.