Le 02/08/2009 21:23, Attila Szegedi a écrit :
> On 2009.08.02., at 16:28, Rémi Forax wrote:
>
>
>> I've quickly browse the source code.
>>
>> I've found a small error in
>> CompositeTypeBasedGuardingDynamicLinker#addTypeBased,
>> case 1 should be:
>>
>> case 1: {
>> llinkers.addAll(tblinkers);
>> tblinkers.clear();
>> break;
>> }
>>
>
> Thanks. How on Earth did you spot that?!
>
:)
Professional alteration. I read lot of code produced by students.
>> I think you can simplify drastically the way you
>> find a linker for a given object.
>>
>> The JSR292 already recognizes that a class is responsible
>> to register itself to handle all invokedynamic
>> of all methods of that class.
>>
>> I think you can follow exactly the same way and says
>> that a class should register its own linker.
>> More that one class can have the same linker and
>> the way linkers are managed must be let to the dyn language
>> runtime.
>>
>> class ADynamicClass {
>> static {
>> MOPLinkage.registerLinker(ADynamicClass.class,
>> MyDynamicLanguageRuntime.LINKER);
>> }
>> }
>> // with
>> classMyDynamicLanguageRuntime {
>> public static final LinkerLINKER = ...
>> }
>>
>> registerLinker will do two things :
>> - use Linkage.registerBootstrapMethod with the MOP bootstrap method
>> - register that the linker should be used for all receivers of class
>> ADynamicClass.
>>
>
> Arguably, this could be done. I do have several reasons for choosing
> the approach I chose (JAR service mechanism), namely:
> 1. it's less complex for the developer of the language runtime;
> instead of including code to associate a linker with a class in every
> class, they just need to declare it in a file
>
Don't agree. I love the approach
"all is in the bytecode"
> 2. not every linker needs to be class-based (although I expect the
> majority will be)
>
If it is not class based,
One could see that as class-based linker than is able to delegate
its operation to the receiver object.
the linker has to be stored in the object
all other approaches will not scale.
Trying to optimize something that will be stored in a cache
> 3. 3rd party users of language runtimes can create implementations of
> language-specific classes; i.e. you can have your own class
> "implements IRubyObject" and have JRuby use it as a native. With my
> approach, a theoretical RubyLinker would handle that class too, with
> class-based registering you'd need to have the class register itself
> explicitly.
>
>
> And thanks for thinking this along with me. (I read on your blog
> you're on vacation too, right? Seems like most productive periods for
> working on cool stuff :-) )
>
I am in vacation close to the sea, so I'm not sure that this
is my most productive period :)
> Attila.
>
Rémi
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
