gobo-eiffel-develop — Development discussions

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

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

On Mon, 2001-10-22 at 23:43, Andreas Leitner wrote:
> On Mon, 2001-10-22 at 15:31, Berend de Boer wrote:
> > Andreas Leitner <no...@sb...> writes:
> > 
> > > > I assume XI_PARSER is some base class here?? I don't see another need
> > > > for inheritance in this case, it's just a class with a callback
> > > > feature. And it doesn't need anything currently in XI_PARSER, it's
> > > > just confusing IMO.
> > > 
> > > XI_PARSER defines the features like `parse_from_string',
> > > `parse_from_buffer', `parse_incremental_from_string', ...
> > 
> > But you don't need them in the callback class. Perhaps move
> > parse_from_XXXX to XI_REAL_PARSER_BASE or so.
> 
> That's why XI_CALLBAKCS would not inherit from XI_PARSER. The parser is
> the source, the callbacks are the sink.
> 
> Frank, are you with us on this approach? Or do you favor yours?
> 
> Andreas
> 
> 

Re: [gobo-eiffel-develop] Re: defines for geant

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

On Mon, 2001-10-22 at 23:33, Eric Bezault wrote:
> Andreas Leitner wrote:
> > 
> > Yep, short options are also allowed. But for short options the '=' is
> > disallowed. Some apps take accept the value just with a space,
> 
> But here '=' is not meant to separate the option from its value,
> but is equivalent to the second '=' in:
> 
>   --define="name=value"
> 
> (whose double quote characters will be removed by  the
> underlying shell before being passed to the application
> if I remember correctly).

That is correct, indeed. That actuall string received by the app would
be --define=name=value

> Moreover isn't the -D option the way C compilers define
> preprocessor values?

Correct again. But to me the -Dvar=val looks a little awked. Since the
value part is variable (Dvar), it is for example not parsable via
optimus.

But then again, --define=name=value is awked too. Hmmm, dunno.

Andreas

Re: [gobo-eiffel-develop] Re: defines for geant

[Eric B. <er...@go...>]

Andreas Leitner wrote:
> 
> Yep, short options are also allowed. But for short options the '=' is
> disallowed. Some apps take accept the value just with a space,

But here '=' is not meant to separate the option from its value,
but is equivalent to the second '=' in:

  --define="name=value"

(whose double quote characters will be removed by  the
underlying shell before being passed to the application
if I remember correctly).

Moreover isn't the -D option the way C compilers define
preprocessor values?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

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

[Berend de B. <be...@po...>]

Andreas Leitner <no...@sb...> writes:

> > I assume XI_PARSER is some base class here?? I don't see another need
> > for inheritance in this case, it's just a class with a callback
> > feature. And it doesn't need anything currently in XI_PARSER, it's
> > just confusing IMO.
> 
> XI_PARSER defines the features like `parse_from_string',
> `parse_from_buffer', `parse_incremental_from_string', ...

But you don't need them in the callback class. Perhaps move
parse_from_XXXX to XI_REAL_PARSER_BASE or so.


> The reason for putting those in it's own interface is that the tree
> based parser needs exactly the same features. Thus both the tree and
> event bases parser interfaces inherit from a common parser interface
> class.

Yes, but the callback stuff doesn't need them. It can be completely
unaware of these.


> Why is that? Oops, I think I made a mistake: My XI_EVENT_CALLBACKS
> should not have it's featured deferred, but give empty implementations.
> Then you only need to refine what you are going to use - similar to the
> vistor pattern.

Yes, only redefine, much easier.


> Or are you thinking about performance issues?

Not really. If one doesn't hook any of the callbacks into expat,
everything will work just at the highest performance.


-- 
Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] Re: defines for geant

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

On Mon, 2001-10-22 at 11:09, Eric Bezault wrote:
> Sven Ehrke wrote:
> > 
> > I could change this of course if most of you would prefer the --define syntax.
> > Just let me know.
> 
> Can't they both be supported: long or short option name?

Yep, short options are also allowed. But for short options the '=' is
disallowed. Some apps take accept the value just with a space, but
personaly I think it is cleaner to allow only long options a value and
let short options server for boolean flags. Dunno what the specs say
here exactly.

IMO should every short option have a long option pendant, if only for
self documentation purposes. Whereas long options need not have short
option pendants.

If I see a usage listing like:
-v, --verbose ... some explanation

I don't even need to look at the right hand for an explanation. The long
option tells me all I need, plus it tells me what shorthand I can use.
If I only see '-v' without the explanation, I could only guess what it
means (version, verbose, volatile, ... :)



