[NETBEANS4428] Initial work on "is/get/set prefixes" bug

[SirIntellegence]

It has been implemented. Just need to work on the tests

To resolve issue #4428

[mbien]

before I forget: the commits need to have a real name and valid address in the header.

[SirIntellegence]

By header, you mean the commits or the pull request? I will probably need to disable a certain Github option...

[mbien]

By header, you mean the commits or the pull request? I will probably need to disable a certain Github option...

the commits. git log of your branch i checked out shows your nickname and a noreply mail address. Those would be the same commits which land in master. This project requires real names and valid addresses for contributions. You can change this per commit, per repository or globally in your git settings.

git commit --amend --author="Author Name <[email protected]>" --no-edit would update the author info of the last commit of the current branch.

[SirIntellegence]

That should have done it? Don't know if I need to fiddle with other github settings or not

[SirIntellegence]

I just noticed that time stamps on the commits were lost... I am trying to decide if they are important enough to fix...

[mbien]

I just noticed that time stamps on the commits were lost... I am trying to decide if they are important enough to fix...

time stamps going to usually change every time the commit hash changes which is every time the commit itself is modified. PRs like this are usually squashed as last step after review to a single commit before merge anyway so don't worry about those.

the author details look good to me now, thanks.

[SirIntellegence]

In regards to optimization, we could us a wrapper CharSequence to avoid creating 3 Strings when we check a method. That would require modifications to other methods as well. Another possible solution is to filter through the members in parallel.

[mbien]

In regards to optimization, we could us a wrapper CharSequence to avoid creating 3 Strings when we check a method. That would require modifications to other methods as well. Another possible solution is to filter through the members in parallel.

string concatenation is rarely a problem. The JVM became very good at optimizing this. Most String ops are intensified. I wouldn't optimize anything by hand before knowing that this is actually a problem. But I would change it to the version i proposed at https://github.com/apache/netbeans/pull/4440#discussion_r931630020, since it creates the strings lazily/on-demand and is more compact/easier to read as bonus.

Its just that the non-matching case has 4 times more checks than before this PR. Would be good to test and show that this is in fact a non-issue. e.g generate a class with a few thousand methods/fields and compare before and after this PR.

Even if this turns out to be a problem there would be more paths we could take: e.g making this feature configurable/optional.

[SirIntellegence]

Is the "Do not merge" tag still applicable?

[mbien]

Is the "Do not merge" tag still applicable?

I think so.

• I would still like to check that this does not introduce a performance regression since it does 4x more checks per candidate. This might be a non-issue.
• this would also need more reviewers/opinions to see if this is something what should be enabled by default or via settings. This also somewhat depends on the results of the first bullet point.

[SirIntellegence]

So, I tested this file with and without the 3 additional checks and didn't notice any difference (yes, I added methods). My attempt to profile the methods in question didn't seem to work? They never showed up in the results. Even if I used instrumentation. So someone else will probably need to test that. I did notice that going the star import route was slow for both variations. FieldsOfJoy10k.java.txt

[mbien]

So, I tested this file with and without the 3 additional checks and didn't notice any difference (yes, I added methods). My attempt to profile the methods in question didn't seem to work? They never showed up in the results. Even if I used instrumentation. So someone else will probably need to test that. I did notice that going the star import route was slow for both variations. FieldsOfJoy10k.java.txt

interesting, filed an issue for this #4500

[mbien]

@neilcsmith-net @matthiasblaesing would we need a setting in the options for this or is it ok to have this always enabled?

[neilcsmith-net]

I suspect this might be the wrong approach, although I haven't looked in depth as yet. How does it interact with camelcase completion? eg. typing bean.sF| for bean.setFoo. My initial thought would be to hook into, and extend, that process.

[matthiasblaesing]

Maybe I'm missing something obvious, but from my perspective the issue description is solved by enabling "Subword completion":

with that I get this:

for this code:

public class Test {
    public static void main(String[] args) {
        Test t = new Test();
    }

    private int demoNumber;

    public int getDemoNumber() {
        return demoNumber;
    }

    public void setDemoNumber(int demoNumber) {
        this.demoNumber = demoNumber;
    }
}

I don't see reason to make CC more complex.

[neilcsmith-net]

Agree with @matthiasblaesing that this seems better supported already via subword completion. I use camelcase completion sometimes, but had completely missed we had that option too!

@SirIntellegence if this meets your needs OK, please close this PR, or highlight what's missing. Thanks!

[mbien]

i have to apologize to @SirIntellegence since I didn't actually know that the feature was already there, otherwise I would have mentioned it right away before reviewing.

[SirIntellegence]

Ooo. How long was that there? Thanks for letting me know about that. That covers the request. Thanks!