On 9 September 2015 at 11:11, sebb <seb...@gmail.com> wrote: > On 4 September 2015 at 18:46, Mark Roberts <mar...@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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