Andreas

Re: Re: [gobo-eiffel-develop] Re: defines for geant

[Sven E. <sve...@we...>]

er...@go... schrieb am 22.10.01:
> Sven Ehrke wrote:
> > 
> > I could change this of course if most of you would prefer the --define syntax.
> > Just let me know.
> 
> Can't they both be supported: long or short option name?
> 

Of course. Sould be implemented this week then.

- Sven

_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

Re: [gobo-eiffel-develop] Re: defines for geant

[Eric B. <er...@go...>]

Sven Ehrke wrote:
> 
> I could change this of course if most of you would prefer the --define syntax.
> Just let me know.

Can't they both be supported: long or short option name?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Re: defines for geant

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

On Mon, 2001-10-22 at 12:31, Sven Ehrke wrote:
> er...@go... schrieb am 22.10.01:
> > Andreas Leitner wrote:
> > > 
> > > I am cool with --define, I was just afraid that compile_* would be the
> > > _only_ way for passing options to geant.
> > 
> > I'm not sure whether Sven already implemented the
> > command-line option --define, but I'm pretty sure
> > that it's on his TODO list somewhere because if
> > I remember correctly there is already support for
> > command-line defined variables in geant source code.
> 
> geant supports this on the commandline using the -D option:
> 
>   geant -Dparam1=value1 -Dparam2=value2 ...
> 
> (Yes, I know I have to work on the documentation)
> 
> I could change this of course if most of you would prefer the --define syntax.
> Just let me know.

I'd vote for --define="param1=val1 param2=val2", because this syntax
obeys the GNU command line conventions. And thus integrates well with
the majority of the other tools available as free software.

Andreas 

[gobo-eiffel-develop] Re: defines for geant

[Sven E. <sve...@we...>]

er...@go... schrieb am 22.10.01:
> Andreas Leitner wrote:
> > 
> > I am cool with --define, I was just afraid that compile_* would be the
> > _only_ way for passing options to geant.
> 
> I'm not sure whether Sven already implemented the
> command-line option --define, but I'm pretty sure
> that it's on his TODO list somewhere because if
> I remember correctly there is already support for
> command-line defined variables in geant source code.

geant supports this on the commandline using the -D option:

  geant -Dparam1=value1 -Dparam2=value2 ...

(Yes, I know I have to work on the documentation)

I could change this of course if most of you would prefer the --define syntax.
Just let me know.

- Sven

_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

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

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

On Mon, 2001-10-22 at 07:33, Berend de Boer wrote:
> Andreas Leitner <no...@sb...> writes:

> > 
> > 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
> 
> Right.
> 
> > 
> > -- 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
> 
> I assume XI_PARSER is some base class here?? I don't see another need
> for inheritance in this case, it's just a class with a callback
> feature. And it doesn't need anything currently in XI_PARSER, it's
> just confusing IMO.

XI_PARSER defines the features like `parse_from_string',
`parse_from_buffer', `parse_incremental_from_string', ...

The reason for putting those in it's own interface is that the tree
based parser needs exactly the same features. Thus both the tree and
event bases parser interfaces inherit from a common parser interface
class.


> 
> And indeed, this class can exist with two faces to implement the
> multiple layers:
> 
> deferred class XI_JANUS_FACE
> 
> inherit
> 
>   XI_EVENT_PARSER
> 
>   XI_EVENT_CALLBACKS
> 
> feature
> 
>   on_start_tag (...) is
>     do
>       -- do my work here
>       ...
>       -- and pass the call on
>       callback.on_start_tag (...)
>     end
> 
> end
> 
> 
> We can even do data folding into such classes (making sure you get the
> on_content just once, if possible), so people don't have to have that
> in the base parser and you can add/delete it depending on your
> (performance) needs.
> > I'm not that good in pattern names, but I believe this is the
> decorator pattern.

*looking into pattern book* yes decorator seems to fit, but I think we
can still see this approach as an application of the pipe and stream
pattern. You can have a source, you can have a sink and you can have a
pipe (which is a source and a sink).


> The XI_EVENT_CALLBACKS should have 1 more feature: something like
> on_finished that is called when parsing is done, or when there is no
> more data. This will make validation easier.
> 
> XI_EVENT_CALLBACKS should come in two flavors:
> 
> 1. A simple one with only on_start_tag, on_stop_tag and on_content.
> 
> 2. The full featured one.

Why is that? Oops, I think I made a mistake: My XI_EVENT_CALLBACKS
should not have it's featured deferred, but give empty implementations.
Then you only need to refine what you are going to use - similar to the
vistor pattern.

