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

On 04/30/2011 05:26 PM, Tronje Krop wrote:
> Hi Eric,
>
> thanks for explaining. I can now see how well considered this design is
> even though it breaks the symmetry.
>
> CU Tronje

I want to add that we don't just consider the design,
I actually implement it and it was painful and
also complex to use.

Fortunately, Eric comes with the current API.

cheers,
Rémi

> 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