Duby dynamic dispatch has landed!

[Attila Szegedi]

On 2010.03.25., at 20:25, Charles Oliver Nutter wrote:

> On Thu, Mar 25, 2010 at 12:56 PM, Attila Szegedi <szegedia at gmail.com> wrote:
>> I did give tips for usage in DynamicLinker javadoc; the simplest you can get is:
>> 
>> public class MyLanguageRuntime {
>>    private static final DynamicLinker dynamicLinker = new DynamicLinkerFactory().createLinker();
>> 
>>    public static CallSite bootstrap(Object caller, String name, MethodType type) {
>>        RelinkableCallSite callSite = new MonomorphicCallSite(caller, name, type);
>>        dynamicLinker.link(callSite);
>>        return callSite;
>>    }
>> }
>> 
>> and then every class just does:
>> 
>> public class MyClass {
>>    static {
>>        Linkage.registerBootstrapMethod(MyLanguageRuntime.class, "bootstrap");
>>    }
>>    ...
>> }
> 
> Yep, that's exactly what I wanted. But I think it would be nice to
> have a JavaLanguageLinker built-in so that I don't have to maintain
> *any* Java code of my own. This is literally all I need, and I don't
> think I'll be alone.

Well, I *could* add a convenience "DefaultBootstrapper". My only problem with it is that it is a singleton, and there is actually some hidden state at play here, the two together are synonymous with "tricky trap" :-). Namely "new DynamicLinkerFactory().createLinker()" won't just give you a POJO linker, but a composite linker assembled from all linkers that can be automatically discovered via the java.util.ServiceLoader in the classpath of the current thread's context class loader. A linker is always tied to a class loader, and there's some other uses for that class loader in the library, namely it'll dare store strong references to classes visible through the loader it's associated with, but only weak references to classes not visible through it (to prevent accidental cross-loader retaining of classes). 

I really don't like singletons, and try to not have them in the libraries I write :-)

>>> P.S. Switch to git :)
>> 
>> I will; I certainly have the intent. I do have an account on github, I created it to fork Syrinx last year to integrate it with MOP :-) I'm still learning it (Git, that is). As I lamented elsewhere: first I encountered CVS[*]. By the time I mastered CVS, Subversion comes along. By the time I decently learned Subversion, I need Mercurial (for MLVM). By the time I grasp enough Mercurial to check out OpenJDK and apply MLVM patches, cool kids go Git. It's hard keeping up with the version control system fashion... :-)
>> 
>> What (if any) IDE integration do you use with Git?
> 
> I've used CVS, SVN, SS, Hg, Git, Perforce (a little) and Clearcase (a
> little). Git has just about the worst learning curve for cli
> interaction, but it's structured better than any other I've used.
> 
> IDE support, unfortunately, lags enough that I don't use it. I have
> use the nbgit plugin, which is pretty good. I'm pretty sure IDEA has
> great integration as usual, and I've heard Eclipse is pretty good. I
> just use command-line, raw git.

I started the preparations to migrate to git, but I'll now instead spend time on building a MLVM on my own from latest sources and see whether I still get the testcase errors. Long-term plan is to definitely move to git.

Attila.

> 
> - Charlie