Comments on: Typesafe DSLs in Java: Part 1 — Typesafe Bytecode

By: Jevgeni Kabanov

Jevgeni Kabanov — Thu, 27 Mar 2008 05:40:12 +0000

Alex: I discuss that in “The world isn’t perfect”. Most classes you access are likely to be present and some classes you can access using special placeholders (e.g. Self for the class being constructed). In general case you just have to make some calls not type safe. It will still provide a great deal of benefit to many projects.

By: Alex Popescu

Alex Popescu — Thu, 27 Mar 2008 01:02:38 +0000

I don’t think usage of class literals will really work when defining classes, as you may need to refer classes that haven’t been loaded.

cheers,

./alex
–
.w( the_mindstorm )p.
Alexandru Popescu

By: Sp3w » Blog Archive » Linkage 2008.03.26 PM

Sp3w » Blog Archive » Linkage 2008.03.26 PM — Wed, 26 Mar 2008 20:01:44 +0000

[...] Typesafe DSLs in Java: Part 1 – Typesafe Bytecode [...]

By: Jevgeni Kabanov

Jevgeni Kabanov — Tue, 25 Mar 2008 22:04:02 +0000

Oh, and about staying up-to-date — it’s not a true versioned project at the moment, so this blog is most likely the best place to follow for now.

By: Jevgeni Kabanov

Jevgeni Kabanov — Tue, 25 Mar 2008 22:02:38 +0000

>Like you have invokeVirtualVoid, you’d also
>have invokeVirtualInt and likewise the other
>primitive types.

invokeVirtualInt wont work, since ints can appear anywhere in the descriptor, both as arguments and as result. What you can do is declare a Placeholder parametric class, which could take an enum or somesuch and overload the invoke* methods to take either Class or that. You can also just allow giving it as string. Both approaches are viable, but not pretty.

>As for the performance concern of the numerous
>instances…

No I can’t, since the methods must be polymorphic (parametrized) and the only way to do it in Java is to have the particular instance parametrized. If I have the StateObject I’ll lose the type safety (unfortunately). It is possible to make all the methods static (static methods are not polymorphic to the instance), but then I’d need to pass the instance and apply them in reverse order, which again sucks.

>it should provide support for dropping down
>to “guru level” whenever needed

Of course. That’s partially what assume* exist for.

By: Christian Vest Hansen

Christian Vest Hansen — Tue, 25 Mar 2008 21:38:05 +0000

This is certainly interesting. Perhaps you could create a number of methods designed specifically to work on the primitive methods? Like you have invokeVirtualVoid, you’d also have invokeVirtualInt and likewise the other primitive types.

As for the performance concern of the numerous instances, could you not create just a single instance of each of these MethodBuilders, perhaps even lazily, per instance of ClassBuilder, and then pass a StateObject around that contains everything they need to know at each particular call?

I also think Closures are the right way to go about control flow.

Finally, I’d like to say, that some people might want to do some very crazy things with ASM – things your API might not anticipate or allow, so it should provide support for dropping down to “guru level” whenever needed, and give direct access to the Method and ClassWriters.

Oh, and do you have a mailing list, or is the RSS feed for this blog th best way to “stay posted”?