Converting EiffelVision 2 Systems to Void-Safety

Introduction

In order to convert systems that employ EiffelVision 2 (Vision2) to void-safety, some adjustments may be needed depending on its usage. This page describes the various usage scenarios of Vision2 that will need to be converted in order to adhere to void-safety.

If you have classes that inherit from a Vision2 interface class such as EV_DRAWING_AREA, the first change that has to be made is to alter `initialize' so that any types that are attached (i.e. types that remain non-void throughout the lifetime of its container [parent object]) are instantiated via `create_interface_objects'. This feature needs to be redefined if the type from Vision2 is instantiable. If not, then it may need to be made effective (such as when the class inherits directly from EV_ANY). It is important that any attached types in the interface class are instantiated in `create_interface_objects' and these objects are initialized via `initialize'. Attached types should not be instantiated in `initialize' due to the Bridge Pattern implementation, and initialization of these types in `create_interface_objects' MUST be performed in `initialize', otherwise unexpected behavior may occur as the Bridge Pattern has not been fully set up at this point in time.

Example from EV_TIMEOUT create_interface_objects -- <Precursor> do create actions end create_implementation -- Create implementation of timeout. do create {EV_TIMEOUT_IMP} implementation.make end

Inheritance from an Implementation Interface Class with Associating Interface Class

If you have an existing, custom platform-dependent implementation, a few more changes will be needed above and beyond those required for the interface class.

For interface class changes, now the interface object is passed to the implementation after creation, via `assign_interface'. This means that `make' no longer takes an argument (see `create_implementation' above). This also means that to adhere to void-safety all of the types are now created and initialized via the creation routine of the implementation object.

An example from the conversion of the Windows implementation of EV_BUTTON_IMP:

make (an_interface: like interface) -- Create `Current' with interface `an_interface'. do base_make (an_interface) wel_make (default_parent, "", 0, 0, 0, 0, 0) extra_width := 20 text_alignment := default_alignment -- Retrieve the theme for the button. open_theme := application_imp.theme_drawer.open_theme_data (wel_item, "Button") end initialize -- Initialize `Current'. do Precursor {EV_PRIMITIVE_IMP} set_default_font end interface: EV_BUTTON;

would become:

make -- Initialize `Current'. do wel_make (default_parent, "", 0, 0, 0, 0, 0) extra_width := 20 text_alignment := default_alignment -- Retrieve the theme for the button. open_theme := application_imp.theme_drawer.open_theme_data (wel_item, "Button") Precursor {EV_PRIMITIVE_IMP} set_default_font end interface: detachable EV_BUTTON note option: stable attribute end;

The following steps are needed during the conversion:

• The attribute `interface' needs to be made a stable attribute. The converted `interface' attribute shows the syntax for doing so.

• Copy any initialization of the widget from `make' to `initialize' excluding `base_make' setup. Any initialization code that relies on `interface' would have to be rewritten so that `interface' gets passed to the new creation routine, which in turn calls the original `make'. See EV_PRINT_PROJECTOR_IMP on Windows `make_with_context' for an example of this.

• Remove `make', rename `initialize' to `make', and make sure that any calls to Precursor do not override any settings set in `initialize'. The ordering may need to be changed in order to make the code void-safe. See EV_POPUP_WINDOW_IMP.make (Windows implementation) where the setting of `user_can_resize' is performed after the Precursor call so that is doesn't get overriden.

See Also: Void-safe programming in Eiffel