No error on semi implemented interfaces
Monkey Forums/Monkey Programming/No error on semi implemented interfaces
| ||
According to the documentation you should not be able to implement a partial completed interface?Interface example_i Method abc:void() Method def:void() End Interface Class try_c Implements example_i Method abc:void() Print "!working!" End Method End Class Function Main:Int() Local a:= new try_c a.abc() Return 0 End Function I expected the above to throw an error/not compile because the interface has not been fully implemented?. It is missing the def() method. Is this an error with me or a bug? A comment by Mark *hints* that all methods should be implemented |
| ||
| Strict mode on? EDIT: Ok, that didn't do anything. |
| ||
| It's monkey super awesome/confusing dead code eliminator - stuff that isn't used, isn't compiled. If you add a call to def() to main, it'll probably 'unwork' as expected. will probably get around to adding a 'compile all' mode at some point in the future... |
| ||
| This particular compiler feature, as a beginner, caused me no end of confusion till someone explained to me. A 'compile all' mode would be better for "type a bit in then quick compile to check syntax" coders too! :P |
| ||
| Thought occurred to me when I looked at the link to Mark's comment in the top post. It says: "On the downside, not being able to provide implementation code in interfaces limits where you can use them - you can't even provide simple helper methods that don't use fields or anything." What would be wrong with actually allowing that? I.e. an interface could come with default methods that don't access fields, or perhaps access only fields that belong to the interface itself, and cannot be aliased in classes that inherit the interface. Seems you could avoid the major issues with multiple inheritance in C++, without going all the way to interfaces as currently understood. A class that inherits from any class that implements its own version of any interface method would have to implement that method explicitly. Probably this has been thought of and answered before... maybe interfaces that inherit interfaces are problematic cases? |
| ||
| @Gerry Quinn allowing implementation code in an interface would make the concept weaker, for one thing, and would probably have a series of scope resolution problems with conflicting method signatures when multiple interfaces are implemented that would need to be spelled out. It's my understanding that the reason Interfaces and Abstract classes exist separately from one another with hard rules for each in most high level languages is to prevent the kinds of issues C++'s form of multiple inheritance has figuring out what is what. See: http://en.wikipedia.org/wiki/Diamond_problem#The_diamond_problem for a simple version of the problem and http://msdn.microsoft.com/en-us/library/ms973861.aspx#interinher_topic2 for a more interesting discussion on why .NET chose similar constructs to Java for Abstracts+Interfaces. |
| ||
| I know about the diamond problem. What I'm wondering is whether the solution is too severe. How often do scope-resolution problems really come up? And can we solve the diamond problem in cases where there are diamonds, without ruling out the majority of cases where there aren't any? What I'm thinking is, essentially, why not have something almost like C++ multiple inheritance except for: (i) when there is the possibility of ambiguity/diamonds you get a compile-time error unless you explicitly define a method (ii) interface-specific field names are tagged with the interface name so they can never clash with other fields. You can look at it from either side - adding options to interfaces, or eliminating cases where multiple inheritance causes a clash. What I'm suggesting is that instead of making a rule that definitely eliminates problems but loses a lot of good stuff, we make a weaker rule that eliminates most problems, and the compiler will kick when a problem does actually show up. |
| ||
| I figure most people have just agreed that MI is generally not a good idea and Interfaces are the typical, if not canonical way to approach the solution. If your coding pattern is such that you'd want to have Abstract-like classes with Interface-like implementation, that's your thing. I don't think it would be technically that much more difficult to make scope resolution doable with what you're suggesting (see the article on C3 linearization), but it would put the concept of Interfaces in a camp with less strongly-typed languages such as Python and Perl -- and while I can't speak for anyone but myself, I don't like that idea and I don't think it suits Monkey's style. Maybe something like what you're suggesting could be supported later down the line, like Mixins instead? I just think if Interfaces are allowed to be treated more like Abstracts, there will be even more confusion and even more bad design patterns resulting from its 'less rigid' implementation. |
| ||
| Maybe you're right. I certainly don't have any issues with having strict options like Interface as currently constituted, and I am pro strict typing. I wouldn't care if less-strict options (if such can be invented, and of course they would be strict according to their own rules) are called by a different name. I was just thinking aloud, really. Mind you it could be argued that Monkey's dead-code eliminator is a sort of solution to the Interface NOP problem! |
| ||
| Right that answers that problem then!. Noted for future. I would be in favour of a strict mode forced implementation of all interface methods. |
| ||
| In my modest opinion, multiple inheritance is my definition of hell. Interfaces (as they're now) are a very handy, clean and safe way to sort out most situations where you may think multiple inheritance could "do it". |
   |