## A new idea in OOP. Please comment.

I have an idea: what if we can convert a class to an interface with only a requirement that the class just need implements all the member of the interface without point out the interface in its declaration (this is similar to duck-typing but it has different principle, though i didn't know about duck-typing before writing the article). And when using an object with unknown type, I think the dynamic type isn't a perfect solution (because many error-exception could occur at runtime). To read complete article, please go to this link: http://dakurai.blogspot.com/2009/06/new-wild-idea-in-oop.html . Please read and give me some reply. Thanks you.

## Comment viewing options

This idea is like Haskell type classes. Also, I like Haskell type classes.

So, firstly, how is it different? But secondly, yes, perhaps we need type classes in more languages. It's never been clear to me why this feature hasn't caught on more. Perhaps people don't like the compiler error message "T is not an instance of class C. Possible solution: add T as an instance of C" whenever they make a minor mistake like putting the function arguments in the wrong order. Still, that's got to be soluble, right?

### Concepts

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.

### Not quite...

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.

### No more error caused by invalid name or arguments

When we want to use an object through a view, we use a convert operator (such "as") to convert it. In the converting process, all the declarations including name,arguments (and order) and return type of members will be checked. If all that match, the conversion is successful and the result is not null. After that, we can call members from it without worrying about invalid name, arguments,... anymore because compiler will check it for us now. Thanks you for reply (I don't know much about Haskell so thanks you for information).
Anyway, I think the idea is suited for many modern languages such as C#, Java, ECMA Script,...

### Please give some principles that you think similar.

A principle I've received that very similar to my idea is duck-typing and I've written a comparison with it. Another is type class (Haskell) which I think almost different (it's more similar to Generics in Java or C#). If you've known something similar to my idea, please give me some replies. Thanks you.

### Type classes

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.

### Sorry, my mistake.

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.

### Some references

I wrote a little article for JOT a while ago, which proposes a type system design to solve the kinds of problems you describe. You can take a look here. There is also some recent work by Malayeri and Aldrich in this direction, see e.g., their ECOOP'08 paper. There are also proposals to add type classes to OO languages, most notably JavaGI by Thiemann et al.

### New?

This isn't too much different from any structurally typed language, not too different than some of Scala's features.

In fact, I can pretty much guarantee that this isn't a new idea since I implemented it last year. [edit: in further investigation, it appears that the OP and my implementation are slightly different in important ways.]

### OCaml

I think OO in OCaml works exactly as you suggest.

### Thanks for replies.

From the three above replies, all I get is quite a unique concern: "structural subtyping". The tangent type's described is exactly an implement of it. "A structural type system (or property-based type system) is a major class of type system, in which type compatibility and equivalence are determined by the type's structure, and not through explicit declarations". This is very similar to root of my idea.
As I wrote before, my idea is very similar to duck-typing or structural subtyping but the different approach make it easier to understand and could gain more features in OOP context (please read definition of view). With those techniques, you can convert between compatible classes, interfaces and what you get is a power at technical code level (maybe in your situation, a dragon can be used as a duck but generally, it's not). When designing an architecture with specific domain concern, using those technique could make the an OO design harder to understand and maintain.
Anyway, thanks for replies.

### I respectfully disagree.

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.

A view is different from interface so it can be added more features such as extract signatures of methods from class or default behavior. 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). About the definition of view, do you think that's not clear enough?
About the conversion, a fully check is required to complete use it safely after that. The conversion will check all signatures (in fact,only member without default behavior) and return a reference that's not null if successful. Checking fully the view may take more time but if a mechanism is design to optimize the process could make it worth (and after the conversion, calling to a member as fast as static type).
After receiving many disagreements, the discussion would be end soon. So welcome some last replies.
BS: "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?)

### Clarification

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).

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?

### More discussion

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.

### Because it creates a global namespace?

My principal concerns with this (and similar) proposals are namespace pollution and its effects on separate compilation.

In many (most?) object oriented languages, method names are scoped to the defining class. Under the proposal, if I am reading it correctly, all method names (actually, signatures) would become global, and if a class happened to implement a superset of the signatures of another class (possibly one defined in another module) it would become convertible to the type of the latter class. This offers a broad new potential for surprise, and complicates a number of otherwise-useful static analyses (especially in the presence of separate compilation).

The difference between Car.Drive() and GolfBall.Drive() may be intuitive to human readers of the code, but it is a big problem for tools.