keyword interface not working correctly
Monkey Forums/Monkey Beginners/keyword interface not working correctly
| ||
| I cannot get interface to work properly. I left out the method myMethod() in class player that implements the interface and the complier does not complain. It should give some type of error saying I forgot to add the method. below is what I had typed in: I went to You tube and tried getting the error he got and did not. Am I doing something wrong or has monkey acquired a bug? Interface I_thisInterface Method myMethod() End Class Player Implements I_thisInterface '------interface method was not placed here-------- End Function Main:Int() Local p:Player = New Player() Return 0 End |
| ||
| ... |
| ||
| This is not a bug with Monkey's compiler. Monkey only compiles what you use/reflect. Here's a similar post. Basically, you have to use what the interface has, otherwise it won't consider it an error. To change this behavior, you'll have to reflect the module in question using the preprocessor (Add the module to the reflection filter, and import 'reflection'). To add the current module, rather than using exact names, write (Importing 'reflection' is likely required):
' For the record, 'MODPATH' is an actual preprocessor variable as well.
#REFLECTION_FILTER += "${MODPATH}"
To reflect everything, set the filter to "*"; I do not recommend this, the final binaries are huge when you do this; not to mention the compile-time on some platforms. And as k.o.g. said, there are forum codes; but for some reason they don't pop up when starting threads. You seem to be using interfaces properly, though. Also, please don't use the 'code' tag too often; 'codebox' is better contained. The 'code' tag works better for short snippets like the above example I posted. |
| ||
| ImmutableOctet(SKNG), thanks for you very helpful response, because this situation was driving me crazy and I figured I was doing it right but I was leaving out something import to the monkey environment. So, basically to use interfaces the way I would normally use them in C# I can type in the following: '------------------------------- #REFLECTION_FILTER += "*" Import reflection '---------------------------- you say it will make a huge binary file. Can't I just remove the filter after I know the application is working correctly , or use preprocessor directives to edit it out when used in the release version? (if possible what is the preprocessor directives to achieve this?) I say this because I am only using interfaces to guaranty that I am using or spelling the implemented methods correctly when implementing them in a class; when the game is finished I will know I used the required methods because I would not have received any previous error messages when I compiled the final game; at that point the reflection filter and import will no longer be necessary and can be safely removed. Is this correct or am I still missing something? |
| ||
| Well, the interface will work properly either way, but the error reporting will only work if the method of the interface in question is used from a reference using that interface. Explicit reflection filters are ideal for most cases, as you won't be reflecting the "Monkey Standard Library" (AKA, the standard 'monkey' module; always auto-imported by Monkey files). All that is reflected can be used with the 'reflection' module for runtime manipulation, and therefore, Monkey needs to generate code for the reflection functionality to work. Monkey doesn't do this at the standard language level, but instead the native level, meaning that you'll end up with a lot of native code that may (And in your case, very likely will) be useless to you. This, in turn, makes compilers like GCC/MinGW sit in place for minutes on end, taking up obscene amounts of memory. JavaScript generally isn't too bad about this, though. The effects I mentioned aren't usually that bad, but that's a "worst case" scenario. I remember having a file which imported all of my public modules, and it generated so much code for reflection, it was ridiculous. Monkey has a "build mode" of sorts available, which allows you to check your source for errors, but it works with the same mindset. If you simply want to test if your code is correct (Disregarding reflection rules), then you'll need to set the reflection filter as you specified, and use that mode. Otherwise, the target-native build process will begin, and you probably don't want that with reflection set up this way. This feature can be used through 'Ted' (Monkey's default IDE) by pressing F6, going to the "Build" menu on the top of the window, or by using the "-check" argument from the command-line. Like I said before, the reflection behavior works like a normal compile, so you'll still have to set it if you want that kind of error checking. Setting / adding "${MODPATH}" to the reflection-filter, which can be done for per-module reflection. Of course, there's also using "*" as a wild-card for submodules, as stated here, which could be useful to you. I think JungleIDE also has some stuff for "IntelliSense"-like functionality, if you like that sort of thing; requires the full version, though. The only other thing I can suggest is to use the preprocessor to optionally add everything to the filter when you want to, and then simply run a source-check. Basically, you'd just comment and uncomment a/several line(s) that set(s) the reflection filter and/or imports when needed. From there, you'd run the usual source-test. You could technically make this nicer by checking for a preprocessor variable you define, or checking if the 'CONFIG' preprocessor variable is set to "debug", or something. |
| ||
| ImmutableOctet(SKNG) : I think I figured out how monkey is using interfaces with the help of the explanation you gave in the first post. I don't require reflections. What I was doing was already the correct way of doing it. the way that C# compilers check interface is they will start looking at errors when you first make the class before an object is even used. if you make a class that uses an interface it will give errors if you forget to add or misspell a method (even if you do not create an object from it.) The way monkey seems to do this is if you make a bunch of classes using the same interfaces at least one of the classes has to have an object created from it and use a interface method correctly before monkey will complain about the other classes not having that method. which is fine. all I was concerned about was getting an error when I forget or misspell method in a class that I extended from a common interface. Is my reasoning correct? |
| ||
| That's about right. The only solutions are to either actually use the code in question, or to use reflection to force source-checking. I'd say don't worry about it most of the time. Monkey will only care about errors in your code (Or compiling/generating native code) when the code is actually relevant. Unfortunately, there are downsides to this design, but at least there are ways around its limitations. On the bright side, this means Monkey compiles things as it sees them. This basically makes generated code in many ways "pre-optimized" for the target's compiler (Theoretically; this is with regard to general code generation, not necessarily hardware-oriented optimizations). Not to mention that from a compilation perspective, everything is compiled by checking "references" to code from the contents of 'Main' (And everything provided recursively). Since 'Main' must be available in a Monkey program, this makes things quite fast. It's not like you'd want the unused code to be compiled anyway. I mean, really, though I'm partially against how Monkey's compiler loads source files, it's incredibly fast at compiling. And because of this, and the work pre-established with GCC/MinGW (Currently used for building the compiler), Monkey's compiler can recompile itself really quickly, and can therefore produce optimized code at several levels (And that's not even counting the small optimizations Mark has added). Though, it may be messy, you've got to hand it to Mark for building a solid compiler. And with platforms like the JavaScript/HTML5 target, the source is basically generated quickly by a highly optimized GCC/MinGW binary, then run exactly after, making the build process about as quick as it gets. There are still ways of making Monkey's compiler faster, but the fact is, it's damn good at what it does. Also keep in mind that I'm talking about the compiler. Generated code is rather fast by default, but the fact is, the overall performance of Monkey is up to the user and environment. So, don't go thinking Monkey is the fastest platform out there, just well built, and has the potential of running very quick. You'll still have to write fast code, even if the compilers can help optimize it (Just like any other platform). Interestingly, compilers like GCC (For C++ Targets; MSVC is also available) actually work really well with Monkey's native side, as the C++ array implementation can be optimized very well as far as SIMD instructions go. Anyway, sorry about the rant regarding Monkey's compiler; yes, your code is correct, but Monkey does have some optimization quirks. |
| ||
| Other targets such as Java run decently too, because Monkey has basically [*] a very similar structure to java. [*] Heh, pun not intended. But while the syntax is Basic-y, objects are basically the same as java objects. |
   |