Eclipse Community Forums: TMF (Xtext) » Using XBase vs JavaVMTypes

Help

Home

Home » Modeling » TMF (Xtext) » Using XBase vs JavaVMTypes(Which is best for my use case)

Show: Today's Messages :: Show Polls :: Message Navigator

Using XBase vs JavaVMTypes [message #1716165]

Tue, 01 December 2015 20:25

Larry LeBron

Messages: 124
Registered: October 2015

Senior Member

I appreciate any advice on this.

I'm using XText to re-implement a DSL with a rather non-traditional generator output, but it does use Java types and expressions (in certain contexts).

Instead of generating single classes per AST object, each AST object contributes code to multiple different factory classes.

My sense is that using XBase would therefore get me access to all of its nice syntax and Java integration, but would require overriding the generator. I assume this would also require some heavy modification of the model inferrer pipeline, though I'm still fuzzy on that process.

So, I'm debating between going with XBase vs. just building on top of XText's JavaVMTypes and sticking with the terminals grammar.

If recommending the latter, are there any good examples of member/field access and imports when using only JavaVMTypes and terminals?

Thanks again for any perspective on this one. I'm trying to avoid going deep with XBase just to discover that I am endlessly fighting it and wishing I'd built up my own structure.

Report message to a moderator

Re: Using XBase vs JavaVMTypes [message #1716217 is a reply to message #1716165]

Wed, 02 December 2015 09:30

Stefan Oehme

Messages: 159
Registered: April 2010
Location: Kiel

Senior Member

Xbase is not limited to a single type, you can infer as many as you want from one resource.

But I'm afraid you want the opposite: Many resources contribute code to one factory class. That is not something that Xbase supports out of the box.

m:1 generation is a problem that you should try to avoid if you can change your target infrastructure. If you can't avoid it, you'll have to come up with an incremental update mechanism for those factories. Otherwise incremental builds in Eclipse won't work.

Report message to a moderator

Re: Using XBase vs JavaVMTypes [message #1716307 is a reply to message #1716217]

Wed, 02 December 2015 19:19

Larry LeBron

Messages: 124
Registered: October 2015

Senior Member

Thanks for the reply. I will look into other solutions. Perhaps there is another target infrastructure option. In my DSL, there is a separate runtime which merely invokes the generated factories via reflection. The factories are essentially just giant switch statements which return the desired object, based on ID. This worked well with our old generation approach, but perhaps there is a 1:1 which would work equally well. My fear is that this would end up with a giant number of classes in the generated project (e.g. a class per code block). Is there a jvm limiation/performance disadvantage on that front?

As far as the incremental build issue goes, is it possible to disable automatic generation? I'd be fine with it if the code was only generated on user command. Or, am I missing something? Is the incremental eclipse build process somehow dependent on the generated output?

Report message to a moderator

Re: Using XBase vs JavaVMTypes [message #1716394 is a reply to message #1716307]

Thu, 03 December 2015 13:22

Stefan Oehme

Messages: 159
Registered: April 2010
Location: Kiel

Senior Member

If you don't generate code incrementally, your user will not be able to reference it before he hits the "generate" button. And that "generate" button would be slow, as it does a full build. So incremental builds are about usability.

A 1:1 generation solution is usually the best idea. When I need some kind of aggregation, I usually model it explicitly in my DSL:
Let's say I have "Modules" that are composed into an application. Instead of just picking up all the "Modules" in my project and generating an application from that, I'll have a dedicated "Application" concept in my DSL where the user lists the modules he wants. It works with incremental builds and is more flexible (the user can reuse modules in different applications). Maybe that general idea is applicable to your domain too.

Report message to a moderator

Previous Topic:	Xtext for Templating Language (CFML in this case)
Next Topic:	Change Quickfix order

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 01:50:01 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter