Community
Participate
Working Groups
Currently , org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding has a fieldCount() API which calls the field() api, that in turns does resolution and other things that may sometimes not be needed in order to just obtain the no. of fields from the binding. It will be good to have a simple api in ReferenceBinding that can return the no. of fields: public int fieldCountSimple() { return this.fields.length; } Srikanth, what do you think?
This reminds me of unResolvedMethods() (in ReferenceBinding, SourceTypeBinding and BinaryTypeBinding) as well as unResolvedFields() (only in SourceTypeBinding) So we could either add unResolvedFields() to the remaining two classes or create the same structure for unResolvedFieldsCount().
(In reply to comment #0) > Srikanth, what do you think? What is motivating the change ?
(In reply to comment #2) > (In reply to comment #0) > > > Srikanth, what do you think? > > What is motivating the change ? This is required for bug 247564 where I need to calculate TypeDeclaration$maxFieldCount as a cumulative count of no. of fields from all supertypes, from the binding.
(In reply to comment #1) > This reminds me of unResolvedMethods() > (in ReferenceBinding, SourceTypeBinding and BinaryTypeBinding) > as well as unResolvedFields() > (only in SourceTypeBinding) > > So we could either add unResolvedFields() to the remaining two classes > or create the same structure for unResolvedFieldsCount(). I just checked and I actually didnt see how unResolvedMethods actually doesnt do resolution. Its internally calling methods(), and in both SourceTypeBinding and BinaryTypeBinding, methods() does the whole resolution. So unResolvedMethods() indirectly returns methods after resolution. This looks strange!
(In reply to comment #4) > (In reply to comment #1) > > This reminds me of unResolvedMethods() > > (in ReferenceBinding, SourceTypeBinding and BinaryTypeBinding) > > as well as unResolvedFields() > > (only in SourceTypeBinding) > > > > So we could either add unResolvedFields() to the remaining two classes > > or create the same structure for unResolvedFieldsCount(). > > I just checked and I actually didnt see how unResolvedMethods actually doesnt > do resolution. Its internally calling methods(), and in both SourceTypeBinding > and BinaryTypeBinding, methods() does the whole resolution. So > unResolvedMethods() indirectly returns methods after resolution. Not for BinaryTypeBinding. For SourceTypeBinding, yes, what you say is true and seems to have been that way for ever.
Created attachment 185040 [details] proposed fix I believe this should be sufficient here. As for the SourceTypeBinding, I guess we should raise another bug and fix that as well?
(In reply to comment #6) > Created an attachment (id=185040) [details] > proposed fix > > I believe this should be sufficient here. I think a suitable implementation is needed in BinaryTypeBinding and perhaps ParameterizedTypeBinding too. > As for the SourceTypeBinding, I guess we should raise another bug and fix that > as well? I would leave this alone unless it is causing some known problem as this has been the case since day one.
Created attachment 185209 [details] proposed fix extended Extended the fix to BinaryTypeBinding and ParameterizedTypeBinding.
Released in HEAD for 3.7M5.
Verified for 3.7 M5 by code inspection.