Or are you thinking about performance issues?

Andreas

Re: [gobo-eiffel-develop] geant file for libexml

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

On Mon, 2001-10-22 at 09:25, Berend de Boer wrote:
> Eric Bezault <er...@go...> writes:
> 
> > > Why reinvent the wheel? Wouldn't it be an idea for geant to generate
> > > Makefiles? Or parts of makefiles one can include. I need a makefile anyway.
> > 
> > The primary reason to use geant in Gobo was to avoid using
> > Makefiles because they are not portable, avoid cygwin on 
> > Windows, etc. 
> 
> A makefile generator (aka autoconf) would get around this problem. Now
> one has to maintain both a makefile and a geant config file.

Well, but last I time I checked autoconf was not runable on straight
windows. And I don't think that will ever change, since it relies on a
lot of tools to be installed (m4, ... IIRC). It will (probably) run with
cygwin, but we wanted to avoid a dependency on cygwin.

Andreas
PS: The problem with mails bouncing should be fixed now. I had to
disable a debug message in the mail deliver script. Thanks Berend for
the hint.

Re: [gobo-eiffel-develop] geant file for libexml

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

> > Why reinvent the wheel? Wouldn't it be an idea for geant to generate
> > Makefiles? Or parts of makefiles one can include. I need a makefile anyway.
> 
> The primary reason to use geant in Gobo was to avoid using
> Makefiles because they are not portable, avoid cygwin on 
> Windows, etc. 

A makefile generator (aka autoconf) would get around this problem. Now
one has to maintain both a makefile and a geant config file.

-- 
Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] geant file for libexml

[Eric B. <er...@go...>]

Andreas Leitner wrote:
> 
> I am cool with --define, I was just afraid that compile_* would be the
> _only_ way for passing options to geant.

I'm not sure whether Sven already implemented the
command-line option --define, but I'm pretty sure
that it's on his TODO list somewhere because if
I remember correctly there is already support for
command-line defined variables in geant source code.

> Yep, that's why I made a symlink on my installation and used the path
> with bench in the build file. Once Eiffel 5.1 is out, I can rename the
> file. If that is ok with you, otherwise, I go and change it back to the
> variable solution.

No, that's fine.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] geant file for libexml

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

On Mon, 2001-10-22 at 10:29, Eric Bezault wrote:
> Andreas Leitner wrote:
> > 
> > So if we start with:
> > 
> > compile_ise
> > compile_se
> > compile_hact
> > compile_ve
> 
> Note that I use these above for ease of calling. We
> could have things like that:
> 
>   geant --define="GOBO_EIFFEL=ise" compile
> 
> instead of:
> 
>   geant compile_ise
> 
> but I thought that the short-cut was easier to use
> (even though more cumbersome to write).

Sure, a --define is ok with me. Some kind of autoconf tool could still
generate the correct geant call based on a configuration.eant file then.

> What's wrong with:
> 
>   geant --define="expat=true debug=true posix=true" compile
> 
> ? Once again having many 'compile_*' tasks was just to make
> the geant command-line easier to type, but if we want to
> make build files easier to write we can use the above
> command-line syntax instead.

I am cool with --define, I was just afraid that compile_* would be the
_only_ way for passing options to geant.
 
> > This also much more reflects the usage. I do not switch from debug
> > builds to release builds on every compile.
> 
> I do. I try to run tests every so often to check that
> the Gobo classes are still consistent, and I try to do
> that in all compilation modes.
> 
> > Well, but you assume that all linux users have the latest beta. Earlier
> > versions do have the old path.
> 
> It is very hard to support several Eiffel compilers, so as
> a rule of thumb we should only support one version per
> compiler. So either we decide to support ISE 4.5 or 5.0.
> Then it's up to the users to patch whatever needs to be
> patched in order to make Gobo work if they don't use the
> supported compiler version. In our case we are still in
> development phase (i.e. the version in CVS is not an
> official release of Gobo), so the rule does not need to
> be as strict, but official Gobo releases should definitely
> support only publicly available Eiffel compilers. Beta
> versions of SmallEiffel can be considered publicly available,
> but not those of ISE. Anyway I hope that ISE 5.1 will be
> officially released before we have an official version
> of Gobo, so this discussion is probably already obsolete ;-)

Yep, that's why I made a symlink on my installation and used the path
with bench in the build file. Once Eiffel 5.1 is out, I can rename the
file. If that is ok with you, otherwise, I go and change it back to the
variable solution.

Andreas

Re: [gobo-eiffel-develop] geant file for libexml

[Eric B. <er...@go...>]

Berend de Boer wrote:
> 
> Why reinvent the wheel? Wouldn't it be an idea for geant to generate
> Makefiles? Or parts of makefiles one can include. I need a makefile anyway.

The primary reason to use geant in Gobo was to avoid using
Makefiles because they are not portable, avoid cygwin on 
Windows, etc. And our goal is not to reinvent the wheel
('geant' is already reinventing Jakarta Ant anyway) but
to have fun writing a tool in Eiffel which can be used in
the Gobo package in a portable way.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] geant file for libexml

[Eric B. <er...@go...>]

Andreas Leitner wrote:
>  
> Btw, do you know if procedures can be moved around in ISE? Maybe this
> sounds like a stupid question, but I really don't know. Meaning do we
> need to protect the function pointers?

As far as I know function pointers do not change during
the execution of the program and are the same in all threads
for a given Eiffel feature.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] geant file for libexml

[Eric B. <er...@go...>]

Berend de Boer wrote:
> 
> Not really. Just that I didn't know that the code Eric showed
> worked. The code I used was the example code on ISEs website. So
> perhaps that's the way they assume you write your code, or perhaps
> its the way you must write this code. I really don't know.

Or perhaps they don't know the way to write this code properly ;-)

> And secondly I wanted to have the compiler dependent stuff in the C
> code.
> 
> Eric, does your example works with VE/SE/HACT? That would be great,
> because I too suspect that your code is much faster. We have to check
> this, who knows what happens behind the scenes :-)

That's a good question. As far as I know the Eiffel code
of the example in my previous message has a standard Eiffel
syntax, so it should compile with all Eiffel compilers.
But nothing's better than actually checking that with all
Eiffel compilers to be sure. As for the C code, it is
likely that it will be different, but #ifdef in C is
not a problem.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] geant file for libexml

[Eric B. <er...@go...>]

Andreas Leitner wrote:
> 
> So if we start with:
> 
> compile_ise
> compile_se
> compile_hact
> compile_ve

Note that I use these above for ease of calling. We
could have things like that:

  geant --define="GOBO_EIFFEL=ise" compile

instead of:

  geant compile_ise

but I thought that the short-cut was easier to use
(even though more cumbersome to write).

> then we want debug builds as well so we double:
> 
> compile_ise
> compile_se
> compile_hact
> compile_ve
> compile_ise_debug
> compile_se_debug
> compile_hact_debug
> compile_ve_debug
> 
> then we want to compile with expat:
> 
> compile_ise
> compile_se
> compile_hact
> compile_ve
> compile_ise_debug
> compile_se_debug
> compile_hact_debug
> compile_ve_debug
> compile_ise_expat
> compile_se_expat
> compile_hact_expat
> compile_ve_expat
> compile_ise_debug_expat
> compile_se_debug_expat
> compile_hact_debug_expat
> compile_ve_debug_expat
> 
> then we would like to link against the posix libraries:
> 
> compile_ise
> compile_se
> compile_hact
> compile_ve
> compile_ise_debug
> compile_se_debug
> compile_hact_debug
> compile_ve_debug
> compile_ise_expat
> compile_se_expat
> compile_hact_expat
> compile_ve_expat
> compile_ise_debug_expat
> compile_se_debug_expat
> compile_hact_debug_expat
> compile_ve_debug_expat
> compile_ise_posix
> compile_se_posix
> compile_hact_posix
> compile_ve_posix
> compile_ise_debug_posix
> compile_se_debug_posix
> compile_hact_debug_posix
> compile_ve_debug_posix
> compile_ise_expat_posix
> compile_se_expat_posix
> compile_hact_expat_posix
> compile_ve_expat_posix
> compile_ise_debug_expat_posix
> compile_se_debug_expat_posix
> compile_hact_debug_expat_posix
> compile_ve_debug_expat_posix
> 
> Actually I think the autoconf/autobuild people have a better approach
> here. They seperate the task of configuring and building a project into
> two tasks. In the first task you call:
> ./configure --with-expat --debug --my-other-option
> and then do a simple
> make
> 
> We could do something similar: Have a configure.eant file that stores
> configuration options.
> 
> A configure.eant file (that would grows linearly only) could look like
> this:
> <configure>
>         <var name="expat" value="true"/>
>         <var name="debug" value="true"/>
>         <var name="posix" value="true"/>
> </configure>

What's wrong with:

  geant --define="expat=true debug=true posix=true" compile

? Once again having many 'compile_*' tasks was just to make
the geant command-line easier to type, but if we want to
make build files easier to write we can use the above
command-line syntax instead.

