Re: Re: ASM 4 is ready ?

On 01/09/2011 08:54 AM, Tronje Krop wrote:
> 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.

It not the same concept.
java.dyn.MethodHandle is a runtime safe function pointer to
any method, constructor, etc. or some predefined 
combinations/transformations
of method handles.

org.objectweb.asm.MethodHandle only stands for *constant* method reference,
it's the compile time mirror of a only a subset of all possible method 
handles.

> CU Tronje

cheers,
Rémi

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

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