Difference between revisions of "Internal and Expanded"

Latest revision as of 12:02, 23 March 2010

We are discussing here how to export the description of expanded fields in a normal object to enable a fast and efficient introspection of objects at runtime. We will describe the various possibilities the last one being the implementation we have chosen in EiffelStudio.

To make the discussion consistent, let's suppose we have the following set of classes:

class A
feature
	b: B
	sa: STRING
end
 
expanded class B
feature
	c: C
	sb: STRING
end
 
expanded class C
feature
	sc: STRING
end

Nothing special

As of version 6.5 and before of EiffelStudio, one can use `field' and `set_field' to get and set the expanded attributes

pros: simple

cons: very inefficient

Convenience routine

The runtime is equipped with a function that given an object gives you a properly typed TUPLE which contains all the fields of an expanded type. This TUPLE can also be then used to saved back to the expanded field.

pros: ???

cons: Still memory inefficient.

Extra fields

The attributes of the expanded are also visible as extra fields of the object. In other words, we would see for class A either one of the following:

1. All components:
   • b
   • b.c
   • b.c.sc
   • b.sb
   • sa
2. All first level components and then only necessary components:
   • b
   • b.c.sc
   • b.sb
   • sa
3. Necessary components:
   • b.c.sc
   • b.sb
   • sa

Clearly the thrid option is what is enough, however it would break existing code relying on the presence of b. So we will offer the second variant with a flag to say if the field was an extra field or not.

pros: as efficient as the implementation when not using expanded objects.

cons: a little bit more complicated to implement since we need to expose some information that are strictly not need by our runtime, so we will have to duplicate some data. If an expanded type have a cycle, we won't follow the cycle and thus we will be back to the normal way of settings the expanded.