Re: [gobo-eiffel-develop] A prototype XML event interface

[Andreas L. <no...@sb...>]

Thinking about it for some time, I found another solution to eliminate
the bridge pattern:

The sole reason using the bridge pattern is that one has to be able to
redefine the callback features. You cannot inherit directly from the
parser, because you have to be able to switch the implementation.

Now currently the parser also includes the callbacks. But we could
seperate them into another class.
---- (pseudo code, not tested, assertions left out)

-- inherit from this class to react on events
deferred class XI_EVENT_CALLBACKS

feature 
	on_start_tag (...) is
		deferred
		end
	on_end_tag (...) is
		deferred
		end
end

-- every parser back end inherits from this class
deferred class XI_EVENT_PARSER

inherit

	XI_PARSER

feature
	set_callback (cb: XI_EVENT_CALLBACKS) is
			-- `cb' features will be called whenever a
			-- xml atom has been found.
		do
			callback := cb
		end

	-- feature parse_from_string etc. inherited from XI_PARSER

feature
	callback: XI_EVENT_CALLBACKS
end

-- a fictious parser implmentation
class XP_EVENT_PARSER

inherit
	
	XI_EVENT_PARSER

feature

	parse_from_string (str: STRING) is
		do
			...
			callback.on_start_tag (...)
			...
		end
end
----

I intentionally did not allow for more than one callback per parser. A
seperate class XI_EVENT_CALLBACKS could do the job.

Now, with this design, a user inherits from XI_CALLBACKS creates an
object of the resulting class and gives it a given parser implementation
(that can be retrieved from a factory).


> So in the end, it seems this design allows:
> 
> - easy composition of layers of event processing
> - clean client interface (no inheritance from parser)
> - bridge vs. factory does not matter for the parser
> 
> At the cost of:
> 
> - more dynamic typing of event types
> - somewhat different coding style

This is the resume of the design proposal of this mail:

  + easy composition of layers (you can still connect serveral
XI_EVENT_CALLBACK objects)
  + clean interface
  + bridge vs. factory does not matter for the parser
  + typing is as static as it is with the brige pattern
  + the coding style would stay the same (if you mean the callback
interface with that point)
  - multiple callback features, so no chance to inherit from
KI_OUTPUT_STREAM




Andreas