The opinions expressed here are my own, not someone else's. If they seem rational, that's purely coincidental and you are likely reading far too much between the lines.

Wednesday, 9 January 2013

EMF Can Do What?

I've been very busy these past months implementing all kinds of cool new things. Of course I always intend to do some marketing for them, but once each problem is solved, it loses its glitter and I quickly focus on the next cool thing. I know I really should take time to make the community aware of new capabilities, because it makes those things more valuable in reality, but I still prefer to focus on development. Oh well, we all know where the road paved with good intentions typically ends.

As an example, I'll bet very few people are using using a ResourceSetImpl.ResourceLocator, something I added in EMF 2.8, because they don't know they can. You can see how it's used in the unit test, i.e., just create it and you're done. What does it do? It allows ResourceSet.getResourceto find the resource without searching the whole resource set. If you look closely at how it's normally implemented, you can see it uses quite an expensive linear search that is made even more costly by the need to normalize each resource's URI to do proper comparison. By adding a locator, the cost reduces to a fast mapped look-up where the performance is independent from the size of the resource set. Most importantly, the map is properly maintained, so no matter what you change, including changes to the URIConverter's URI mappings, you'll always find the right resource in constant time. So if your application has a large number of resources, your should consider using it.

The most recent example of a cool new feature is support for reified types. You'll only notice this change if you use generics extensively and you regenerate your model, assuming I've not broken anything in the process, because then you might notice sooner! Consider the following model:

Notice that in menu we know the children and selected element should be menu elements. With the latest build, the generator realizes that too, so it generates the following overrides in the menu's implementation class.

In other words, the generator will ensure fail-fast, type-safe behavior. Not only that, the edit support is also enhanced. That is, you can create any type of thing in a container.

But you can create only a menu element in a menu.

Similarly, you can select any type of element in a container.

But you can select only a menu element in a menu.

How cool is that? You might ask yourself, who would model in this way? Look closely, you'll find it right under your nose. I have the good intention to blog about other cool things you probably didn't realize were available.

2 comments:

Very nice improvement. I like the idea of posts about new things. But it would be good to put such news in the EMF page too. The latest info about new thing in http://eclipse.org/modeling/emf/ was in 2009. The latest plan was for Galileo. There is no release notes.

Yes, the EMF home page (not to mention the Modeling home page) need a complete overhaul! That's near the top of my "good intentions" list. We used to have an automatic tool that at least gathered up all the bugzillas in each build...

About Me

I lead the top-level Eclipse Modeling Project as well as the Eclipse Modeling Framework subproject. I hold a Ph.D. in Computing Science from Simon Fraser University. I have my own small company, Macro Modeling, and my work at Eclipse is funded by itemis AG.