You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mark Roberts <ma...@cs.washington.edu> on 2015/09/04 19:46:17 UTC
[BCEL] deprecation of getClassName in generic/FieldOrMethod
I read and understood the comment as to the reasoning, but the problem is the shared code nature of FieldOrMethod. When dealing with a method you know a priori that the object cannot be an array. Now to get the ClassName of an InvokeInstruction operand you must say invoke.getReferenceType(cp).getClassName(). This seems pretty awkward. One solution might be to provide an override version of getClassName in InvokeInstruction.
Thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [BCEL] deprecation of getClassName in generic/FieldOrMethod
Posted by sebb <se...@gmail.com>.
On 9 September 2015 at 11:11, sebb <se...@gmail.com> wrote:
> On 4 September 2015 at 18:46, Mark Roberts <ma...@cs.washington.edu> wrote:
>> I read and understood the comment as to the reasoning, but the problem is the shared code nature of FieldOrMethod.
>
> What comment was that?
I see now, you meant the comment against the method
generic.FieldOrMethod.getClassName(ConstantPoolGen cpg)
I thought you were referring to a proposal to deprecate a method.
I agree that the problem is the shared nature of the code.
Also of course the mutability of the CP index, which means that it can
be accidentally changed to point to the wrong type of entry in the
pool.
>> When dealing with a method you know a priori that the object cannot be an array. Now to get the ClassName of an InvokeInstruction operand you must say invoke.getReferenceType(cp).getClassName(). This seems pretty awkward. One solution might be to provide an override version of getClassName in InvokeInstruction.
>
> I think that's what I'm suggesting in BCEL-262. I just want to be sure
> I have got it right.
>
>> Thanks,
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [BCEL] deprecation of getClassName in generic/FieldOrMethod
Posted by sebb <se...@gmail.com>.
On 4 September 2015 at 18:46, Mark Roberts <ma...@cs.washington.edu> wrote:
> I read and understood the comment as to the reasoning, but the problem is the shared code nature of FieldOrMethod.
What comment was that?
> When dealing with a method you know a priori that the object cannot be an array. Now to get the ClassName of an InvokeInstruction operand you must say invoke.getReferenceType(cp).getClassName(). This seems pretty awkward. One solution might be to provide an override version of getClassName in InvokeInstruction.
I think that's what I'm suggesting in BCEL-262. I just want to be sure
I have got it right.
> Thanks,
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org