Re: Re: Re: bootstrap methods in the constant pool

Rémi Forax wrote:
>> after looking carefully at these patches and the proposed changes
>> to the bytecode format in JSR 292, the design I prefer to support
>> this in ASM is the following:
>>
>> remove visitLdcInsn, replace it with 6 new methods:
>>
>> - visitCstNumberInsn(Number n)
>> - visitCstStringInsn(String s)
>>    
> 
> I wonder if these two can not be collapsed in one.

probably, since instanceof and casts are necessary to distinguish
between Number subclasses anyway; so adding String does not add
complexity for users
 
>> - visitCstClassInsn(String desc) // replaces Type arguments in 
>> visitLdcInsn
>> - visitCstMethodInsn(String methDesc) // JSR 292
>>    
> 
> I prefer visitCstMethodTypeInsn(String methodDesc) // JSR292 MethodType
> 
>> - visitCstMethodInsn(String owner, String name, String desc, int tag) 
>> // JSR 292
>>    
> 
> and visitCstMethodHandleInsn(int tag, String owner, String name, String 
> desc) // JSR292 MethodHandle
> Moving the tag as first argument is in my opinion more like other 
> methods visit in ASM.

ok to move the tag first; I did not add Type/Handle to avoid too long names
 
>> - visisCstInvokeInsn(String bootstrapOwner, String bootstrapName, 
>> String bootstrapDesc, int bootstrapTag, String methName, String 
>> methDesc) // JSR 292
>>    
> 
> ???

John added this in its patch (see lines 47-52, 130-131, 151-157 and 176-179 of his 'bsm' patch). But maybe this is not in JSR 292?
 
>> add a new method for InvokeDynamic:
>>
>> - visitMethodInsn(String bootstrapOwner, String bootstrapName, String 
>> bootstrapDesc, int bootstrapTag, String methName, String methDesc) // 
>> JSR 292
>>    
> 
> I think I prefer putting bootstrap info after calling info:
> visitInvokeDynamicMethodInsn(methName, methDesc, bootstrapTag, 
> bootstrapOwner, bootstrapName, bootstrapDesc)

why not

> About the stability of the API, there is a vicious circle for ASM:
> ASM is quite popular as backend tool for (dynamic) language runtime,
> so If we want the JSR292 bytecode changes to be tested we need a version 
> of ASM with these changes.
> But because runtime developers test the API using ASM, we have feedback 
> that require to change
> the JSR292 spec which leads to change the ASM API, etc.

"temporary" ideas can be tested with ASM changes made in a branch. Here
we are speaking of the final API for the final JSR 292 spec.

Eric

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws