Are your objects feeling bloated? When you look in the memory analyzer, do unsightly bulges around the heap upset you? Do embarrassing OutOfMemory exceptions mar your social life? Well hide in shame no longer. With the new EMF Ultra Slim diet, you can quickly shed those unwanted bytes to a reveal a new and slimmer you. That's right, this is not a gimmick. Go to your GenModel now, find the "Root Extends Class" property, and enter the special promotional code below.
Then regenerate your model, sit back, relax, and let EMF do all the work. Unlike other fad diets, with EMF Ultra Slim, there is no risk of nausea, hair loss, depression, insanity, or premature death because no drugs are involved. Of course smaller objects have to work harder to get the same job done, so you may experience a small decrease in performance. If this disturbs you in the slightest, immediately stop the treatment, or better yet, take the steps outlined below to allocate the fields you really need to get the most out of life.
Please note that Ecore itself has taken the EMF Ultra Slim challenge so extenders of Ecore may notice that the eContainerFeatureID has disappeared, unless of course they too take the EMF Ultra Slim challenge themselves, in which case, references to this field will vanish along with the unsightly extra bytes it consumed. If this disturbs you, recall that I've repeatedly explained that extending Ecore is done at your own risk because binary compatibility of the implementation classes is not guaranteed. If you're feeling inclined to complain about that, please address all correspondence to Hello!@DoILookLikeICare?.com and prepare for a long wait because you're more likely to see the moss in this picture grow than to get a response.
How does this copyrighted new miracle treatment work without the aid of drugs? The wonders of open source reveals all. MinimalEObjectImpl has only two fields: an int eFlags field and an Object eStorage field; they are private, so I can change them in the future. The flags field is used to represent three things: whether notifications should be delivered, the container feature ID, as well as bits to indicate what's in the storage field. It's designed so that the field needs no initialization, i.e., the default value of 0 represents the correct ground state. Additional values, such as the container, adapters, dynamic class, dynamic settings, proxy URI, and resource are maintained in the storage field. If only one such value is needed, it's stored directly in the storage field. If more than one is needed, an array of objects is allocated to hold all the required values.
But wait, there's more! The adapters list is no longer stored as a list. It's stored as an array with a wrapper list being allocated only as needed. Not only that, if this array has the same contents as that of the container, the array of the container is shared. This fits very nicely with a common pattern of usage where all objects in a containment tree share the same adapters. It's a thing of beauty.
So what if you decide really want a field all the time for some specific value because you know your objects will always have it and you'd like the storage field itself not to end up allocating an array to hold multiple values. Worry not. By overriding two or three simple methods in your derived class, you can make that design choice yourself. The nested Container class of MinimalEObjectImpl does exactly that, i.e., it allocates a field to store the container. After all, most objects are contained by other objects so having a field for this is a good thing.
So what will this fantastic new therapy cost you? Not a penny, just the time it takes for one simple treatment. Of course generous donations to Eclipse will be most welcome. Don't forget to mention EMF Ultra Slim when professing your undying gratitude to Eclipse; in addition to a fast mirror, you'll receive a special reusable "fast help" coupon that you can use in the EMF newsgroup. As a footnote, MinimalEObjectImpl is the very first file I've ever committed that actually contains my name: "Copyright (c) 2009 Ed Merks and others."
Metrology in mining and metallurgy
4 years ago