Re: Method[Hande|Type] name clash between java.lang.invoke and org.objectweb.asm

Hi Eric,

thanks for explaining. I can now see how well considered this design is
even though it breaks the symmetry.

CU Tronje

Eric Bruneton wrote:
> 22/04/2011 11:11, Tronje Krop wrote:
>> Hi Remi, hi all,
>>
>> thanks for bringing it up again, because I noticed something before.
>>
>> May I ask, why you have introduced a MethodType|Handle in ASM in the first
>> place?
>>
>> IMHO the MethodType|Handle in ASM it is a breach of the well chosen design
>> rules, that should be urgently discussed before fixing the API of ASM 4.
>>
>> (1) MethodType
>>
>> The MethodType is only a wrapper for a method description string with some
>> convenience methods. It only transports the once verified information of
>> being a method type, that can be derived from the string itself.
>>
>> In ASM such information, in general, is provided as describing string, and
>> only its parameter position or its format may give you an additional hint
>> about its context.
>>
>> I do not suggest that it is good programming style, but it is the common
>> pattern of ASM that should not easily be dropped without questioning.
> 
> in visitLdcInsn we cannot deduce from a string alone if this string must 
> be interpreted as a CONSTANT_String or a CONSTANT_Class value. This is 
> why we used Type to represent .class constants, instead of String.
> 
> In the same way we cannot deduce from a string alone if its a 
> CONSTANT_String or a CONSTANT_MethodType value. This is why we 
> introduced the MethodType class.
> 
> The other solution that we considered was to introduce new visitLdcInsn 
> methods, such as visitLdcClassInsn, visitLdcMethodTypeInsn, etc. But 
> this solution does not solve the second problem (see below).
> 
>> (2) MethodHandle
>>
>> For MethodHandle it is a different story. I think this class may have a
>> right of its own, although it is very common in ASM to leave the bundling
>> of information to the visitor interfaces. E.g. a common bundle is the
>> tuple of (access, name, desc, signature) that is used either for fields
>> or methods. And there are many other places that may be simplified by
>> bundling information into objects.
> 
> the second problem with CONSTANT_MethodType and CONSTANT_MethodHandle is 
> that they can be used as optional arguments in a bootstrap method 
> description (see the last argument of visitInvokeDynamicInsn). We 
> considered that using MethodType and MethodHandle classes was a good 
> solution to this problem. The other solution we considered was to define 
> a new interface with methods very similar to the visitLdcInsn, 
> visitLdcClassInsn, visitLdcMethodTypeInsn, etc:
> 
> BsmArgVisitor visitInvokeDynamicInsn(String name, String desc,
>      int bsmTag, String bsmOwner, String bsmName, String bsmDesc);
> 
> with:
> 
> public interface BsmArgVisitor {
>      void visitArg(Object o);
>      void visitClassArg(String c);
>      void visitMethodTypeArg(String mt);
>      void visitMethodHandleArg(int tag, String owner, String name, 
> String desc);
>      void visitEnd();
> }
> 
> and we considered that this design was too complex, with quite redundant 
> methods with visitLdc...Insn.
> 
> 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