Difference between revisions of "Eiffel Visitor Factory Tool"

m (Sample Output)
m (Sample Output)
Line 43: Line 43:
  
 
process_error_a (a_value: ERROR_A)
 
process_error_a (a_value: ERROR_A)
-- Process object `a_error_a'.
+
-- Process object `a_value'.
 
require
 
require
 
is_valid: is_valid
 
is_valid: is_valid
Line 52: Line 52:
  
 
process_error_b (a_value: ERROR_B)
 
process_error_b (a_value: ERROR_B)
-- Process object `a_error_b'.
+
-- Process object `a_value'.
 
require
 
require
 
is_valid: is_valid
 
is_valid: is_valid
Line 95: Line 95:
  
 
process_error_a (a_value: ERROR_A)
 
process_error_a (a_value: ERROR_A)
-- Process object `a_error_a'.
+
-- Process object `a_value'.
 
do
 
do
 
check not_impl: False end
 
check not_impl: False end
Line 101: Line 101:
  
 
process_error_b (a_value: ERROR_B)
 
process_error_b (a_value: ERROR_B)
-- Process object `a_error_b'.
+
-- Process object `a_value'.
 
do
 
do
 
check not_impl: False end
 
check not_impl: False end

Revision as of 10:22, 22 November 2006

Overview

The Eiffel Visitor Factory Tool is a simple command line application to generate Eiffel visitor patterns based on Eiffel classes found at specified folder locations. It can generate an interface (deferred) and/or stub (effective) Eiffel classes in no time.

Command-line Options

By default the tool will look in the current working directory for Eiffel source files (*.e). If you want to specify alternative locations use the -i switch to specify relative or absolute directory or file paths. If you need to exclude files use the -ex switch to specify what files to exclude.

To exclude a files in the current directory that start with status you would call:

vfact -ex "status.*\.e$$" (Windows shell requires $$ to represent $)

You can optionally search all specified directories recursively using the -r switch.

For all other options please read the usage help using the -?

Sample Output

As an example of what the tool generates, imagine the tool running in a directory containing two classes - ERROR_A and ERROR_B:

class ERROR_A
    --
end
class ERROR_B
    --
end

Running the tool in with the with the following options will produce an interface and stub class:

vfact -stub -interface

Interface class:

deferred class
	GENERATED_VISITOR
 
feature -- Processing
 
	process_error_a (a_value: ERROR_A)
			-- Process object `a_value'.
		require
			is_valid: is_valid
			a_value_attached: a_value /= Void
			is_applicable_visitation_entity: is_applicable_visitation_entity (a_value)
		deferred
		end
 
	process_error_b (a_value: ERROR_B)
			-- Process object `a_value'.
		require
			is_valid: is_valid
			a_value_attached: a_value /= Void
			is_applicable_visitation_entity: is_applicable_visitation_entity (a_value)
		deferred
		end
 
feature -- Query
 
	is_valid: BOOLEAN is
			-- Determines if `Current' is in a validate state to permit processing
		do
			Result := True
		end
 
	is_applicable_visitation_entity (a_value: ANY): BOOLEAN is
			-- Determines if object instance `a_value' is applicable for a visitation
		require
			a_value_attached: a_value /= Void
		do
			Result := True
		end
 
end -- class {GENERATED_VISITOR}

Stub class:

class
	GENERATED_VISITOR_IMPL
 
inherit
	GENERATED_VISITOR
		redefine
			process_error_a,
			process_error_b
		end
 
feature -- Processing
 
	process_error_a (a_value: ERROR_A)
			-- Process object `a_value'.
		do
			check not_impl: False end
		end
 
	process_error_b (a_value: ERROR_B)
			-- Process object `a_value'.
		do
			check not_impl: False end
		end
 
end -- class {GENERATED_VISITOR_IMPL}

You can run the tool with the -n option to change the name of the generated class. Stub classes are always generated with a _IMPL extension.

Another option, user data, allows you to generate a visitor that is passed a piece of user data. In this case you would use the -ud switch an specify the base class for the user data. Using this approach will generate features that have to be passed an entity to visit upon and a user data entity (this could be void.)

Using the following command line will produce the output below:

vfact -n MY_VISITOR -ud TEXT_PRINTER -interface -stub
deferred class
	MY_VISITOR [G -> TEXT_PRINTER]
 
feature -- Processing
 
	process_error_a (a_value: ERROR_A; a_data: G)
			-- Process object `a_value' using user data `a_data'.
		require
			is_valid: is_valid
			a_value_attached: a_value /= Void
			is_applicable_visitation_entity: is_applicable_visitation_entity (a_value)
			is_text_printer_valid: is_text_printer_valid (a_data)
		deferred
		end
 
	process_error_b (a_value: ERROR_B; a_data: G)
			-- Process object `a_value' using user data `a_data'.
		require
			is_valid: is_valid
			a_value_attached: a_value /= Void
			is_applicable_visitation_entity: is_applicable_visitation_entity (a_value)
			is_text_printer_valid: is_text_printer_valid (a_data)
		deferred
		end
 
feature -- Query
 
	is_valid: BOOLEAN is
			-- Determines if `Current' is in a validate state to permit processing
		do
			Result := True
		end
 
	is_applicable_visitation_entity (a_value: ANY): BOOLEAN is
			-- Determines if object instance `a_value' is applicable for a visitation
		require
			a_value_attached: a_value /= Void
		do
			Result := True
		end
 
	is_text_printer_valid (a_data: G): BOOLEAN is
			-- Determines if data `a_data' is valid for Current.
		do
			Result := True
		end
class
	MY_VISITOR_IMPL [G -> TEXT_PRINTER]
 
inherit
	MY_VISITOR [G]
		redefine
			process_error_a,
			process_error_b
		end
 
feature -- Processing
 
	process_error_a (a_value: ERROR_A; a_data: G)
			-- Process object `a_error_a' using user data `a_data'.
		do
			check not_impl: False end
		end
 
	process_error_b (a_value: ERROR_B; a_data: G)
			-- Process object `a_error_b' using user data `a_data'.
		do
			check not_impl: False end
		end
 
end -- class {MY_VISITOR_IMPL}

Redefines

You may ask why the implementation classes redefine the features of the interface class. There is not compiler-related reason for this. Deferred features do not need to be redefined. However as a sanity check, if a feature is removed from the interface class the compiler will raise and error because it no longer exists. There is no other way to check this. This ensures your implementation class does not contain code that is no longer relevant or used. The vice-versa, new features added, are already checked at compile time.

Information

This tool was developed and maintained by Paulb.

Location: https://origo.ethz.ch/eiffelsoftware/es/trunk/Src/tools/visitor_factory

Change Log

Update: --Paulb 19:44, 22 November 2006 (CET)

  • Bug: Fixed crash when scanning large number of files.
  • Bug: Fixed multi-pattern excluded file search.
  • Added: Ability to exclude directories
  • Added: is_valid and is_appliable_visitation_entity to interface classes.
  • Change: Stubs are not generated by default, use -stub and -interface to generate both.

Initial Entry: --Paulb 23:54, 21 November 2006 (CET)