April 2, 2018 at 10:30 pm #14210
I’m stuck tracking down a linkage crash and would like to ask a few quick questions :
- Is a linkage crash (mx2cc fatal error) always considered a bug (ie. the thing causing the crash should be caught during semanting)? If so, I will try to create a crash test example and put it on github to help get it fixed.
- The crash seems to be caused by me calling a Class Function on an Instance of a Derived Class (it is a Virtual Function). Should I be able to do this or am I abusing the Monkey (ooh-er!)?
- Am I being dumb or are Class Functions not mentioned in the online documentation? If they are missing, can I help put them there? Who maintains the docs and where should I officially report documentation errors and the like?
TIAApril 2, 2018 at 10:52 pm #14211
I would at least comment on 1)…
Report with runnable example and see what Mark makes of it, in that mx2cc fatal errors basically shouldn’t happen.April 2, 2018 at 11:19 pm #14212
Finally pinpointed the problem and boiled it down to this runnable example. Uncomment the final line to cause a linkage error.Monkey1234567891011121314151617181920212223242526272829303132333435363738Class ThingMethod DoStuff() VirtualPrint "Doing Stuff"End MethodFunction DoStaticStuff() VirtualPrint "Doing Static Stuff"End FunctionFunction DoAbstractStuff() AbstractEnd ClassClass SubThing Extends ThingMethod DoStuff() OverridePrint "Doing Stuff in subclass"End MethodFunction DoStaticStuff() OverridePrint "Doing Static Stuff in subclass"End FunctionFunction DoAbstractStuff() OverridePrint "Doing Abstract Stuff in subclass"End FunctionEnd ClassFunction Main()Thing.DoStaticStuff() ' Prints Doing Static StuffLocal foo := New SubThing()foo.DoStuff() ' Prints Doing StuffThing.DoStaticStuff() ' Prints Doing Static StuffSubThing.DoStaticStuff() ' Prints Doing Static Stuff in subclassfoo.DoStaticStuff() ' Prints Doing Static Stuff in subclassSubThing.DoAbstractStuff()foo.DoAbstractStuff()Local bar:Thing = New SubThing()bar.DoStuff() ' Polymorphism doing its thing ; Prints Doing Stuff in subclass'bar.DoAbstractStuff() ' Causes linker error... Should polymorphism work for static methods?End Function
Should polymorphism work on ‘static method’s / ‘class function’s?April 3, 2018 at 4:13 am #14217
You can’t override static methods in java or c#, so I think Mark have to deny it too.April 3, 2018 at 5:35 am #14218
This looks like a compiler bug to me – you shouldn’t be able to use ‘virtual’, ‘abstract’, ‘override’ or ‘final’ with functions (static methods).
It doesn’t make any sense to allow it either – without a ‘Self’, an object has no dynamic type.April 3, 2018 at 5:58 am #14219
The code example works in version 1.1.08
Attachments:April 3, 2018 at 6:52 am #14221
there is a github orgnization
the fact that class funcs are not documented is in the issues.
You can help improving docs via that fork or with your own github..
If you want admin rights in mx2DocsCommunity just ask..
I’ve had been working a bit on the language ref. but have just a few spare time now so focused on my game project.April 4, 2018 at 7:47 am #14232
@abakobo Thanks for the heads-up. I had no idea that docs repo existed.
I’d be very happy to help sort some of those issues listed on github. I dont use github much (I prefer the git cli) but can’t seem to find a way to request admin rights… am I being dumb or is there no way to do so on github? Can you add me as an admin – IMO it is a much tidier way to work than adding more and more forks! I’m arpie42 on github.
I know what you mean about spare time! But many hands make light work, apparently 🙂April 4, 2018 at 8:36 am #14233
@arpie, invited you as owner. If you are used to git cli, it would be great if you could sqash all the “dev up” commits into one commit, so it doesn’t pollute brl’s repo when making a pull request. Can you do that? I’ve been looking a for it a bit but I never used the cli..April 4, 2018 at 9:23 am #14235
@abakobo I am no expert but afaik it is generally considered a bad idea to squash commits once they have been pushed to a shared repo – it means ‘rewriting history’ and causes a headache for anybody with local copies of the repo.
A better approach would be to have two branches – one where all the commits happen, as they do now (wipdocs), and a master branch to which those commits are merged in batches, before being then pulled back into brl’s repo. There are other approaches but at a first glance, this one makes the most sense to me for this project.
Maybe you are already doing something like this? I will take a closer look later and get back to you.April 4, 2018 at 12:31 pm #14237
Well I’ve done it all wrong till now and Mark has merged some pull requests full of «dev up». So for the last pull request I actualy made a clean fork on my account and the closed the issues on the mx2docsCommunity fork.
I must say I’m a bit surprised it is so complicated to keep a branch sync and clean.
Anyway, do as you think it’s better. My way to do it is completely wrong probably. Nerobot had suggested somewhere how to do it cleanly (in a pull request discussion I think).
If it is possible to create a new branch that is a clean copy of brl’s dev that would be neat. But how to sync mx2docsCommunity master(or dev) with brl’s dev in a clean way?
As you can see I’m more using github like a dropbox than like a git ;).April 4, 2018 at 12:42 pm #14238
My suggestion is good for a short improvements. But if you have long changes then there can be many merges of m2 repo in yours.
But anyway – the only main repo here is brl/monkey2, and to keep its commits clear Mark have to always use Squash&Merge option (to get single commit of all pulled changes). And I think he does it already. 🙂April 4, 2018 at 10:28 pm #14244
@abakobo don’t be so hard on yourself! git is extremely complex, has many possible ways of doing the same thing. Multi-user version management is inherently incredibly complicated. If your method is working then you are not doing it wrong! As far as I know, the method you are using is actually quite common. It seems messy because Mark is a coding god and produces a huge number of commits.
When you mention brl/monkey2, do you really mean blitz-research/monkey2? I presume Mark changed the name at some point in the past?
Nerobot has hit the nail on the head : the only main repo is blitz-research/monkey2. Commits should only be squashed in one direction -> towards the main repo. If we squash the merge from upstream to docs, it will be very difficult for Mark to then merge back to pull in the doc commits.
On the other hand, I don’t think Mark should be squashing your pull requests. He should be rebasing them! That way he wouldn’t have the merges from brl->docs showing up in the brl repo. Or perhaps I’ve misunderstood something?
@Mark, have you tried doing a ‘rebase and merge’ instead of just a merge on the docs pull requests? Will you even notice this question?
I think we could rebase locally in the docs repo before issuing a pull request to Mark but that may get difficult to maintain due to having to rewrite history in the docs repo. I will have a play tomorrow.April 5, 2018 at 8:32 am #14253
Can I get back to my original question about static methods?
@qube thanks for that but I think if you uncomment the final line of code it will crash.
@Mark I’m using the ‘latest’ gcc on linux so I would be surprised if this is a compiler bug? but you never know!
@Mark @nerobot surely it is not quite as simple as banning override/abstract/etc. It is useful to be able to declare an abstract Class Function in order to enforce any derived classes to define the function (a style of contractual programming, I guess?). Certainly they make sense within an interface, don’t they?
The only OO concept that breaks with static methods is polymorphism. The only thing that needs to be made illegal (caught by the semanter?) is calling an abstract function. This is what caused my crash… and in any case a crash is Not A Good Thing.
I intend to add class functions to the docs so want to fully understand what they can/can’t be used for…April 5, 2018 at 8:42 am #14254
It is useful to be able to declare an abstract Class Function in order to enforce any derived classes to define the function (a style of contractual programming, I guess?). Certainly they make sense within an interface, don’t they?
‘Static’ mean that this logic is common for whole class/type, not for every instance.
To declare common logic for instances which can be overriden you should use virtual methods (not a functions).
To prevent overriding in derived classed you can mark methods as Final.
To force user to override method – mark it as Abstract; methods of interfaces are abstract by defaul.
You must be logged in to reply to this topic.