BMX-NG and overriding methods
BlitzMax Forums/Brucey's Modules/BMX-NG and overriding methods
| ||
Have an issue with the following error:Compile Error: Overriding method does not match any overridden method. (Detail: Return type is "Int", expected "Void".) Which is happening when running the following code: SuperStrict Import brl.max2d Import rigz.max2dext Import rigz.glmax2dext SetGraphicsDriverEXT(GLMax2DDriverEXT()) InitEXTGraphics() Those modules just have a few abstract methods that don't return anything and get overidden. The modules compile fine, so is there something I need to do in NG for methods that don't return anything? I can't seem to isolate the problem in a blitzmax program by recreating the types, it only seems to happen in the compiled modules so not sure if I've found a bug in NG If you need to test my module can be checked out from here: https://github.com/peterigz/rigz.mod.git which you can test with the above code. Thanks! |
| ||
| Its most likely some methods defined without a Return Type that are overridden with type Int. bmx-ng changed functions and methods to actually have no return value (hence the Void) if no type is specified, vanilla blitzmax defaults to Int even in SuperStrict. |
| ||
| Thanks, I just noticed one of the modules is only strict, so after changing to superstrict and adding a few :int where necessary it seems OK now. Didn't have to change the return types though. |
| ||
| Yes, perhaps it should either : * raise an error if you are extending a SuperStrict type in a Strict module * upgrade overridden methods in your Strict subclass to match the original strictness of the super. (i.e. don't default no return type to Int) It's a bit complex. bmx-ng changed functions and methods to actually have no return value (hence the Void) if no type is specified Seemed like a good idea at the time :-p |
| ||
| If you want to adjust behaviour, there is an issue about this already: https://github.com/bmx-ng/bcc/issues/55 bye Ron |
| ||
| So, I'm going to change things. The default will be to "upgrade" strict method void return types to actually be void if the parent type is superstrict. If you declare the return type as Int in your strict method, it will raise an error - since the two types are not the same. There will be an option (compiler flag) to disable automatic upgrading - this will result in a compilation error if you have a strict method with void return overriding a superstrict method with void return. fun fun :-p |
| ||
| Do not forget to write some "SCT-tests" for this language-features. This avoids running into regression bugs. (Maybe we should have some kind of list for tests-still-to-write - so I {and others} could help you with this). bye Ron |
| ||
| The problem with SCT is that the freeprocess stuff doesn't appear to work reliably. I should be able to expect the consistent (and complete) pipe output over multiple runs on different platforms. This is not the case. On Windows for example, when the child process ends, it doesn't appear to be able to grab the last bit of the pipe data - for whatever reason. Meh. |
| ||
| Maybe we should discuss this in an individual SCT-issue, albeit this is a freeprocess-thing (I had this very same issue in my approach of an BlitzMax-Editor - because It was not able to fetch every output of BCC/BMK in all cases). All process-code is located in "base.processes.bmx". bye Ron |
| ||
| Updated SCT to wait for incoming process data (standardIO and errorIO) instead of relying on "fdHandleProcess()" alone. Maybe this helps already. As it works "here" I am not sure about that. bye Ron |
| ||
| @ Pete The latest bcc will "fix" your Strict (which I assume you've probably changed to SuperStrict now) rigz.glmax2dext, by making the return types of methods such as SetBlend() void despite being in a Strict file - which would normally change it to an Int. :o) |
| ||
| Great, thanks for looking at it Brucey, that sounds like it'll make more sense now. I think that module was a copy of a standard Blitz module that i modified so it was still only strict. |
   |