Re: Coping methods

Just to finish the discussion:
At last I implemented method copy as I wanted. It turned to be extremly 
heavy, dificult and error-prone: local vars fixes, argument fixes. And 
is not exactly "copy": it is more like "implantation".
So, now I agree that it is better idea for MethodGen to have copy method 
as curently implemented in BCEL.

I hope that mail thread will be useful for the next BCEL user who 
wanders how to _plant_ (rather than copy) a method from one class to 
another.

Stephen Kolaroff wrote:
> well, there should be some kind of misunderstanding.
> I took a lok at the copy implementation. And mentioned that all 
> constants from original CP are copied to the destination CP. Which is 
> perfect.
> My question was, isn't it better to take care of references to fields 
> and method of the original class (this.field = 100 to be copied as 
> this.field=100 in the other class). Moreover, I pointed that the current 
> method copy produces incorrect (In JVMspec sense) result when 
> transfering such this.smth references. Such incorrectnest, though, is 
> perfectly correct as long as you, bcel developers, state that 
> MethodGen.copy must behave as behave now.
> 
> Meanwhile, I do implement my metod copy (actuall, whole class copy):
> class One {
> int filed;
> void putfield() {field=100;}
> }
> 
> class Another {
> }
> 
> copy One to Another:
> class Anoter {//after copy
> int field;
> void putfield() {field=100;}
> }
> 
> Markus Dahm wrote:
> 
>> You probably forgot to copy the ConstantPool as well. Alternatively 
>> you have
>> to copy the referenced entries and set the indexes by hand.
>>
>> Cheers
>>   Markus
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>