Abstract class method recognition

[Justin Julicher]

I’m implementing an inner class that extends a class from a name-spaced package and I am getting the following error even though it allows me to save:

I think the structure is like this:

‌

Interface A, Interface B → Abstract Class C (implements A,B) → Abstract Class extends C → Inner Class extends C.

A, B & C are all in namespaced package.

Have re-created the OST multiple times and restarted and cleared caches.

The method in question is on Interface B.

‌

‌

‌

[Scott Wells]

Justin, is it possible for me to install this package? If not, could you send me an OST generated with the package installed so I could use it in a project to reproduce the behavior?

[Scott Wells]

Justin, I've created a project based on the provided packages and source files. I had to do a few things, giving the project a namespace that matches that of the installed packages and stubbing one referenced exception type that wasn't provided. Once I did so, the only issues I saw were in the Functions class, and that was because of what seems to be a typo in Functions.SetField.call:

        global Object call(Object record) {
            return call((SObject) record);1
        }

Notice the trailing 1 after the return statement. Once I remove that, everything else looks good in the file.

Is it possible that the files that you provided don't evidence the original issue and this was just a red herring?

[Scott Wells]

Oops. I spoke too soon. Quite a few errors still in the Filters class. Let me keep investigating...

[Scott Wells]

Okay, the issues I found in the Filters class were due to IC2 trying to resolve Functions.InnerTypeName as InnerTypeName in the Functions system namespace. With that addressed, I don't see any other issues in the provided source, but I don't think I've yet encountered the original issue that you reported. I'll include the fix for the local-type-with-same-name-as-namespace resolution issue in this week's build and we'll see how much that helps, but my guess is that we'll need to keep this open for the other issues you're seeing.

[Justin Julicher]

Hi Scott,

Thanks for getting back to me.

The issue I had the most was that when I created another class that extended the sobject Filter class in apex I just had to override 1 of the methods but IC was complaining that I had to override both.

Thanks

Justin

[Scott Wells]

Justin, was that represented in the source files that you sent me? If not, can you please provide an update with an example that reproduces the issue?

I just finished what I hope to be the last RC build for tomorrow's update, so I don't plan to add any other fixes into this one, but if I can reproduce the behavior I'll be happy to fix it for next week's build.

[Justin Julicher]

Hi Scott

Yes -

this is an example - an internal class:

private class CommencementDateIsTodayOrInThePast extends

qic.Filters.SObjectFilter {

    public override Boolean apply(SObject toFilter) {
        Date targetCommencementDate = (Date)

toFilter.get(ContractDetail__c.TargetCommencementDate__c); Date actualCommencementDate = (Date) toFilter.get(ContractDetail__c.ActualCommencementDate__c); return actualCommencementDate != null ? actualCommencementDate <= Date.today() : targetCommencementDate <= Date.today(); } } }

[Scott Wells]

Okay, I've reproduced it now. I was confused by what you gave me and put the provided classes in the local project, but they're already in the installed packages. Being local prevented them from ending up in the OST, though, so I wasn't seeing what you were seeing. I should be able to debug and fix it now. Thanks.

[Scott Wells]

Ah, I finally see the issue. The generated OST only includes what it considers to be the accessible interface of the installed package, specifically things that are global or @NamespaceAccessible, so it doesn't know about the concrete inherited implementation qic.Filters.ObjectFilter#call. Hmmmm....I suppose that if the namespace of the installed package matches the namespace of the current project's connection, things that are protected and public should also be included in the OST. I'll look at making that change once I get this week's build out and provide you a pre-release test build to try. Assuming that goes well, I'll include such a change in next week's official build.

[Scott Wells]

Okay, I made a small change to include public and protected symbols in the OST from installed managed packages with the same namespace as the current project and that does resolve the error you were seeing, but it's still not 100% correct. Technically those symbols are not available to the local project unless they're also annotated with @NamespaceAccessible:

https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_namespace_visibility.htm

So in addition to the change I've already made, I also need to make sure that IC2 doesn't consider these accessible for purposes of code completion and semantic validation of references if they aren't properly annotated. Not a problem...knowing what the problem was and therefore what to do was the main hurdle here...but I don't want to rush this. I do think I'll have a proper fix for you in the next build, though, and I can provide a preview of it ahead of time if you'd like.

[Scott Wells]

The fix for the Functions inner class was delivered in 2.2.1.3. I'll address the main issue for next week's build.

[Scott Wells]

Okay, I just committed a fix for this. The details of the fix will be included in next week's release notes along with the fix itself.

[Justin Julicher]

Amazing! Thanks Scott!

[Scott Wells]

Delivered in 2.2.1.4. You'll have to regenerate your OST after updating. Let me know if you still that issue (or if you see any other new issues, of course) after doing so.