Transient attributes
I'm not sure if this feature was noticed by many so I figured out I would write an entry on the matter. Starting with 6.5 we have added the notion of transient attribute to our runtime. Transient attributes are not stored to disk and thus their absence in the storable file means that they can safely be ignored upon retrieval.
It can be useful in many scenarios. The most common one is the case of once per object implemented using an attribute and used as a caching mechanism. Since the value can easily be recomputed, you do not want to store the computed value to disk.
How it works, simply declare an attribute with a special note clause:
In 6.5, the support for transient only works with the C storable mechanism. In our forthcoming 6.6 release, it will also work with the Eiffel storable mechanism (a.k.a. SED) on both classic and .NET. It even works on .NET when using the .NET serialization library (to this purpose we are using the Microsoft .NET NonSerializedAttribute custom attribute on Eiffel generated attributes.) In addition in 6.6, INTERNAL has been augmented with queries to find out how many persistent fields they are in a type as well as finding out if a field is transient or not.
When can you use a transient attribute? Not all the time as you can see below with the validity rule as implemented in EiffelStudio. An attribute a of type T which is marked transient is valid if and only if it satisfies the following conditions:
- if T is a reference type, T must be detachable
- T is not a formal generic parameter
- T is not a user defined expanded type
- a is not an attribute of a user defined expanded class
The second is a direct consequence of #1. The last two are a limitation of the current implementation of storing/retrieving expanded types in the Eiffel Software runtime.
Happy Eiffeling,
Manu
Language enhancement?
How will "note option: transient" be built into Eiffel? Via a keyword?
At the moment we don't know. It is an Eiffel Software extension and to ensure that our code still compiles with another compiler, we usually implement new functionality using the note clause. We have the same kind of extension for stable attributes (i.e. in a void-safe systems an attribute which is initially not set but once set cannot be unset.)
What about transient classes? Some classes aren't really meant to be serialised out, e.g. those representing an OS object. And that property could be inherited!
That certainly makes sense. For example descendants of IO_MEDIUM could fall into this category. POINTER would be a good candidate as well. On the graphical front, descendants of WEL_WINDOW or EV_WIDGET too.
However I'm wondering how much restrictive it is for a class author to declare his class transient. I mean, the author might not know how to reconstruct it, but someone else might know and could extend our store/retrieve framework to handle them properly for a particular context.