Re: ASM 4 is ready ?

Hi,

nonetheless, I agree with Eric's opinion.

In general I think, source files should and will separate between code
that uses java.dyn.MethodHandle and org.objectweb.asm.MethodHandle.

Therefore in my opinion, the discomfort that is done by giving the
concept another exceeds the risks of using the wrong MethodHandle by
failed import or the discomfort of fully spelling on of them.

CU Tronje


Rémi Forax wrote:
> On 01/08/2011 07:59 PM, Dave Brosius wrote:
>> On 01/08/2011 01:35 PM, Rémi Forax wrote:
>>> On 01/08/2011 05:23 PM, Eric Bruneton wrote:
>>>> 08/01/2011 16:46, Rémi Forax wrote:
>>>>> On 01/08/2011 04:28 PM, Eric Bruneton wrote:
>>>>>> 08/01/2011 13:56, Rémi Forax wrote:
>>>>>>> I think renaming MHandle to MethodHandle ( resp.M.Type to 
>>>>>>> MethodType)
>>>>>>> was a bad idea.
>>>>>>> I mostly use ASM at runtime e.g. in a world where 
>>>>>>> java.dyn.MethodHandle
>>>>>>> exists,
>>>>>>> you can see an example in my last blog post
>>>>>>> (http://weblogs.java.net/blog/forax/archive/2011/01/07/call-invokedynamic-java) 
>>>>>>>
>>>>>>>
>>>>>> but is it or will it be a common usage pattern? For me, in the most
>>>>>> common cases, code using ASM, like dynamic language compilers, is a
>>>>>> kind of "meta code" using "quoted" values, e.g. class names 
>>>>>> instead of
>>>>>> Class objects, quite distinct from the "user" or "base level" or "ASM
>>>>>> generated" code using the real values. So it should not be a problem
>>>>>> if "quoted" and "real" concepts are represented with classes having
>>>>>> the same names in different packages (again, in most common cases).
>>>>> invokedynamic blurs this difference.
>>>>> By example, If you have a script to execute, you can first compile 
>>>>> only
>>>>> the main entry point,
>>>>> and use invokedynamic to resolve unkown method. You will lazily 
>>>>> compile
>>>>> the other methods
>>>>> when needed, e.g. when the function will be called.
>>>>> In fact, this is a common pattern, all Java VMs works like that.
>>>> still, the compiler manipulates strings representing 
>>>> class/method/field names and types in the script, not the real objects?
>>> yes, you're right.
>>> But because the compiler and the runtime are interleaved, you will 
>>> find source files
>>> that handles both java.dyn.MethodHandle and 
>>> org.objectweb.asm.MethodHandle.
>>>
>>>> Eric
>>> Rémi
>> Would calling the class
>>
>> org.objectweb.asm.DynamicMethodHandle
>>
>> solve both of your objections?
>>
> 
> Yes, I will be happy with anything but org.objectweb.asm.MethodHandle.
> 
> Naming it MethodHandle is error prone and this kind of error is hard to 
> catch.
> org.objectweb.asm.MethodHandle and org.objectweb.asm.MethodHandle are used
> in visitLdcInsn wich takes an Object as parameter so doing something like
> 
> public void visitLdcInsn(Object o) {
>     if (o instanceof Methodhandle) {
>        // ....
>     }
> }
> 
> will be usual. But here because there are two MethodHandle, you have a 
> chance
> to use the wrong import so you will think that you check 
> org.objectweb.asm.MethodHandle
> but the VM will check java.dyn.MethodHandle.
> 
> It's a stupid bug but it's hard to find because IDE manage imports
> (they have auto-import shortcut and hide imports by default).
> 
> Rémi
> 

-- 
     Tronje Krop <[email protected]>

   Encrypted eMail welcome! GPG/PGP-Key: 0x9AD43A05
  68E5 A3D3 75A0 B096 AC75  62D5 8EEE 3D18 9AD4 3A05

 No responsibility is taken for the correctness of the
previous information. Please delete if you receive this
                  mail unintentional.

-- 
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