Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Detect function body type (retake) #297
- Check that parent method visibility matches - Check when overriding that the parenet method doesn't have inline or static
…also added a HaxeDocument that will allow to modify the document easily without using static methods
It was a case-sensitive issue. Since I'm using windows and mac, which both have case insensitive file systems, I didn't triggered the issue. It was a bit strange since I created tests cases using the intelliJ which created files with the first upper cased letter. I have seen that getTestName allows you to specify whether you want the first letter to be upper case or not. So instead of changing names which usually causes problems when pulling in case insensitive file systems I'm going to try to refer to the files as they were cased already.
@soywiz Hi Carlos, I've looked at everything except the model code; Srikanth was reviewing those, though I have added a comment or two. Can you please either fix the outstanding issues or explain why they are correct so I can make this merge? My plan was to do it today, but it takes a while to read so much code. :)
We were see-sawing back and forth between whether we wanted to eliminate the redundant models and just merge them with the underlying PSI classes or not. I know that Srikanth has a list of those that can be merged. I think we're going to go ahead with keeping them as they are at this point. Whether we continue to expand and use them or not depends upon whether they create more of a maintenance headache than they solve. Right now we're not sure of that cost.
I have reviewed your comments and done some much more granular commits easier to follow to fix some of them. I expect those changes are enough for the merge. Obviously there will be some more things to fix. New false positive errors and so on. But with some time we will be able to fix them as we spot them.
Regarding to models... My point was to try to keep things a little more separated. It was not going to be completely DRY in the other case since I had to change a interface and at least one implementation for each method I wanted to add. Also there are some concepts that have no direct psi representation. And having a non-symmetric API would be pretty strange. I think it is not too much trouble to maintain that. But obviously that is my opinion. So I would accept and follow what you decide. If you like we can try to keep them for a while and if the feedback we obtain from the code is that it is more a burden than anything else, I would remove them by myself so it is not a burden for you.
Thanks again for all your reviewing and my apologises for all the craziness in there :)