> This also much more reflects the usage. I do not switch from debug
> builds to release builds on every compile.

I do. I try to run tests every so often to check that
the Gobo classes are still consistent, and I try to do
that in all compilation modes.

> Well, but you assume that all linux users have the latest beta. Earlier
> versions do have the old path.

It is very hard to support several Eiffel compilers, so as
a rule of thumb we should only support one version per
compiler. So either we decide to support ISE 4.5 or 5.0.
Then it's up to the users to patch whatever needs to be
patched in order to make Gobo work if they don't use the
supported compiler version. In our case we are still in
development phase (i.e. the version in CVS is not an
official release of Gobo), so the rule does not need to
be as strict, but official Gobo releases should definitely
support only publicly available Eiffel compilers. Beta
versions of SmallEiffel can be considered publicly available,
but not those of ISE. Anyway I hope that ISE 5.1 will be
officially released before we have an official version
of Gobo, so this discussion is probably already obsolete ;-)

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: Re: [gobo-eiffel-develop] geant file for libexml

[Sven E. <sve...@we...>]

Berend de Boer <be...@po...> schrieb am 22.10.01:
> Eric Bezault <er...@go...> writes:
> 
> > A similar mechanism will probably be partially implemented
> > in geant. Sven already started to look at how it could be
> > designed.

Yes. This will help in most situations I hope; maybe not in all.

> 
> Why reinvent the wheel? Wouldn't it be an idea for geant to generate
> Makefiles? Or parts of makefiles one can include. I need a makefile anyway.

Although I did not have time to look at you makelib tool
I cannot see a reason for not having a geant task for your tool.
You're invited to contribute ;-)
An issue will be dependency on eposix.

What I do not want is mix of geant files and makefiles.

- Sven




_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

Re: Re: [gobo-eiffel-develop] geant file for libexml

[Sven E. <sve...@we...>]

Berend de Boer <be...@po...> schrieb am 22.10.01:
> Eric Bezault <er...@go...> writes:
> 
> > A similar mechanism will probably be partially implemented
> > in geant. Sven already started to look at how it could be
> > designed.

Yes. This will help in most situations I hope; maybe not in all.

> 
> Why reinvent the wheel? Wouldn't it be an idea for geant to generate
> Makefiles? Or parts of makefiles one can include. I need a makefile anyway.

Although I did not have time to look at you makelib tool
I cannot see a reason for not having a geant task for your tool.
You're invited to contribute ;-)
An issue will be dependency on eposix.

- Sven




_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

Re: [gobo-eiffel-develop] geant file for libexml

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

> A similar mechanism will probably be partially implemented
> in geant. Sven already started to look at how it could be
> designed.

Why reinvent the wheel? Wouldn't it be an idea for geant to generate
Makefiles? Or parts of makefiles one can include. I need a makefile anyway.

-- 
Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] geant file for libexml

[Berend de B. <be...@po...>]

Andreas Leitner <no...@sb...> writes:

> This makes sense. IIRC that dynamic stuff came from Berend. Berend was
> there any other reason not to use function pointers?

Not really. Just that I didn't know that the code Eric showed
worked. The code I used was the example code on ISEs website. So
perhaps that's the way they assume you write your code, or perhaps
its the way you must write this code. I really don't know.

And secondly I wanted to have the compiler dependent stuff in the C
code.

Eric, does your example works with VE/SE/HACT? That would be great,
because I too suspect that your code is much faster. We have to check
this, who knows what happens behind the scenes :-)

-- 
Groetjes,

Berend. (-:

Re: Re: [gobo-eiffel-develop] inheritance for geant

[Sven E. <sve...@we...>]

er...@go... schrieb am 22.10.01:
> Sven Ehrke wrote:
> 
> Note that I had to fix 2 bugs in GEANT_PROJECT in order to
> make it work. The first one was to allow environment variables
> such as $GOBO in the filename specified in the 'inherit'
> attribute value, and the second was a call to Void target
> crash when the default target name of a parent build file
> was not present in the child file. These bugs are fixed now.

Thank you for fixing them.

- Sven

_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

Re: Re: [gobo-eiffel-develop] inheritance for geant

[Sven E. <sve...@we...>]

er...@go... schrieb am 22.10.01:
> Sven Ehrke wrote:
> 
> Note that I had to fix 2 bugs in GEANT_PROJECT in order to
> make it work. The first one was to allow environment variables
> such as $GOBO in the filename specified in the 'inherit'
> attribute value, and the second was a call to Void target
> crash when the default target name of a parent build file
> was not present in the child file. These bugs are fixed now.

Thank you for fixing them.

- Sven

_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

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